June 29th, 2011
The One Where The Release Plan Was Unacceptable
Overview
Xander, the ScrumMaster for the Blockheads team, had just finished leading them through release planning of the highest priority section of Product Backlog for the OPAL project. The team was fairly new and had little concept of their velocity plus the project was fairly complex and, after 4 hours, the Blockheads came up with a plan of 6 sprints to complete this release.
Heleena, Xander’s manager, who had been observing this new practice of agile planning pulled Xander to one side.
“Six months? That’s ridiculous. We can’t afford to take six months to get this release out.” She said
“Well we do have the option of deploying any time after sprint three so we could call this two releases really” Xander replied
“But it’s still going to take us six months to get this functionality finished though isn’t it?”
“It looks that way with the information we have at the moment, but it could be quicker or it could even be longer” Xander explained “This plan is just an aggregation of approximations based on little practical evidence of this team working on this type of problem”
“Well, I worked through these requirements with a couple of other managers the other day and we calculated it would take 3-4 months, nearly half the estimate of the team here” Heleena said
“You already planned it out?” Xander asked “Why?”
“To give myself a baseline to assess the team’s plan. I had no idea what they were going to come up with and wanted to know if it was reasonable”
“In other words you didn’t trust the team” Xander implied
“It’s not that I didn’t trust them, it’s just that they aren’t used to doing this and, well, this idea of the team doing the planning is bound to lead to teams under-committing isn’t it?” Heleena tried to explain
“So what are you going to do with this information?” Xander asked
“Well can’t you encourage them to revisit the plan to see if they can find a way to bring the timescales down?” Heleena asked
Analysis
Xander is in a difficult situation here. This team is new and so the plan is very likely going to be wrong. All plans are wrong anyway because, as soon as they are made, the information they used is immediately out of date but, when a team is new and the problem is complex things are even harder. However, team empowerment is a key part of Scrum and giving the team the space to establish their capability is a massive contributor to that. In practice, it often takes teams about 3 or 4 sprints to establish their true velocity, during which time they tend to fluctuate around what they are truly capable of.
It is widely shown also that teams (and individuals) who set their own targets often outperform those that have their targets set for them. If trust of a team is a major issue, though, it might be worth considering shorter sprints in the early stages so as to get some empirical data about team velocity earlier. This must be weighed up against the extra overhead and strain on a team to deliver in shorter sprints.
If the projected cost of the project makes this project too much of a gamble, then the Product Owner should not proceed (or perhaps she should attempt to find another team who are more experienced in this area). However, one of the big benefits of Scrum is that the Product Owner has the opportunity to re-evaluate this “gamble” on the project every sprint. If, after one sprint, the release plan has expanded to nine sprints, the chances are the project will be stopped. However, if the team velocity is higher than predicted and the release plan shrinks to five sprints, this is a bonus.
Attempting to encourage, pressure or bribe the team into reducing the release plan will almost certainly lead to the team either consciously or sub-consciously cutting quality and introducing technical debt. The softer side of this situation is the lack of trust of the team. If the team were to find out that their plan would only count if it met the expectations of the Product Owner or management, then their buy-in to the process and the project would undoubtedly diminish with little chance of achieving the productivity and creativity benefits offered by a self-organising Scrum team.
As Henry Stimson said:“The only way to make a man trustworthy is to trust him”
Summary
“You can do it your own way, if it’s done just how I say” – From “Eye of the Beholder” by Metallica
I would encourage Xander to have an in-depth discussion with Heleena and other managers and product owners in the organisation as to the benefits of self-organisation and the general advantages of team buy-in and the consequences of pressuring teams into meeting imposed deadlines i.e. technical debt.
This was a situation where Xander used his team's On-call Coaching hours to talk this through with me before deciding what to do. To talk to me about booking some On-call Coaching hours, drop me an email or give me a call.
Category:
Scrum / scrum master / ScrumMaster Stories
Tags:
Planning / Product Owner / Release Planning / Scrummaster / The One With
0 comments | | add comment
Subscribe to RSS