I have been coaching a world-wide program for some time.  One of the teams on this program has been challenged from the start.  At the very start they were thrown into  a whirl-wind of activity without having the necessary environment or tools available to them.  Over the course of time several members of the team left for a variety of reasons and the remaining people were formed from three different geographical sites.  The current Team members reside in two different sites in North America and one site in India.  While this is not ideal, it is the current business need and cannot be avoided for the short term.

The Team’s Challenge

In the early months the team members reported to 3 different managers.  To help create some cohesiveness, the management team met on a weekly basis to align on what is happening within the team and gain consensus on what needed to change.  Despite this level of engagement, the managers identified that the team continued to struggle with:

  1. Quality expectations were not being met
  2. The team’s output was not predictable
  3. Velocity was too slow

I was asked to get involved involved with the team to understand the problem and recommend corrective actions.  As Lean Philosophy is at my core, I felt it was time for a GEMBA walk.  I relocated myself with the team so that I could immerse myself in their activities and better understand what was really happening from both an internal and external point of view.   After some time, I boiled down the team challenges to the following three areas:

  1. The definition of done was not being completed consistantly
  2. Committed work was changing with-in the iteration
  3. The sprint backlog items being developed at the start of iteration.

As I worked with the team’s ScrumMaster, the topics came up in retrospectives and despite everyone acknowledging the same problems and agreeing on corrective actions to be taken, individuals were detracting and not improving.  This cycle continued for several iterations before I began to try a different approach:  Affect change from outside the team.

As this company is large and accustomed to creating an environment where people respond to what their manager asks for, I decided to discuss this with the managers.  We aligned on the action to be taken and after several iterations, still no change had occurred.  This left me questioning, what is actually holding this team back?

As I talked to team members, they all wanted to have change, but felt that they needed to focus on other areas because of the pressure they were under.  As I talked to managers, they wanted change and regularly discussed it with their respective employees but would just articulate back to me the same things that the team members were saying.  It was only then that I truly understood the problem:  Our managers were not engaged.  As a looked more closely, how could they be?  There was not one person responsible/accountable for ensuring the team has all of the support they need, there were three!  All three were taking different approaches, but none of them were getting involved in the team’s day-to-day challenges.

The Change

After discussion with the team’s leadership staff, we decided that one manager, John, would be responsible for the team and accountable to their performance.  HR responsibilities would still be divided across the three managers, but everyone took their direction from one leader.

In the first week, John started acclimating himself to the team ceremonies.  He started attending their huddles, demonstrations and planning sessions.  He held meetings to communicate the need for change and began building road map to recovery.  He listened to the perspective of the team and helped them understand root causes by digging in the the quantitative data.  He openly defended the team from undo outside pressures while acknowledging their challenges.

Iteration by iteration, the team began to improve.   Team members were inspired.  John created a space where the team could take the time to recover without the fear of additional outside pressure.  They began to unite on confronting their challenges.  First to tackle was quality.  The team instituted a policy of Deep Heuristic static analysis and began addressing any major issues.  They self-organized and created a strategy around developing automated testing for their software and implemented that strategy.  They began publishing their quality metrics and conducted root-cause-analysis sessions when quality dips occurred.

With quality improving, the team shifted their focus to completing what was committed to.  The team agreed that the definition of done was correct.  Some of the items were being interpreted differently from different team members.   For instance, some team members felt that they needed to have the validation team test their software before calling it ‘done’ in the iteration.  This process would sometimes take weeks and was not appropriate for a User Story definition of done as it was outside the control of the team.  John created a ‘SAFe’ environment for the team to ensure that as long as they properly tested their work within ‘Sphere of Control’ that bugs would be prioritized and corrected as they came in.

With this change, outsiders started noticing that work was more consistently flowing through the team.  In fact the team was measuring their own performance of committed versus actual with a goal of 90%.  Very quickly they were steadily achieving 95% of their committed work.