Agile development has become very popular these days. It is widely recognized as improving on prior software development methods by minimizing risk and improving the likelihood of shipping on time. If you aren't familiar with Agile, there is a consise summary at http://en.wikipedia.org/wiki/Agile_software_development
At BMC, we have adopted a variant of Agile called Scrum for most of our projects.../../../../podcasts/podcast-gat.html
Usability processes always need to be optimized to fit with the development process a project uses. In this week's blog, I'll discuss some of the ways I have modified my usability techniques to fit with Scrum.
I am responsible for designing the user interface for a product called BMC Performance Manager. This development team is using Scrum with two week iterations. Every two weeks, a set of features are designed, implemented, and tested. At the beginning of each iteration, the developers are chomping at the bit to get to work on coding. They need to get the user interface design for these features within the first 2-3 days of the iteration in order to meet the schedule.
I believe that user interface design is optimally an iterative process. I like to design, get user feedback, and refine the design based on that feedback. Sometimes it is necessary to prototype multiple designs and conduct user testing to determine which approach works best. In a large product, it is important the all the features be designed to fit together into a cohesive whole.
Under our previous development process, I would work on the user interface design a few months before coding started. This provided time to do testing and refine the design. I would prototype the user interface and document it in a spec. This gave the developers a clear blueprint to work from.
With Scrum, the development is done in smaller pieces each with a short schedule. The product requirements can change during development. Features come and go based on customer input and on the progress of development. High priority features all get in, but low priority features may be added or dropped to ensure the schedule is met. Scrum emphasizes real time communication over written documents so, instead of writing specs, the development team relies on meetings and short documents on a wiki.
My challenge was to figure out how the usability process should be adapted to best fit into Scrum. I am currently working on the third release of this product developed using Scrum so have had time to refine my methods until I have a process that I think is working well.
I have found that it is important to do high level design at the beginning of the project. As soon as the requirements for the project are fairly complete, I do rough screen flows for all the critical features. This ensures the features will fit together well into the overall design. I start collecting user feedback at this point. Having a rough idea what the UI will be helps the development team to estimate the work effort and accurately plan the iterations for the release.
As the development iterations start, I refine the high level design into screenshots that show exactly what the UI will look like and describe the interaction. These screenshots become part of the documentation for each feature on the wiki. Because the high level design has given me a good idea how the feature should work, I can create the low level design very quickly. This meets the needs of the iteration schedule, but still allows me to create a design with good quality.
Some iterations are designated as hardening iterations. This is time designated for fixing bugs and making sure the code is ship quality. No new features are added in hardening iterations. This provides a good opportunity to do usability testing.
Daily interaction with the development team is essential to successful implementation of agile. The user interface designer needs to function as an integral part of the team. It doesn't work well to "throw the design over the wall" or act as a consultant.
A good article on integrating usability into an Agile development process at another company (Alias) is available at http://www.agile2005.org/XR19.pdf
There is lots more that could be said on this topic, but I just wanted to touch on a few of the key points this week. If you have questions, feel free to add a comment or shoot me an email.