Tag Archives: interruptions

Pitfall of Scrum: ScrumMaster as Contributor

The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions. Let’s look at each of these aspects of the ScrumMaster role in turn:

The ScrumMaster Helps the Team Follow the Rules of Scrum

The ScrumMaster is a process facilitator. The Scrum process, while simple to describe, is not easy to do. As the Scrum Guide says:

Scrum is:

Lightweight

Simple to understand

Difficult to master

The ScrumMaster helps the Scrum Team and the organization to master the Scrum framework. Helping everyone understand Scrum and respect its rules is a first step. Some of the rules are particularly challenging. In some companies, being on time for meetings and ending them on time is hard. Scrum requires this. The ScrumMaster helps the team do this. In some companies, meeting deadlines, even short ones, is difficult. Scrum requires this every Sprint. The ScrumMaster helps the team do this. In some companies, giving time to improving things is hard. Scrum Teams do retrospectives. The ScrumMaster ensures that the team takes the time for this.

Of course, following the rules is hard for people. Even just the concept of “rules” is hard for some people. Everyone has the right to do whatever they want. Well, if you aren’t following the rules of Scrum you aren’t doing Scrum. So for some teams, just getting to the point of being willing to follow the rules of Scrum is a big step. The ScrumMaster needs to help with motivation.

The ScrumMaster is Vigorously Removing Obstacles

The Scrum Team is going to be working hard to meet a goal for the Sprint. As they work, they are going to work through many challenges and problems on their own. However, the team will start to encounter obstacles as well. These obstacles or impediments come from a few sources:

  1. Dependencies on other people or parts of the organization outside the Scrum Team.
  2. Skill gaps within the team.
  3. Burdensome bureaucracy imposed by the organization.
  4. Lack of resources such as tools, equipment, licenses, or even access to funds.

The ScrumMaster needs to work through these.

On a panel talk on Saturday one person said “the scrum master is an administrator, moving cards, updating the burn down. It is an easy job, I think my son could do it.” I then rebutted his remarks….

The ScrumMaster will tackle enterprise operations for their slow error prone deployment process, tackle Sarbox [Sarbanes-Oxley] compliance policy that has been way over-engineered to the point of slowing dev to a crawl, telling the PMO that 3 sets of reports is waste, exhorting the team to try to do unit tests in ABAP (SAP cobol), etc.

Robin Dymond, CST – (Scrum Training and Coaching Community Google Group, Sep. 23, 2009)

The ScrumMaster is Protecting the Team from Interruptions

Every organization seems to have more work than their staff have the capacity to deliver. Staff are often asked to task switch repeatedly over the course of a day or even in a single hour. Sometimes people are “allocated” to multiple projects simultaneously. This breaks the Scrum value of focus. The ScrumMaster needs to protect the team from interruptions or anything else that would break their focus.

But what should the Scrum Team members be focused on? Simply: the goal of a single Sprint. And a single Scrum Team is focused on a single product. The Product Owner should be the point of contact for any and all requests for the time and effort of a Scrum Team. The ScrumMaster needs to re-direct any interruptions to the Product Owner. The Product Owner decides if:

  • the interruption results in a new Product Backlog Item, OR
  • the interruption is irrelevant to the product and simply discarded, OR
  • the interruption is important enough to cancel the current Sprint.

There are no other options in Scrum for handling requests for work from the Scrum Team (or any member of the Scrum Team).

Contribution as Distraction for the ScrumMaster

Any time the ScrumMaster starts to contribute to the product development effort directly, the ScrumMaster is distracted from the other three duties. Although simple, following the rules of Scrum is not easy. Getting distracted from the duty of helping the team follow the rules of Scrum means that the team is likely to develop bad habits or regress to non-Scrum behaviour. Vigorously removing obstacles is usually a huge job all on its own. Most Scrum Teams have huge organizational obstacle that must be worked on. Some of these obstacles will take years of persistent effort to deal with. The ScrumMaster cannot become distracted by tactical details of product development. Protecting the team from interruptions means the ScrumMaster must have broad awareness, at all times, of what is happening with the team. If a team member is interrupted by a phone call, an email, or someone walking into the Scrum team room, the ScrumMaster needs to notice it immediately.

Whenever a ScrumMaster takes on a product development task, focus on the role is lost and a condition of a simple conflict-of-interest is created. If the team has “committed” to deliver certain Product Backlog Items at the end of a Sprint, then that feeling of commitment may lead a ScrumMaster to focusing on the wrong things.

The time of a ScrumMaster is an investment in continuous improvement. Letting a ScrumMaster contribute to the work of the team dilutes that investment.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: The scope of work for a Sprint is never expanded mid-Sprint (interruptions)

The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team.  In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work.  Focus and commitment are both important values of Scrum.  Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment.  This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work.  If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders.  That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Seven Options for Handling Interruptions in Scrum and Other Agile Methods

Almost three years ago we wrote a brief article about interruptions.  In that article, we described four methods of dealing with interruptions.  I would like to expand on those four methods and add three more to present a comprehensive set of options for organizations struggling with this.

Option One: Follow Scrum Strictly

The rules of Scrum are clear: if it isn’t part of the team’s work for a Sprint, then it shouldn’t be done.  From the moment the team commits to work in Sprint Planning to the end of the Sprint with the Sprint Review, the team needs to be protected from interruptions.  If an interruption is truly urgent enough to warrant the team’s attention mid-Sprint, then the Sprint can be canceled.  This is a pretty extreme result however since it invalidates the team’s previous commitment.

 

The Scrum approach is based on the basic philosophy that Scrum is a system to expose the problems and obstacles in the organization.  This is painful!  In the case of interruptions, Scrum then is metaphorically throwing them back in the face of the organization and saying “this is bad behavior!  Fix the behavior that causes so many interruptions, don’t find a way to accommodate interruptions.”

For example, many teams are faced with interruptions related to their support of the software they are creating.  In Scrum, deflecting the interruptions forces the team and the organization to examine the root causes of the support issues and fix them.  If the team is producing software with lots of defects, then that needs to change.  If the team is producing software that is hard to use, then that needs to change.  If the team is producing software without the appropriate level of user documentation, then that needs to change.  But what doesn’t change is the team breaking the safety of the Sprint defined by the rules of Scrum.

Option Two: Allocate a Portion of Time to Interruptions

Given certain conditions, the amount of interruption of a team can be “stable”. If this is the case, then the team can reasonably set aside a certain percentage of their time to handle interruptions. Determining if this is possible can be done by tracking the occurrence of interruptions and the level of effort to handle them.

 

In a team using this method, there are two ways to allocate this time: everyone on the team gives a certain amount of time each day to handling interruptions OR one or two people on the team are committed full-time for a cycle to handling interruptions. In either case, if the amount of actual time spent on interruptions is less than the amount of time available, then that difference of time must be used carefully. Generally, the best use of this extra time is to work on resolving the root causes of interruptions. For example, if one person of a team is dedicated to dealing with interruptions, and most interruptions come from in-the-field bug support requests, then that person might spend any extra time working on fixing older lower-severity defects.

The amount of time that the team is allocated to handling interruptions should never be exceeded otherwise the team’s commitments at the start of the cycle are not really commitments.

This option is by far the most common systematic approach to dealing with defects

Option Three: Visible Negotiation of Change

Another common method of handling interruptions is the “fluorescent note card” method which requires visible stakeholder negotiation around the impact of interruptions. With this method, any time a stakeholder comes to the team with an interruption request, the ScrumMaster/Coach/Process Facilitator writes the request on a bright colored note card so that it is easy to distinguish it from the other tasks the team is working on in their current cycle.   The ScrumMaster then asks the team to do a task breakdown on the card and using their normal process (whatever that is) estimates the work effort. The requesting stakeholder then has to negotiate with any other stakeholders (and in particular the Product Owner/Growth Facilitator about what work to remove from the iteration in order to make room for the new work. This process works well primarily because it makes the tradeoffs visible. It does not work so well with letting the team make and keep their commitments which can have a long-term impact on trust.

 

This approach requires a few things to be in place to be effective:

  1. A visible task board instead of electronic tools for task tracking.  The visibility makes the change much more immediate and you must have the stakeholders involved right in the same physical space.  An electronic tool makes this too abstract and can lead to some important stakeholders not being properly aware of changes.
  2. A team that is reasonably good at estimating.  By “good” I mean both accurate and fast.  If it takes the team half an hour to do an accurate estimate, then that is already a significant interruption in itself!  A team should be able to look at an interruption, break down the tasks and come up with a reasonably accurate estimate within no more than 10 minutes.  Remember that doing this is already task switching so there is going to be an additional cost to the team.
  3. Finally, and perhaps most importantly, a clear agreement must be in place among stakeholders that this approach to interruptions is allowed and that the consequence of it is that the team cannot be held accountable for their commitments!!!  I cannot stress this enough!

Option Four: Separate Team for Interruptions

This option is fairly self-explanatory and in fact is just a way of saying that you have a separate support group who deals with interruptions.  The more technically capable this group is, and the more authority they have to make changes to the code/database/etc., the more effective they will be at protecting the agile teams from interruptions.

 

In some ways, this is a good approach because it makes the cost of interruptions very visible to the business: how much does your support team cost?  If this cost is growing, then it means that the development teams are creating software that is harder and harder to support.

If you follow this approach, please ensure that you do not rotate development team members through the support team as this damages the team-building process for both the development team and the support team.

(One radical option to try as an add-on to this is to defray the cost of this support team by tying developer’s salaries to the cost of support.  To make this palatable, you might simply say to the development team that any time a support person can be laid off due to improved quality in the product/system, that person’s salary will be permanently distributed and added as a raise to the salaries of the development folks.  PS.  I’ve never seen any organization do this – it’s just a theory.)

Option Five: Extremely Short Cycles

A less common, but interesting method for handling interruptions is to have extremely short iterations. In this method, choose your iteration length to be so short that you can always start work on urgent interruptions before anyone gets impatient! This can be exhausting, but it is one of the best ways to get the team and the organization to understand the large toll that these interruptions take.

 

There is a simple way to determine how long your cycle should be based on measurement.  Choose a “normal” duration (e.g. one or two weeks) and for several cycles track how many interruptions are submitted to the team, and how urgent is the turn-around time on those interruptions.  After several cycles, the team can then adjust its cycle length so that, on average, the team is able to start and finish a cycle in a time shorter than the expected frequency of interruptions.

For example, one team I worked with found that in general, they were getting interruptions that needed to be handled within three or four days, but more urgent interruptions were rare.  They decided to use a cycle that was only two days long so that on average they would complete handling an interruption in three days.  (Interruption comes half way through a cycle and is put on the backlog at the top.  The next cycle they start and finish the interruption.  Elapsed time is three days.)

Option Six: Status Quo / Suffering

There is nothing inherently wrong with continuing with your current approach to handling interruptions.  It probably makes some people miserable, but there are also some people who really enjoy crisis and constant change.  In fact, it may be part of the culture of your organization or something that is strategically important in your particular industry.  That doesn’t mean you can’t be agile, but it may mean that you are making compromises where you are trading off team performance for some other benefit.  it is important that if you choose to continue with your status quo, that you make the trade-off transparent.  Tell everyone on your teams exactly why you are making the trade-off and what is the expected benefit of doing so.

 

Option Seven: Commitment Velocity

The most sophisticated option is based on measuring a special kind of velocity called “Commitment Velocity”.  This is a mechanism that allows both interruptions to be handled mid-cycle and for teams to make commitments that they can keep.  In the simplest terms, Commitment Velocity is the minimum historical slope of a team’s Sprint burndown.

 

For example, if a team in Sprint 1 has 240 units of effort at the start of the Sprint, but, partly due to interruptions, does not finish and then has 40 units of effort left unfinished at the end of the Sprint, then the Commitment Velocity (slope) of the team is 240 – 40 = 200.  In their next Sprint planning meeting, they would plan such that they had at most 200 unites of effort in their Sprint plan.  The team then does their second Sprint and again, partly due to interruptions, they don’t finish everything.  Perhaps this second sprint started with 195 units of effort (<200) and finished with 10 units of effort remaining.  Their new Commitment Velocity is 195 – 10 = 185.  They do a third sprint, but they finish everything.

It is tempting for the team to perhaps take an average – maybe they finished 200 units of effort in their third Sprint so they average 200, 185 and 200 leaving 195.  This is not Commitment Velocity.  By definition, an average means that the team will successfully complete all their work 50% of the time.

Instead, the team maintains its Commitment Velocity of 185 for their fourth Sprint.  By the law of large numbers and the central limit theorem, as the team uses this tool of Commitment Velocity for more and more Sprints, eventually their ability to keep their commitments, even with interruptions) will become closer and closer to 100% certain.

Selecting an Option

Ultimately, the most important thing in selecting one of these options is to do so consciously and in the spirit of learning that underlies agile methods.  Choose  an option and then stick with it long enough to truly understand if it is working for you or not.

There are some things to consider as well:

  • If you are trying to do a dramatic improvement in how your organization gets stuff done, I would recommend choosing either Option One (Follow Scrum Strictly) or Option Seven (Commitment Velocity).  Both of these are options that put pressure on the team and the organization to improve.
  • If you don’t have strong executive support for Agile, then probably Options Two (Time Allocation), Four (Separate Team) and Five (Short Cycles) are going to be your best bet at first.
  • If you do have strong executive support, but you aren’t desperate to improve your organization, you might consider Option Three (Visible Negotiation).
  • Of course, Option Six (Status Quo) is the easiest… I don’t really recommend it though!  Agility requires systematic change to encourage continuous improvement.  All the other options assist with this.
Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Four Methods for Dealing with Interruptions

Recently I’ve talked with a number of people who have a simple question: what do we do with teams that are constantly interrupted by urgent support requests for their time?

Continue reading Four Methods for Dealing with Interruptions

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

8 Team Room Tips

Here are eight tips for making a great team room.

Light, Air, Nature
An appropriate amount of natural light, air circulation and live plants are excellent ways to make a space suitable for human occupation. The lack of these things can subtly but surely slow down and demoralize a team.

Layout
People need to be able to face each other and work beside each other. They also need a semi-private space to have discussions or make phone calls. The walls of the space need to have large areas that can be used for whiteboards.

Ergonomics
It’s just not worth it to have a high-performance team hampered by a poor workstation setup. Good chairs, tables at an appropriate height, and the flexibility to allow individual ergonomic needs to be accommodated all help.

Privacy
Every member of the team needs to be able to get away for short amounts of time. Some organizations provide separate mini conference rooms or “hoteling” spaces. Others allow staff to keep a private cubicle away from the team room.

Personalization
The area of space that a person occupies needs to be flexible and personalized. People need pictures, toys, plants, and other incidentals to help them make a space their own.  For this, elbow room is important!

Visibility to Outsiders
Other people in the organization need to be able to walk by to see and hear what is going on with the Agile Work team. Open doors, windows or a “bullpen” formation of cubicles all allow this.

Convenience
The space must be located so that washrooms, coffee, printers and other common services are easily accessible. It should not be set off and isolated far away from everything else.

Noise
The team will be noisy. Make sure that other people outside the team room are far enough away or isolated in some way from the noise. It can be hard to balance this with convenience and visibility.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail