One of the differences of agile practices when compared with waterfall is the incorporation of change as an integral component of the project as opposed to a threat that needs to be tightly managed or ideally eliminated beyond the planning phase.The normal entry point for scope changes on agile projects is at the end of sprints or iterations during the review of the product backlog at which time the customer would add new work items, clarify existing ones and reprioritize the backlog.
However, this is not the only way in which change can be introduced. Project team members could gold plate or even redo their work. The customer or other project stakeholders could also be influencing continuous change to the "what" or the "how" of the deliverables.
If these types of changes are not reflected as new items in the work backlog, the only indicator of the issue might be velocity metrics, which would illustrate that team productivity is dropping and that it would likely take many more iterations to complete the project.
So what are some methods that a project manager could employ to balance stringent scope control with a "free-for-all"?
- Ensure that high-level iteration planning includes a determination of how many iterations are required to meet the customer's minimal must-have requirements. Focus the team and customer on achieving this target, and then use remaining iterations as an opportunity to refactor and refine.
- Work with the customer to develop a performance incentive plan for the team that balances completing work on time and on budget with meeting all of the customer's requirements.
- Track iteration velocity and if it drops or is well below expected levels, dedicate sufficient time during the retrospective session at the end of each iteration to help the customer and team members identify likely causes. These reviews could include looking at what was expected to be completed during the past iteration and comparing that to the work items that were actually worked on by team members, and how many of those were redone or significantly modified.
Don't forget to leave your comments below.
Comments
Too often, practitioners focus on the methodology and ignore the principles and culture that is required for that methodology to succeed!
Kiron
This is absolutely the challenge for an agile PM - being able to identify when flexibility and lean-focus are being abused without reverting to micro-managing the team and customer.
Thanks for your feedback!
Kiron
In my experience, most of the scope creep starts with the customer, and results when the Product Owner and Scrum Master fail to properly get the client to prioritize new ideas and remove other features instead. That's where Agile becomes an Art.
Kiron
While I enjoyed your post, it seemed to come from a more traditional perspective on scope creep--for example, alluding that team members "redoing their work" as being bad. While it *might* be bad, it might also be the most responsible thing to do...as long as the change is visible and the driver(s) sensible.
I actually don't think that term is really applicable to agile projects, because of the "baggage" it implies. I wish we could come up with another term that represented real-time agile scope adjustments. Any reactions or thoughts on that?
You also speak in terms of the PM still somehow trying to strike the balance between chaos and anarchy related to change. Like it's their sole responsibility.
I'd really like to hear you weigh-in on other aspects of agile teams, for example:
- trusting your team; fostering accountability
- leveraging team transparency
- continuous customer engagement
- allowing the cost of change to be visible
and how the PM can leverage those in a way where the "whole team" and their customer(s) are managing the dynamic change together.
Thoughts?
Thanks for this post!
Bob.
I absolutely wouldn't want there to be an impression that I feel changes and rework are bad - its just that those need to balanced against timeliness in delivering business value.
Other articles I've written on the domain do reinforce your points about the critical need for trust, open communications, collaboration and customer involvement.
My main point in writing this article was to avoid the likelihood of agile being viewed as an excuse for un-managed change.
Thanks for the feedback!
Kiron