Memi Beltrame — Wed, 21 May 2008 15:03:08 GMT

Designing means Re-designing

The “agile thing” does not necessarily have to be just chaos and irritation. In order to make agile work one has to clear a few misunderstandings that bubble up regularly in day-to-day business:
- Sprints (iterations that is) are not a miniature waterfall. Often sprints are misconceived by developers and designers as a sort of controlling device imposed by the management. Or even as a means to constantly rise the pressure to the level usually met at pre-release.
If this happens something is wrong with how the team’s unterstanding of agile is tackled and of how the process itself is run. This, in my opinion, directly challenges the Scrum-Masters competence, since it’s his/her job to make sure that a) collaboration happens and b) workload is managable.

- Daily Scrums are essential and not just hassle. Even if the whole teams sits in the same office all the time daily scrums are indespensable: sharing an office does not get a project organized. The main function of daily scrums is not actually to solve complex problems. It is a way of how the team can coordinate itself efficiently and a place where problems are brought up, action can be taken and impediments are dispelled.

- Evaluation of User-Stories must be tangible. The evaluation scale must be clear. The evaluation process basically makes a projection of what is manageable in the sprint that lays ahead. If those involved in the evaluation do not have the same scale for weighing the issues in question the process is bound to fail and people likely to suffer. This may sound silly but not having the same scale is more common than one might think. Some use a scale based on hours/days of work required, others use gut feeling. I advise using a more complex rating system involving triviality/complexity, numbers of roles involved, dependency on third parties.
The point is that there is more than one way to manage estimation. Every team should find out together what type of scale it wants to use, and finding the scale should be a prominent issue in the beginning of any agile project.

Agile is a prime example for collaborative design. Designers must be aware that collaborative design is not a choice in agile, but a requirement of the method. One way to avoid the constant changing of requirements is keeping track of User Interface / User Interaction Guidelines established during the process. Stick to them and have them ready if the product owners want to change requirements: these changes often contradict the guidelines established.
One thing I noticed about the tendecy towards requiremnt-hopping is that it often breaks very simple, basic rules of interaction design. Mostly changes break the rule of Consistency or they are just laying rubble in the way of the user, forcing the user to do something unneccessary, dull or incomprehensible.

The reason why agile applies also to the design process is that it rises the quality of the product. If it is done right you’ll get a pretty good product that satisfies not only the customer but is actually useful to users. The way to achieve this is by being aware that designing means re-designing.

Memi Beltrame

For the record: Here’s a scale that made somehow sense in the projects i was/am involved in.
It turned to be quite accurate in having 1pt correspond to 1 days work. But you’ll have to fin out for yourselves…

1 pt: trivial, without involvement of any other department
2 pts: trivial, involves more than 1 department (e.g. GUI and middleware)
3 pts trivial, requires input/data frm third party
5 pts complex issues
8 pts core features with dependencies on other core features of the department
13 pts core features that go accross departments or plain killertasks

Boxes and Arrows: Comments by Memi Beltrame