Agile Software Engineering & User Centered Desig n

8 Sep 2004 - 11:32am
411 reads
Michael Bartlett
2004

Hi Satyam,

We practise eXtreme Programming here, and have done so for about 4 years
now. We initially were trained by the guru's themselves and followed the
rules very closely.

I was having a tough time with the process because all functionality was
specified on little pieces of paper which never described the actual UI of
the product. Also the "stories" were very functional and often did not zoom
out to the bigger picture of interaction with the product. So we ended up
having a collection of functions rather than a holistic product experience.

I then read an interview (http://www.fawcette.com/interviews/beck_cooper/)
between Kent Beck and Alan Cooper on Interaction Design vs. eXtreme
Programming. I remember walking away from it thinking that Beck hadn't
listened to a word Cooper was saying and so I went off and I bought Inmates
(http://www.amazon.com/exec/obidos/tg/detail/-/0672316498/qid=1094658739/sr=
8-1/ref=pd_ka_1/002-9597995-4197642?v=glance&s=books&n=507846).

I then started experimenting with our process. Prior to developing something
that was a change to the interaction with the product I would prototype it
using a combination of HTML/Photoshop/PowerPoint. (Let me just inform you
here that we DON'T write web-based applications here - it's all thick-client
stuff). That seemed to work pretty well within an iteration as we were able
to quickly prototype interactions without tying up a pair worth of
(expensive) C++ developers and then putting it into development once were
were "pretty much" happy with it. We, of course, reserve the right to change
our mind at any time - and conversly the engineers reserve the right to
change their estimate.

Another problem we were having was the communication between Product
Management -> Programme Management -> Engineering on release cycles. As you
probably have read, XP isn't big into up-front design and so our Product
Managers didn't really have a good understanding on what would be coming out
and when and, as a result, the developers didn't have a "big picture" of
what they were doing. Of course dates and scope can change, but it still is
important to present a road-map and early "alpha" stage screen shots to
existing clients for validation on assumptions and implementation and we
just weren't getting this. Enter the "Product Design Document"....

Wow what a controversial chunk of paper it was at first! I basically wrote a
50-odd page document (more pictures than words) which had a structure along
the lines of:

* Release Objectives
* Major Product Management (PM) requirements
* Persona's and their goals
* Release Schedule (blank when presenting to engineering)
* Proposed Implementation
* Per requirement
* Interaction scenario
* Proposed implemetation (screenshots and talk-through)
* Technical considerations

I then presented the software architects with this document and boy were
they not happy! The whole emotional kick-back of "hey now were just code
monkeys and we don't design the software" blah blah. I specifically told
them up-front, but this seemed to fall on deaf ears at the time, that this
document WAS NOT a functional specification but rather a stake in the ground
- this is what we want to achieve, let's talk about. So at some point they
wanted to call it the "Product Discussion Document". Eventually they got
over it.

Anyway, to cut a long story short, we have evolved to a best of both worlds
scenario. We brainstorm with architects (they are allowed to bring any other
coders along with them to these sessions) whilst authoring the Product
Design Document. We (Programme Management) still do all the screenshots and
actually write the document - the important thing here is involvement of
architects and developers throughout the cycle of authoring this document.

Each item in the Proposed Implementation section is estimated (roughly) by
the engineering team to give as an indication of how long this stuff will
take.

This document, owned by Programme Management (PmM), is then presented to
Product Management and they are asked to validate the proposed functionality
and give us desired prioritisation. They will often present screenshots from
this document in PowerPoints to clients and discuss them and give us
feedback. The document goes back and forth a little and generally goes
through about 10 (minor) versions and perhaps 2 major revisions before we
"commit" to it. I say "commit" because we accept the mantra that things
change, and boy, do they.

Once we know that we are steering the ship in the right direction, we create
an outline iteration plan - which is sort of like a project plan and we get
stuck in. This is when XP truly kicks in. What we DO NOT do, is constantly
update the Product Design Document. We may provide updated screenshots or
interaction PowerPoints and add additional stories into the iteration.

We then have two sets of recurring meetings. At the end of every iteration
(an It. is 2 weeks) we have an Iteration Review meeting where Eng, QA, PM
and PmM all sit in one big room together and we run through everything that
was achieved in that iteration. Because we release build every day, we are
able to provide PM with the presented build and they can put it in front of
customers for further validation. The second meeting is an Interation
Planning meeting where we blow the dust of the Product Design Document,
revisit our Release Schedule and Iteration Plans and "card up" (literally,
we write things on cards of paper) the stories for development in the next
iteration.

We generally end up spending more time than estimated on each item as the
product starts to become tangible and the complexities that XP tends to
ignore start rearing their heads - but then we just start being agile and
dealing with that. This generally means we end up cutting scope a bit or/and
pushing out the release date depending on where the pressures are coming
from.

I find it an interesting (and good) blend of up-front design coupled with an
agile process. Too many times have we spent weeks engineering something that
was predominantly interaction focused and we ended up throwing it away or
reshaping it so drastically it had not remnants of its former self. Although
there are some more minor interaction elements that do work quite well just
throwing them into the XP pot to boil up.

Oh, one of the other things to consider about our company is that we build
product not solutions. So in terms of your second question regarding
deliverables... we deliver a daily build to QA for testing, a build every
two weeks to PM for testing/validation. We generally deliver a beta 2 months
prior to release and, finally, a versioned official release build.

We will often do a major release a year and 2 service releases in between
cycles. As much as possible we avoid delivering single DLL fixes and such to
clients as you can get into this real mess of managing who has what and we
then run into "branch hell" - so its only very high prioritised fixes that
ever get into this sort of thing - we call those FastTracks and continually
have to fight off Customer Service/Sales to produce them!

Hope that helps,

Michael

Syndicate content Get the feed