Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Another challenge for people new to agile is this idea about welcoming change late in the project. It's not that they don't expect changes, it's the approach taken to deal with it. Usually there is a Byzantine approach that involves change review boards, change request forms and impact assessments.
But there's more than this. The other difference as I see with some organizations trapped in a traditional approach it is they don't want to deselect some less important feature just because some change came along...and usually they don't want the date to change either. I've seen organizations where it's a badge of honor to be on the project that had to add a lot of resources and work ridiculous hours at the end to deliver the project because they had to deal with new requirements but didn’t take anything out of scope.
It comes down to education on backlog management and time boxing. Anything can be added to the backlog but it has to be prioritized. Then you pick the release date. With this and your estimates, you can draw a line and say everything below the line is in the next release. As changes come in, you prioritize them, estimate the new work, and take an equal amount of work out of your list for the first release.
Even though I’m writing about these principles one at a time, they are meant to be taken together and when an organization has one of these death march projects, they burn their people out; they ignore the principle of working at a sustainable pace. If they took a smarter approach to dealing with change and avoided the death march, they would find their teams are more productive in the long run. It comes down to making a hard decision and saying "no" to some requirement that may have originally been in scope.
No comments:
Post a Comment