All projects have constraints. Whether it be the cost, the scope, or the time. We hear a lot about how Agile doesn’t work well with fixed-scope projects. Hey man! That’s just not true!
One thing we have to make sure, first is whether you’re talking about a project or a product. We’ve all heard that Agile software development wasn’t made for projects, but as a product management approach. What gives? Agile works in all facets of life, even projects!
Joseph Flahiff wrote about this in SearchCIO recently and we would agree with his sentiments:
“Some people will tell you that scope is the one thing that is never managed on an Agile project, but is left flexible. In my experience, this point of view just sells Agile short.”
So, which projects benefit from a fixed-scope approach?
If scope management is good for some projects, which kinds of project benefit from a fixed-scope approach? Typically these are:
- Projects with a clear and well-understood scope that absolutely must be completed
- Regulatory projects
- Business mandates
What type of situations would you want to consider Agile for?
- When the organization will benefit from the incremental release of the features that make up the project.
- If the scope is fixed but there are various possible implementations. The final design benefits from an iterative cycle of development and refinement.
- If the project scope is fixed but additional features (beyond the ones mandated) are identified along the way. Examples include legal mandates, such as HIPAA, federal tax projects and so forth.
Thanks for your insights Joseph! Agile can be used in products or projects. In terms of managing the changing backlogs, just remember to have the conversation with the business about the impacts. It’s certainly OK to add features to the product backlog, but don’t move those into the project backlog unless you’ve had a discussion about impacts.