I recently attended a local UPA (Usability Professional Association) event in Boston. The topic was best practices in dashboard design presented by the folks at Enernoc who use the Agile Development Process to design and build their software. The speaker gave a brief overview about the Agile process, outlining the tenet of releasing every two weeks and the merits of iterative design solely as a prelude to the best practices talk. He did not go deep into it as it was just background for the dashboard discussion. The topic of Agile would be broad enough for its own presentation.
This was proven shortly.
During the Q&A portion of the talk, the subject kept turning to Agile because a few of the audience members were stuck on the “releases every two weeks” statement. One attendee wondered how a team could design and release something as complex as an executive dashboard in two weeks?! Others murmured in support of this assumption.
I can sympathize as I was once as curious about Agile and how user experience activities could live within the 2-week cycle. Agile to the uninitiated means pulling all-nighters and burning out staff for two weeks straight to get something out the door.
Not so.
Not everything is done within those assumed two week sprints.
Some things to keep in mind:
- The team will determine how long a sprint is depending on the scale and complexity of the functionality that needs to get built. So two weeks may be extended to four weeks. This makes it pointless to get hung up on the timeframe.
- Sprints do not necessary include design, QA and development in one (2 to 4 week) time period.
- Sprints can be broken into separate activities for design, development, and QA. These can be in parallel or they can be staggered.
The reality is that each discipline can have 2 weeks to do their thing so UX will have two weeks to ideate, conceptualize, wireframe and validate while other disciplines will have their own 2 weeks to develop and so on.
UX activities that help inform the design such as requirements gathering, storytelling, and strategic design can happen after the Sprint planning session. The idea is to have all of the preliminary UX tasks taken care prior to the actual design Sprint so those two weeks are centered on formulating an idea and designing a solution.
For more on this, read my previous post on Agile and User-Centered Design.
Great post Judith. You present a great answer to a common question. I’ve had the same experience – that people get hung up on the timeframe of creation. Thus far the best way I’ve seen teams handle UX work is to have it in separate sprints and then incorporate the work with code in later sprints. Agile and Scrum are frameworks and philosophies, meaning we can change them to suit our needs as necessary.
Thanks, Robert. You hit the nail on the head with the notion that Agile is a framework that is meant to provide guidelines and not hard and fast rules. The very term “agile” means to be nimble so if release cycles need to be tweaked, that flexibility is built into the process.