In a couple of weeks, I am going to be performing a formal review of our progress implementing agile software development practices for one of our sub-teams. While agile is a deeply ingrained methodology for most of our team, this one area has some unique characteristics that make adoption both interesting and challenging. Indeed, the team's size (greater than 80 individuals and growing), the inter-organizational and leadership dynamics in play, and the technical environment (SAP) mean that success is not assured. Nevertheless, there does not appear to be anything in this environment that would rule out the implementation of some form of agile software development. While all environments are not created equal, higher productivity, higher quality, and increased developer and customer satisfaction have accrued from past implementations.
Selecting What to Review and How to Review It
Preparing for a review of this magnitude can be stressful. Each decision made in preparation has the potential to expose useful information and provide a deeper understanding of the team and the environment in which they are now working. Unfortunately, those same decisions may inadvertently suppress useful information, resulting in a faulty analysis that generates incorrect conclusions and follow-on actions. A deep understanding is necessary to determine what is truly working well and what is just not working at all—it has ramifications on what happens next.
Multifaceted Approach. Gathering the correct information is essential for any successful review. Since information can be lurking in unexpected places, the best approach would seem to be a multifaceted one. That is, using several different techniques may be the best way to reduce the possibility of missing something important. To best understand what the team is experiencing on a daily basis, staying away from using the review period to question people about performance metrics would also seem prudent. Those types of questions tend to make people uncomfortable and, more importantly, a team that has just begun using agile is not going to fully understand what those metrics mean or how they are influenced. Instead, all of the review techniques selected thus far are intended to pull meaning from each of the interpersonal interactions. They are also intended to help the team better understand their own performance and allow them to think through what they might need to do to make this successful: a tall order.
The Mini Retrospective. Those familiar with agile have most likely heard of the project retrospective. Nevertheless, most have never actually participated in one—at least not along the lines proposed by Norm Kerth [1]. A full-blown review is time consuming, but rewarding. On the other hand, this review is not about a single successful or troubled project (not yet, anyway). Instead, its focus is on gathering enough information about the new methodology surrounding many the projects in this area and to understand where things are going well or poorly. Variations of two exercises that Kerth proposes are well suited to enable the type of breakthrough thinking that will allow the team to explore what they are experiencing: the "develop a time line" exercise [1 pp. 121-126] and the "emotions seismograph" exercise [1 pp. 127-130]. For good or ill, this part of the review is being called a "mini retrospective." While the name may be a bit generous, the goal of deeply understanding what the team is experiencing is the same. Because only a couple of hours are allocated for each scrum team, there there will need to be some work done by the team prior to the discussion so that the entire time is not spent creating the time line.
Talk to the Individuals. You can learn a lot from a conversation if you ask open-ended questions and listen carefully. When your attention is on more than a person's words you become aware of their underlying mood, energy level, and attitude. You can also develop a better understanding of the person you are listening to. This is called Global Listening—it is sometimes also referred to as level three listening. It seems reasonable to conclude that the ability to listen will determine whether these sessions are ultimately successful. (As an aside, I learned about the three types of listening from a class I took earlier this year. I found a pretty good summary of the three levels themselves, if you are interested [2]).
Getting the Team Together. As important as individual conversations with selected team members are, it is just as important to schedule time with the various sub-teams within the wider team to gain insight into the entire group—insight that might not otherwise appear in a one-on-one setting. This group has a complex matrix management structure. That means that there are several different types of groups from which to gather information: the scrums themselves, the management team, the functional leadership team, and the business team, to name a few. These types of gatherings are often called round tables after the table used by King Arthur and his knights: such a table does not inherently grant precedence to any one person. That description seems appropriate for this part of the team review. By maintaining equanimity, individuals are given a forum and the freedom to discuss collective matters of importance about the team, the methodology, or any other pertinent topic.
Let the Leader Present Their Findings. It always seems best to have the people leading a team take responsibility and ownership for conveying the major themes discussed during the early part of the review with their local management team. This may be somewhat counter-intuitive, but the theory is that by having the team's leader present the findings that they and their team worked so hard to identify will help ensure that the information is complete and accurate. This has the added benefit of giving them visibility to their local management team and giving an overall insight into their dedication and competence.
Concluding Thoughts
The aforementioned techniques are intended to cover an array of individual and group meetings during the review. Missing is how we intend to conduct an analysis of the information gathered and how conclusions will be drawn. While these rather important topics remain partially open as of this writing, one thing seems clear: a tentative summary of findings should be available to the team quickly -- before the on-site review period concludes. This will give the review team additional feedback and serve as a further assurance that something important was not missed.
In a few weeks, I will know whether any of this was effective. Either way, I am sure I will learn something.
References
[1] N. L. Kerth, Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.
[2] S. Smith, “The Three Levels of Listening”, http://careersintheory.wordpress.com/2009/09/08/three-levels-of-listening/, 2009, Accessed September 19, 2010.
