With 7 technical coaches working with some 160 development teams, we find ourselves moving from team to team with little time for in-depth collaboration. I decided to try a different approach to introduce an effective work flow, encourage collaboration within and across roles, and provide direct experience with recommended technical practices in a short time. We have been running two-day intensive working sessions with one team at a time. We have done this with four teams so far. The experiences have been different, but the general results have been positive in all four cases.
We have two coaches in each session — one who focuses on Specification by Example and Acceptance Test Driven Development using Cucumber and Ruby, and one who specializes in the technology stack the developers use on the particular team. The latter is usually Java plus frameworks and COTS packages, or a mix of Cobol, Unix scripting, DB/2, and a different set of COTS packages. There are a few teams that use other technologies, such as .NET or PowerBuilder, but not many. In all cases, both coaches can support the team with both types of work, but each has stronger skills in one or the other area.
This organization is not new to lightweight development methods. They underwent an “agile” transformation at some point in the past, and they are already organized into SAFe Release Trains and small, cross-functional, collocated teams based on the Scrum model. Although there is room for improvement in story writing, story splitting, prioritization, managing cross-team dependencies, determining which teams can best benefit from Scrum or Kanban, limiting work-in-process, and choosing metrics that don’t lead to undesired behaviors, the organization generally does a good job applying “agile” principles and practices at the process level. They are definitely further along their “agile journey” than the majority of companies of comparable size.
Some of the team-level practices that we usually associate with lightweight delivery methods are relatively new to them, especially to recent hires who were not part of the previous transformation program and missed the training associated with that program. These practices include pair programming, cross-functional pairing, driving features from executable specifications, driving code from automated unit tests, and continuous delivery. There are also challenges in general time management; like many large companies, the organizational culture is centered on their groupware package (Microsoft Outlook). Meetings are scheduled throughout the day, including the lunch hour. There is little awareness of the difference between manager time and maker time.
The primary goal of the intensive working sessions is to give a team a “gut feel” for working in this manner. Just talking to them about effective delivery practices on an as-available basis had not led to any real progress. The team sets up in a conference room away from the distractions of their usual team work space. They turn off email and instant messaging. They decline all meeting invitations. During the session, we use the Mob Programming technique to focus the team on one User Story at a time. We don’t cherry-pick the stories; we just pull the next one from the team’s actual backlog. The session addresses real work items, so it does not impact their planned delivery schedule (except in a positive way). Everyone whose particicpation is necessary to complete a User Story and formally accept it is present in the room throughout the session.
The purpose of the session is to get the team started with an unfamiliar work flow and unfamiliar practices. It is not to try and complete an arbitrary number of User Stories. We try to make this clear at the outset, but due to the prevailing organizational culture the teams have (so far) always assumed the purpose was to drive through as many User Stories as possible as quickly as possible. It is difficult to change this deeply-entrenched habit of mind. Although completion of stories is not the goal of the sessions, the reality is that each of the four teams has completed at least one User Story within the two-day time frame. One team completed two. This has tended to reinforce the value of the “new” practices for team members. For reference, we’ve measured baseline delivery performance of about 15 days for User Story completion (mean Cycle Time). Completing 1 or 2 stories every 2 days represents an improvement.
All four teams said they came away with an appreciation for the value of direct, immediate collaboration. They had been skeptical of pairing especially, and yet in each case so far the teams have found pairing to be very useful and not at all stressful. One of the teams decided to make Mob Programming their standard mode of work. They don’t want to surrender any of the value of close, direct collaboration and of focusing on one thing at a time. I have noticed the other teams pairing far more frequently than before their intensive sessions.
With only four teams so far, it may be premature to declare this a generally useful approach to “jump start” development teams. Based on what we have seen, it seems to be a very promising approach. We are continuing to run intensive work sessions for more teams in the organization.