A number of my clients are attempting to use agile as they transition from a strict waterfall to a more adaptive approach to their projects.
One problem the change artists have is this: The managers, product managers, and maybe even the customers want to define all the requirements up front. I have not found the requirements definition of all the requirements possible in any life cycle. (I wrote about this in Manage It! and what to do for different life cycles.)
What can you do?
- Ask for the deliverables people want to see at different times. Now that you know what people want to see, build a roadmap.
- Timebox the requirements generation. I like to workshop the requirements in a one- or two-day timebox for agile projects.
- Ask why people want to see all the requirements. What is their reasoning for wanting to see everything before you start?
This image shows what a roadmap might look like. The roadmap has deliverables in the form of an internal release each month. I like deliverables more often, and I’ll take a one-month deliverable, especially for a program. You don’t have to work in iterations, although that makes it easier for me to show you what the deliverables might look like.
I assume that in kanban, you deliver features every day or so.
Beware of these problems:
- People in your organization do not realize they have more options than Scrum. I wrote a column about that here: Agile Does Not Equal Scrum: Know the Difference. The point in using an agile approach is that you have options for what to deliver when, by making your project more adaptable.
- People think agile is about faster. They don’t realize you get faster and better by creating an environment in which agile allows people to learn early, which might change what people work on when.
- Agile is a cultural change. People need time to think and practice when they change culture.
In all of my experience, the only projects I know that don’t have requirements changes are those projects that require two or three people and take less than a month, such as patches or fixes. All the other projects—even the ones that seem straightforward—have some sort of requirements changes.
One good reason to use agile is to adapt to those changes. If you need all the requirements up front, maybe you don’t need agile? Or, maybe you need to help your colleagues think in a more agile way. Join us at the Influential Agile Leader, if this is one of your challenges.