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.
Define “all.” I think it’s ridiculous to demand that all aspects of the product, from data model to UX to user roles and security to exposed API’s, be defined before starting to design and code. That said, there are a lot of products that have to comply with external requirements, whether driven by legislation (HIPAA) or a commercial standard (PCI). How much do you need to nail down, in order to comply with requirements not under the control of your product manager? Every product requires some thought up front – what do we need to be able to count on, so we don’t refactor most of what comes out of the first six sprints? If you’re creating a consumer-facing app with no connections to the financial network, which collects no PII, and produces no persistant output, no worries. Butfor enterprise software, start by sorting out the compliance problems, and then seque into delighting the users.
Call it “minimum viable requirements.” And don’t be surprised if there’s nothing de minimis about it.
Dave, love the idea of “minimum viable requirements.” I share your concern with non-functional requirements, such as compliance. I have no problem with thinking ahead before starting. My question is how much thinking ahead do we need before we start building small chunks of value?
There is No One Right Answer. My preference is to build many small things across the product and see where we are at the end of a short timebox (not more than two weeks). Do we need a requirements workshop then? Do we need to rethink the architecture? Your preference might be to create a roadmap and more specific backlogs. That’s because your product might be different than mine.
(BTW, those external requirements: the product manager needs to understand them and bake them into the features this team needs to deliver.)
As long as we think about what we do and don’t try to convince each other that we “know” everything about the product and that what we know won’t change, I’m happy.
Pingback: New PM Articles for the Week of February 29 – March 6 - The Practicing IT Project Manager