By Roger W. Brown
Our coaching group recently received requests for help from three teams that needed to make changes in their agile practices. The first was a team that had adopted a set of agile practices with no external guidance. They had veered off course. The second was a team using some agile practices with no formal knowledge of agile principles or practices. The third was an established agile team that has been acquired by a new company and is now required to conform to a different agile framework. In all three cases, we applied a simple, yet effective, tool: a facilitated gap analysis.
Our first case is an example of the type of issues we encountered. As an introductory step, the team invited us to join the Daily Scrum. This is what we heard:
- Twenty people from multiple locations met for thirty minutes on a conference call.
- All focus was on a collaboration tool used to log each member’s time-in-task.
- An authoritative voice directed each person to answer three questions:
o What task did you work on since the last meeting?
o How much time did you spend on it?
o Why is it taking so long?
Anyone who has had Scrum 101 could find the warning signs in this scenario right away. But we don’t want to just send the team a list of our recommendations. A basic principal of Scrum is team empowerment. When a team makes its own decisions, the motivation level is higher and success is more likely. Similarly, a team requesting outside assistance is likely to have better results when the help is facilitated rather than directed. Our challenge, then, was to get the team to find their problems, own them, and fix them. That’s where gap analysis comes in.
What is Gap Analysis?
Gap analysis is a conceptually simple technique for identifying the differences between one system state and another. In business it is often used to compare current performance with potential performance. In software development it is often used to compare the current system with a target system that offers some advantage. For our purposes, we used gap analysis to find the difference between current team practices and desired team practices and then to help the team define a strategy for moving from the current state to the desired state.
This is the general recipe we developed to guide these teams in a favorable direction.
1. Define the Current State
We want the team to tell us what practices they are using now. Our role as coach is simply to facilitate the collection of data. At the same time, we are watching for clues to the motivating factors behind the current choice of practices. For example, is the team aligned on the current set of agile practices or were they mandated by someone in the corporate hierarchy? Motivations can reveal additional opportunities for improvement.
Occasionally, we may need to ask leading questions when we detect omissions in the story. For example, if the team does not seem to be aware of a particular agile guideline such as small team size, we might ask a question about the size of the team or division into sub-teams to help make an issue more visible. These questions are best asked in a value-neutral manner.
2. Describe the Desired State
Next, we make a presentation describing the target process and recommended practices. Again, no value judgments are made regarding the current processes and practices. We simply present a vanilla case that is common agile practice in the organization. We answer questions as they come up. From the context we can determine which questions are best answered directly and which can be leveraged to elicit a comparison with the current state regarding both practices and motivations.
3. Facilitate the Gap Analysis
The third step is to invite the team to compare and contrast the current state with the desired state. We use fairly standard retrospective facilitation techniques here. Create an opportunity for each team member to contribute. Make it safe to speak. Un-invite authority figures if that will help. Keep a running list of differences on the whiteboard. We reserve the right to propose items at the end if we feel that important differences were not listed. The team can accept or reject our suggestions.
We keep a second list of “challenges” that the team may mention along the way. These are things that the team identifies as impediments to productivity but are not necessarily related to an agile process. Some examples are expensive deployments, a disengaged Product Owner, or high demands on the team for support of the current product. These may relate to the gaps or may be orthogonal. In either case, they may show up as additional opportunities for process improvement.
4. Prioritize the Gaps
At this point, we treat the list of differences much like a backlog and ask the team to prioritize them. The priority can be a multi-parameter function as it is with software features. Which items are easiest to implement? Which will have the biggest impact on improvements? Which are likely to be the least or most disruptive to the work already underway?
5. Define Action Items
Now that we have identified the gaps and their relative importance, what can we do to bridge each gap? Working with the prioritized list of differences between the current and the desired state, we invite the team to define action items. The action items may include self-assignment of gap owners and timelines for implementation. We may offer suggestions from experience or the literature. We test this before giving much “advice” because unsolicited recommendations are not necessarily welcome.
Action items also may include approaches to meeting the list of additional challenges we identified in the gap analysis. We stick to the general theme of process improvement rather than compliance to agile philosophies or practices.
Conclusion
This simple recipe for gap analysis is easy to follow but is full of challenges. Here are some keys to success:
- Do not assume that you know the best solution for a particular circumstance.
- Let the team own the discoveries, decisions, and action items.
- Encourage all team members to participate.
- Pay attention to both verbal and non-verbal clues to identify team relationships and other opportunities for improvement.
- Stretch the analysis over a few days. It may bring up complex issues that need some mental processing time.
