What do you think about putting rules around management’s behavior when learning how to do Scrum?  In the previous installments (Part 1 and Part 2), I shared with you Michael James’s nine constraints he places around Scrum Teams to encourage them to self-organize into new patterns of behavior consistent with Scrum.  In this last article, here are the five constraints MJ puts around management and senior leaders to support them into self-organzing into new patterns of behavior which support Scrum.  Scrum is all about a new way of thinking.  These  constraints encourage new types of conversations, responses to common pressures in the office and support the adoption of Scrum.

1. Avoid interrupting Sprints: once the Team completes Sprint Planning and commits to the delivery of the Sprint Goal, the Team should be allowed to finish the work uninterrupted.  Now urgent things come up in business and we want to be responsive to that in Scrum.  If managers and senior leaders find these urgent items come up frequently within a Sprint, then perhaps shortening the Sprint length is needed.  This is the main reason why 30 day Sprints are no longer common – business moves too fast today to protect the Scrum Team from interruptions for 30 days.  Usually the business can resist the temptation to interrupt a Sprint for two weeks.  However, if that is not possible I will go to one week Sprints.  My next strategy to deal with urgent issues is to bring them to the Product Owner.  In Scrum, Product Owner is responsible for the business outcomes and balancing the development effort with responding to urgent requests.  The Product Owner has the final word on making scope changes once a Sprint is underway and should almost always defer an item rather than introduce an interruption to the Team’s focus.  Of course, there are exceptions and I am not going to deal with that nuance here.  Do not change the scope of a Sprint once it has started.  If an urgent request arises within a Sprint, speak with the Product Owner, let them decide how and when to respond and support their decision.
2. Avoid distracting Team members or splitting them across Teams: if you want people to deliver more, then we have to stop interrupting their train-of-thought and their focus.  Leadership and management can introduce all sorts of distracting elements during a Sprint due to their authority, the types of questions they ask, the concerns they raise and even their presence in the Team room.  Be mindful that when a senior leader or manager is present, they tend to cause a disruption to the equilibrium of the Team.  This is not to say managers cannot participate in a Sprint, but they just have to keep in mind they will be a distraction.  The next behavior that needs to change is the desire of some managers to split individuals across multiple Teams simultaneously.  This is called Task Switching is one of the classic wastes of software development.  This has been know since DeMarco and Lister wrote Peopleware in 1987 and was reinforced in 2001 by researchers at the University of Michigan Ann Arbor.  In the Ann Arbor study, reasearchers showed that worker productivity drops between 20% to 40% as one switches between tasks.  When this happens multiple times a day, this time lost adds up fast.  Be mindful of how managers and senior leaders interact with the Team during a Sprint.  Business leaders need to provide enough resources and staff so Team members can be 100% dedicated to one Team.
   
3. Avoid tilting the Team’s pool table:  what does this metaphor mean?  I believe MJ is referring to the idea we should avoid changing the level of the pool table so that the balls all fall into one pocket or tend to favor one side of the pool table over another.  One item that MJ calls out is designating a particular Team member a “lead”.  While leads sometimes serve an important decision-making role for software teams, they also can severely diminish self-organization and collaboration in Scrum.  In classic Scrum, there are no titles within a Team beyond “Team member”.  Some bad behavior leads have done on past Scrum Teams are assign work, give estimates and provide solutions to development problems.  ScrumMasters need to watch for this type of behavior and should intervene when leads (or any member of the Team) diminishes self-organization, collaboration and commitment.  In addition, here are two common ways I have seen Team’s pool table get tilted – awarding bonuses to individual contributors rather than the entire Team and showing favoritism towards one functional role (i.e. development over test, IT over business, etc.).  There are lots more, so be on the lookout for ways decision makers and senior leaders stack the game to a certain outcome.  Reward, praise and criticize the Team as a single unit rather than a collection of individual contributors.
4. Avoid judging the Team by anything other than its results every Sprint: as my CST colleague Mike Vizdos is fond of saying, “Deliver. And be awesome.”  In the context of Scrum, the main thing manager and senior decision makers should be concerned with is “Did the Scrum Team deliver on their commitment defined by the Sprint Goal?”   If we can say “yes”, then things are probably OK with the Scrum Team and the program.  If the Team did not deliver on their commitments by the end of the Sprint, it does not matter if your dashboard (or  your favorite metric) was yellow, red or green.  We have a problem that needs to be fixed.  MJ specifically identifies comparing estimates to actuals as one type of  behavior which should be  avoided, but there are all sorts of business metrics, while may be important to managing a project or program successfully, are generally irrelevant to the Scrum Team.   Once the Scrum Team gets out of the habit of delivering 100% on their commit to the Sprint Goal each and every Sprint, and management supports and enables that behavior be focusing on other business metrics, then Scrum is on it’s way out in an organization.  Demand potentially shippable product each Sprint and be satisfied with nothing less.
5. Support the ScrumMaster in resolving external impediments: the ScrumMaster exists in Scrum to support the Scrum Team in reaching higher levels of productivity, quality and customer satisfaction.  From time-to-time, ScrumMasters will encounter external impediments to prevent the Scrum Team in reaching these goals.   These impediments often are disguised in the form of organizational policies, procedures and standards and are inhibiting the Team from delivering potentially shippable product at the end of each Sprint.   In many cases, many of these external impediments are easy to fix since the policies, procedures and standards were put in place to deal with the weaknesses associated with the classic phase-gate approach (i.e. waterfall) to software development.  Now that we are doing Scrum, we should reexamine these policies, procedures and standards to evaluate which can be eliminated, relaxed or lightened up.  The default position is to eliminate unnecessary policies, procedures and standards (since  Extra Processes are waste), but some things must remain to protect the business, customers and end users.  As long as the ScrumMaster is pursuing the goal of organizational improvement and faster delivery of end-to-end value, allow the ScrumMaster latitude in chasing down and resolving these issues.  For the more challenging impediments, partner with the ScrumMaster to create, socialize and implement a long lasting fix.  Provide the ScrumMaster support, time and resources to work on organizational improvements on your behalf and schedule regular, meaningful conversations to gauge the effectiveness of their work.