Both options can work, but there will be times when neither is an option. As Agile adoptions increase, problems will emerge on too many fronts. Coaches won’t be available when we need them, and there will be times when the teams themselves will be ill-equipped to deal with problems on their own.
Changing behavior is the most difficult aspect of change, particularly one that involves conflict. Consider the following hypothetical scenario.
Your organization has successfully implemented Scrum with pilot teams, and you are now adopting Scrum across your organization. You have provided training for everyone, and you’ve made sure that each team has a ScrumMaster and a full-time Product Owner. The teams are operating autonomously and the management team is respecting the boundaries of Scrum. All of the preconditions for success are in place.
But you have a team that is struggling to meet its commitments. One-on-ones with those on the team and conversations with your ScrumMaster indicate that the team doesn’t have an issue with understanding what the requirements are, and any impediments encountered by the team are raised and dealt with immediately. However, your investigations have revealed a common thread…
Tasks are taking longer than planned for – not an uncommon situation in software development – but there are rumblings from individuals within the team about the true nature of the problem. Despite everyone’s participation in the daily standup, people are allowed to continue “digging in” on a task that is taking longer than expected while others go about their business. In some cases, people are completing their tasks, but the work is less than thorough; code is buggy or testing is incomplete.
|As a manager, you’ve been encouraging people to speak up and question each other, providing guidance on how to keep things depersonalized and encouraging greater teamwork to help keep the team productive. Those on the team understand that they should “go there” in the team retrospective, but they don’t. In short, people are aware that they should be implementing certain behaviors, but this isn't occurring in actual practice.||We need to develop techniques that can can be applied – as required – to help teams while they’re getting the work done.|
Retrospectives and working agreements are fine, but they won’t always get the job done. A lot of people have a fear of conflict, particularly if this is new territory for them during a transition to Agile development where they haven’t had to contend with the level of teamwork that Scrum requires. People need time change, to learn new behaviors. As a manager, you want to support this team, but they are self-directed, right? So what’s a manager – or ScrumMaster – supposed to do?
As Chip and Dan Heath advise in their book Switch, we need to script the critical moves. The challenge in this case is to create a script that guides behavioral changes within an autonomous team. To accomplish this, I propose something that I’m calling The Elevator Story. It works like this:
The team’s Task Board reserves one row for the Elevator Story. This is the top-level story, making it the highest-priority story. No actual tasks are allocated to this story, and during a sprint where everything is working well, nothing will show up in any of the columns:
However, if a task is taking longer than determined in Sprint Planning – regardless of the reason or how long someone believes it will take to complete from this moment forward – that task card is physically moved up (“elevated”) to the Elevator Story row, keeping the task in whatever column that the task is already in:
This task becomes the team’s top priority as a matter of policy; there is no reliance on people having the courage to speak to up and ask questions about the task. The task gets promoted and the team must then do to two things:
- Ask 5 Whys to develop a solid understanding of the work and why that work is taking longer than anticipated. Now. Not after the fact during a retrospective, but in the moment. The team planned for something to take a certain amount of time, and as a result of this task going long, other planned work is at risk that could jeopardize the sprint.
- Plan and execute activities designed to clear the task from the Elevator Story level. Perhaps a developer needs to be paired with someone, or additional resources need to be applied to testing. The rule is that the team must decide to take different action, not allowing the same approach to working on the task to continue. The goal is to avoid Albert Einstein’s definition of insanity by doing the exact same thing and hoping for a different result.
There is a pre-requisite: User Stories must be broken out into tasks, and tasks should be granular and time-bound. Limits vary by team; I've observed teams limiting the duration of any one task to two days while others use half a day. What you shouldn’t have are “tasks” that are so general in nature that they really hide multiple tasks; if a one-week task is going long during a two-week sprint, you won’t discover a problem until it is too late to take any meaningful corrective action.
The key benefits (I’m sure that you can think of more) to using the Elevator Story are:
- It sharpens the team’s understanding and management of its work.
- It identifies problems and bottlenecks immediately, making them visible and a priority to be addressed.
- It helps to drive accountability at a personal and a team level.
- It removes the implicit reliance on people speaking up about issues that need resolving by making them a team issue by matter of explicit policy.
- Because there was a problem and 5 Whys asked, this information can be used in a retrospective to help the team implement new practices to avoid encountering the same type of problem again.
I just developed this technique recently (last week), or at least I believe that I developed it. To my knowledge this has not been articulated anywhere, and if it has, please let me know! I want to give credit where credit is due, and I’m open to the fact that I may have read about this and filed it away in the back of my mind without taking any notes (which is unusual for me, but a possibility).
I also haven’t had the opportunity to put The Elevator Story into actual practice. I’m interested in your thoughts on the technique, and I’d love to get experiential feedback from anyone who tries it. I expect that once teams get used to handling issues this way, they will not require the Elevator Story technique since they will implement the desired behavior as a matter of habit and practice. Use it as a tool when you need it, discard it when you don't.