Scrum By Example is a series of stories about ScrumMaster Steve who is the ScrumMaster for the WorldsSmallestOnlineBookstore.
Things have been going well for our ScrumMaster Steve and the team as they build out the WorldsSmallestOnlineBookStore. The team is ramping up towards their first public launch and, in the past week and a bit, they could feel the tension increasing.
Three weeks before the scheduled release date, Ellen, the CEO, comes to the team’s Daily Standup (without asking permission first). At the end of the standup she says, “It’s really important for this release to be a success. I want to see lots of overtime in the next three weeks and no slacking. Everyone must be busy.” After her speech, a few people mutter “Okay,” and then the team quietly walk to their desks.
For the first week the team manage to deal with the added pressure, then Ellen has her bi-monthly meeting with the investors. The investors say it’s not acceptable for the product to go to market with only one credit card supported (currently Visa), nor is it okay to do a soft-launch in Canada first. The site must be able to ship anywhere in North America.
Ellen returns to the team room and she is clearly on fire. She interrupts the working day to announce the additional requirements. “I realize this will be hard and there will some additional work but our investors think these changes are critical. Save time, stop writing those Unit Tests or trying to do any other engineering stuff.”
Steve and Doug try to warn Ellen of the damage this will cause, but Ellen says, “Damn the torpedoes, we’ve got to get this out there. These two new features must get in, but don’t drop any of the existing features. They’re all priority one.” In a panic, the team just start work. Of course the team aren’t able to release after two more weeks with sixty hour weeks. In fact, they’re struggling to release six weeks after the investors meeting.
During the overtime period:
- Thirty new defects were written, more than in the previous three months.
- Ian spent most of week working on supporting Amex as a credit card, before Ellen decided it wasn’t as important as MasterCard/Visa support. So the feature got dropped but the code was left in the system.
- Ian’s code for the Amex feature created a bug in the previously working Visa feature that wasn’t noticed until after the release because the team had stopped working on updating the existing automated acceptance tests.
- Most team members stopped collaborating, and as a result Kirby misunderstood and spent several days writing server code that didn’t fit with a client side code that Doug was writing.
- Tonya got sick.
- The late hours were having a significant effect on Martin’s family life. He walked into Don’s office (Steve’s director) and threatened to quit if the overtime didn’t change soon.
The release finally went live after six weeks, but instead of the rave reviews the team hoped for, users gave the store mixed reviews. They liked the basic system but found it had many bugs and subtle usability issues.
Analysis
Why did a little overtime cause all these problems?
Some key causes:
- Focusing on 100% utilization of team members (Ellen’s comment – “no slacking”) ensured that when people didn’t have an obvious high priority user story to work on, then they would do anything to look busy. It turns out that systems (both human and mechanical) that are run at high utilization rates become fragile, inflexible, and error prone. (For more detail see Steve Gamble – The Importance of Slack)
- Lacking clearly defined priorities, all the work got started at once. Later on when it was decided that Amex support wasn’t as important, a week of Ian’s time had been wasted.
- With all the features being started at once, there was limited collaboration and no swarming. Limited collaboration meant that defect rates went up since there were fewer brains involved in each design decision.
- When there is a lot of work in progress, multi-tasking becomes the norm. After every context switch (i.e. moving to a new task, even answering an email) it takes 20-25 minutes to regain the highly productive state of work called flow that high performance teams seek to achieve. In addition, error rates go up in part because we don’t always correctly remember the context of a task when we switch back.
In a case like this, it often boils down to the CEO not having a good understanding of the Product Backlog for the team. In addition there is no map of the overall portfolio to help make the choices clear. Lacking better information, Ellen believed she could just keeping demanding more output with few consequences.
How could Steve have handled this better?
The day Ellen first came into the room with the demand for overtime (before the investors meeting), Steve could have taken her aside later in the day and discussed the costs. The simplest explanation might have been that any system has a “hull speed”, i.e. a maximum speed that can achieved without dramatically increasing the amount of effort. Adding more pressure won’t make a significant difference to the speed and in some cases just risks damaging the hull. Instead of overtime, Steve could have suggested this would be a good time to reinforce core hours, shutdown outlook for most of the day, and cancel most meetings outside of the team. They could even tell the company not to interrupt the team at all during the core hours. All of these changes have the goal of giving the team members more focused time.
When the investors demanded more features in the same timeframe, Steve and Product Owner Paula could have shown Ellen the product backlog as it stood. They could have asked her what she would either drop completely or delay until after the release to achieve the new goals. In addition, they could have asked her for the priorities of each of the new items. Even during a crunch, the team would still benefit from spending a couple of hours doing backlog refinement with the new features. This would ensure that the team members have a common understanding and get at least minimal acceptance criteria for each. This would increase the chances that team members would collaborate during the crunch period.
In the future, Ellen would benefit from seeing a map of the overall project portfolio of the work in flight and queued – a portfolio map that gets updated every few weeks so she always has recent information to share with the investors. In addition, it would help with realistic expectations management.
But those positive Scrum practices didn’t happen for our hapless team this time, and instead they will spend the better part of the next three to four months undoing the damage of the overtime.
Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Thanks for sharing your suggestion on how to deal with such situations. It’s really helpful. BTW. Couldn’t John disagree with investors and tell them they won’t deliver it on time?
Piotr – yes you’re right John could has a lot of other options, mostly I ran out of writing energy and wine 🙂 When I was writing John felt scared and was concerned if he pushed back too hard he would lose his job.
It looks like John didnot play the role of SCRUM Master really well. He should have protected the team from CEO’s direct entry into Daily Standup meeting and regular feedback with PO for items.
Your suggestion about portfolio map is quite wonderful. With such information radiators, it would surely help the team to set expectations right.
Raju – please be gentle with John, he’s young and has less experience than we would like. As below he’s also concerned about keeping his job.
clearly this is bad communication between management and team (both ways), without wrapping it up in Scrum catechism. Unpack the situation and it’s simply a matter of execs, management and scrum team unable to drive a situation where all parties understand all needs, and an effective prioritisation approach is developed. I am a strong supporter of agile approaches, but sometimes I wonder whether all the scrum process and language alienates management and enables team to not find the right solution. I agree that in terms for formal Scrum, John was not strong enough, and did not present options to Ellen in her terms or a way that she could understand. But I see a lot of this type of situation, largely driven by a wholehearted adoption of scrum but with poor execution.
Madman (hopefully not a real name) – I’ve seen the problem in a variety of situations Scrum and otherwise. Recently I’ve seen several examples where it was understood by team members and management that Scrum meant overtime to meet the Sprint Goal or commitment. In one case the amount of extra time is causing burnout and having an effect on people’s family lives.
I wrote this piece to illustrate the problem overtime breeds. I wrote in the language of Scrum as you call it because that is the world that I tend to work in. However you’re right if you unpack it – its about miscommunication and not understanding the limits of people.
As to the language of Scrum alienating management – that depends on the managers in question and who they wanted to be in the first place. Part of the benefit of Scrum is that it provides clear boundaries about who owns which aspect of the work. In this case the problem happened when the boundaries were violated.