All About Agile | Agile Development Made Easy!
Dealing with Slippage in Agile/Scrum
A program manager asked me how to deal when a scrum team slips over its commitment. The review-retrospect-renegotiate does not convince him as he is concern about the slippage may ripple through end of release.
We can minimize and mitigate risks but it is impractical to expect there won't be any slippage. Scrum allows to identify it and take corrective measure at earliest possible. But having a release planned in advanced, how do we convince the management that the scope/features have to be re-prioritized and re-negotiated in case we slip over it.
I believe it requires total Agile adoption from top to bottom and from inside out. Any suggestions? Has this been answered already?
/Manish
Views: 28
Replies to This Discussion
-
Permalink Reply by Kelly Waters on -
Hi Manish. Indeed this is a tricky issue. The truth is that agile doesn't solve this - as you say, it simply highlights it much earlier in the project, while there's still time to do something about it. Apart from highlighting problems early, I've found that agile estimating techniques greatly improve your chances of avoiding slippage. However this is only true once you have built up a track record and know your team's velocity. You can read more about this on my blog - agile estimating: the secret to delivering on time.
Nevertheless, the old project management triangle - time, scope, cost (with quality in the middle) - still applies! You do need your management to understand these dynamics and that these are trade-off decisions that need to be made on any project in any methodology. You can reduce scope, reduce quality (obviously this is not generally recommended!), add time or add cost. Either that or future parts of the project will need to be delivered quicker than planned, which may or may not be possible. If none of these actions are taken, then clearly it increases the risk on the project and this decision should be taken knowingly.
Identifying problems early, which agile really does help to do, gives you every opportunity to fix the problem before the project is too far down the road to do so! But not necessarily without impact...
Kelly.
-
Permalink Reply by Manish Manekar on -
Thanks Kelly, appreciate your response.
-
Permalink Reply by Kelly Waters on
-
No problem Manish.
It would be great to hear from others in this group and understand how they have tackled this issue when it has arisen? Anybody got some experience they can share on this?
Kelly.
-
Permalink Reply by shabbir on -
We have found similar issues with in our teams. We have solve these issues mostly with training and brown bag sessions for each role ( this includes PMs also). In training and brown bag sessions we normally come up with example problem-scenarios and their possible solutions. These sessions are normally lead by industry leaders like ThoughWorks etc...
Yes this is a kind of making your every member of the team agile-aware.
Shabbir
http://agile-software-testing.blogspot.com/
-
Permalink Reply by Patrick on -
I concur with everyone's observations. I've run into similar issues with my customer, especially as we begin to understand the complexities of some of the less understood user stories.
The most important thing we've done, is to educate each stakeholder in what the agile processes are and are not. Really, agile will identify these issues early so you can find mitigation plans, but will not solve them. Many stakeholders view agile as a silver bullet and this is one of the biggest risks I've seen with successful agile adoption.
-Pat
© 2012 Created by Kelly Waters.
