Restroom Closed Sign

Sometimes a process change is required!

Coaching is a function of listening, asking questions and then listening some more.  All of this listening and talking has a goal: to help those being coached down a path of self-discovery and to help them to recognize the right choice for action or inaction.  Sometimes the right question is not a question at all, but rather an exercise of visualization.

Recently when a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together, I saw several paths to suggest.  The first set of paths focused on how people behave during classic Scrum meetings and how the team could structure stories.  However, another path presented itself as I continued to consider options based on the question.  

As a reminder, the team is composed of 8 – 10 people using Scrum, but the team operates in two basic silos.  One subset works on UI related stories while a second focuses on the backend related stories. Let’s pretend that after a long discussion with the team on whether there were really two teams in one or whether splitting the stories differently would address the issue, the team was still unsure how they wanted to address the problem.

Another path to self-discovery is to start at “nothing” and determine if the siloization is causing substantial problems.  I have found that many times teams feel powerless to address process and organizational structure issues unless they can visualize the problem.  Visualization takes the problem out of the theoretical (something feels wrong but I don’t know what it is) and makes it tangible.  This is where kanban – or in this case, Scrumban – is valuable as a tool to help the team to identify their own problem.  A simple approach to consider would include the following steps:

  1. Visualize the workflow. Identify the major steps in the process of delivering functionality that is performed by the team.  Begin with the backlog and end when your team has completed working on the story (hopefully, this results with the functionality in the hands of users).  On a whiteboard (butcher paper and sticky notes also work) write the steps across the top with the backlog on the far left and done/production on the far right.  Arrange the steps in the order they happen.

Consider how the tasks related to the two silos interact. If you have two standalone workflows that are independent of each other (independence defined as each sub-team can draw a story, complete their steps, and put the functionality in production) we have two separate teams living under a single roof. Then the question is: is this a bad thing?  It might not be a problem. Until that issue is tackled, relax and move forward as two teams using Scrumban or revert to the current method (there is no harm from visualization).  For all other scenarios go to the next step.   Note: visualization can expose all sorts of process problems that do not relate to the two team issue.  I suggest not making any process changes until you take the next two steps, which position the team to collect data and structured experience.

In the next installment we will progress from visualization to assigning working in process (WIP) , doing work and then using data to recognize problems and make changes which lead to a healthy team.