June 29th, 2011
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
May 24th, 2011
Overview
Karina, a RE-TRAINED project manager, had recently come back from her Certified ScrumMaster training which had been organised just before the STING project was due to commence. She was aware that Serena, her boss, was keen for this project to be agile but was very nervous about it as this was a big project for one of their major customers. Before she went on the training she had looked at the original budget for 3,500 man days of effort over the next 12 months and thought this would be a big risk for her first Scrum implementation.
Karina had a de-brief with Serena on her return to the office with the idea of setting up the necessary structure for Scrum on the STING project. She mentioned that Scrum teams are generally optimal when... read more
Category:
Scrum
/ ScrumMaster Stories
Tags:
Multiple Teams / Planning / Project Manager / Re-trained / Scaling / Scrummaster / The One With
April 27th, 2011
Overview
Half way through the Sprint the team are having their Daily Scrum. The team take it in turns to share with their colleagues what progress they have made and what they plan to work on today. There are a couple of impediments that get added to the Sprint Backlog and Ashley, the ScrumMaster promises to pick up – one with an external vendor who is not supplying the input file in the correct format, and another with Operations who still haven’t provided a correctly configured staging environment.
The team glance at the Sprint Burndown which shows they are roughly on track and the team are about to leave the Scrum room when Ashley asks a vital question:
“Are we actually OK here? I feel worried but you guys seem fine wit... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Backlog / Burndown / Impediments / Scrummaster / Team / The One With
November 30th, 2010
Overview
On my first day coaching a new team they invited me along to their Daily Scrum first thing in the morning. They had been using Scrum for a couple of months and had a great “Scrum room” with glass walls on all sides and a lovely view of the lake. On one wall they had their Sprint Backlog, on another they had the Sprint Burndown and on another they had the outcomes from the last retrospective.
Everybody was there on time and even Annika, the Product Owner, was demonstrating her commitment to the team by being present. There were a few quick greetings before the team members stood in a circle and took turns to update their colleagues on their progress, confirming the view that the Sprint Burndown was indicating their good... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Burndown / Daily Scrum / Product Owner / Scrum / Scrummaster / The One With
October 18th, 2010
Overview
Eve, the newly minted ScrumMaster was facilitating her first sprint planning for the Jalapenos team on Project Lhasa. She had worked hard with Lilia, the Product Owner, beforehand to make sure the product backlog was well organised, prioritised and understandable and the team had reacted well. The first part of the sprint planning meeting included some planning poker to estimate the top 20% and some good conversation emerged between the team and Lilia. The team committed to 28 points of product backlog (8 items) and were now in the second part of the meeting, where the team work out how they are going to turn those 8 items into potentially deployable functionality.
Clinton, Tania & Kurt were around the whiteboard with a stack ... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Commitment / Planning / Sprint Planning / Task Board / Tasks / The One With
August 24th, 2010
Overview
The Wizard Sleeves were a team of 7 people – Alistair, Dave, Gordon, Margaret, Nicola, Olivier, and Peter; pulled together from various project teams within the department to tackle a project that had been hanging around for about a year. At Sprint Planning Tony, the ScrumMaster (and also one of the management team in the department), brought along a “resource planner” to show how much time each of the team members had available to spend on this project.
Alistair
Dave
Gordon
Margaret
Nicola
Olivier
Peter
40%
33%
50%
50%
25%
66%
33%
Every member of the team had other projects that they were working on at the same time as working on the Wizard Sleeves team. Indeed thi... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Dedicated Teams / Multi-task / Resource / Sprint Planning / Team / The One With
July 12th, 2010
Overview
Andy, the ScrumMaster, was guiding the team through a session of planning poker to estimate the initial Product Backlog so the team could come up with a release plan for the new project. Murray, the Product Owner, had provided the team with the Product Backlog in time for the planning session although it did have to be rescheduled a couple of times as he couldn’t get hold of a couple of the account reps to get their requirements.
The team had timeboxed three hours for the estimation but they had only really just scratched the surface of the Product Backlog and time was nearly up. A quick look at the spreadsheet showed they were probably only about 10% of the way through the product Backlog and that was quite depressing; it ... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Backlog / Product Owner / Requirements / The One With
June 14th, 2010
Overview
Abdul, the lead developer was one of the co-founders of the company along with Pervez, the CEO and Suzanne, the head of sales. They had built a product from scratch to rival the biggest players in the industry and were getting to the point where they absolutely had to expand. So far they had got away with just Abdul and another developer building the product and due to the small nature of the team, when there was a trade off between user experience and functionality, the choice had always been to add functionality at the expense of user experience.
Recently Pervez had appointed a Product Owner, Manish, to the team to focus the product from a user’s perspective as a clunky product just wouldn’t fly in the market. Unfort... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Design / Designer / Dual Role / Product Owner
May 25th, 2010
This blog post is the first in a series of stories from real Scrum teams (although the names etc have been changed to protect anonymity).
Overview
Marcel had been at the company for 7 years and, in that time, had come to be known as the “go-to guy” for Java work. In fact he was known affectionately as the “Java Guru”. The last project was a really important one for the whole company and, naturally Marcel was a central part of the effort to build this product. On more than one occasion he had come up with a breakthrough to help get the team and project back on track and, with a monumental effort from everyone, the project just about met the deadline.
In an attempt to get things under a little more control... read more
Category:
Scrum
/ scrum master
/ ScrumMaster Stories
Tags:
Developer / Dual Role / Geoff / Scrum / Scrummaster
Subscribe to RSS