Building software applications using agile techniques is no guarantee of success. Why? While waterfall teams spend too much time at the outset trying to nail down business requirements, agile teams may also invest too much time on story backlogs. Either way, the teams try to capture and document what the business thinks it wants, but how do they know?
In my last post, I suggested that project phases as defined in RUP (Rational Unified Process) may help agile development teams build better software. Let’s explore that concept further and see how an inception phase can clarify business needs and get everyone in sync. Be advised that using phased sprints in the manner I suggest below may not sit well with some agile developers. It’s non-standard.
I want to be clear that phases apply to an entire software project — all the sprints. Never try to use phases within sprints. It won’t work. You’ll end up with mini-waterfall projects encapsulated inside sprints. That’s not agile.
The Agile Inception Phase
For agile development teams, the primary purpose of the inception phase is to obtain agreement on software functions, features, and flow. In other words, what will the software do (functions) and how will the software do it (features and flow)? The software team should focus on stories that demonstrate the what and how while laying a foundation for future development.
In this respect, using an inception phase may violate an agile rule — deliver valuable and working software at the end of each sprint. But, it depends on how you define value. I’d argue that aligning the business team and the technical team has tremendous value even if the software delivered at the end of a sprint doesn’t provide functionality that the business can use right away.
For a small project, alignment may take just one sprint. For a big project, it may take 2-3 sprints. If you can’t gain alignment and establish a direction in 2-3 sprints, you’re in trouble. Kill the project and start over.
Eliminate Ambiguity and Structure Workflows
How do you get aligned? Focus on ambiguity and workflow. Anything that the business is having trouble clearly articulating needs to be clarified in a hurry. Build a prototype, however crudely, and have a conversation around it. The idea is to build the essential software elements and get them in front of the users so they can see how the software will deliver the results they want.
If they like what they see, build out the prototype into a finished product in future sprints. If they don’t like what they see, it’s better to find out early than to devote months of effort to throw-away code.
Also spend time demonstrating how the software will flow from one user task to the next. For example, the user searches for an item, views it, edits it, saves it, and searches for the next item. How many mouse clicks and/or keyboard entries are needed? What will happen if the user is distracted part way through and needs to save state and return later? Flow equals productivity. Don’t ignore it.
“Done” Gets People Interested
In a big, complex, software system, the business and technical teams have to synchronize their efforts early and often. It can be a major challenge because busy stakeholders tend to lack interest in projects until the software is “done”. Of course, by then, it’s too late. When they aren’t interested, the end result will be no different than gathering all the requirements up front and waiting many months to show working software to them.
By dividing the project into phases, we create several “done(s)” along the way. When the inception phase is “done”, it’s time for the business stakeholders to say “yes” or “no” to the way-forward defined by the software. Clearly, any aspect of the software is subject to change in future sprints but software developers will tell you that change can be costly. It’s better, faster and cheaper to get it right during inception.
In my next post, I’ll discuss the elaboration phase.