What Position Do You Play?


Micheleen Merritt explains that as an agile coach, you need to take into account all of the participants of a team, not just the developers. If you aren’t acknowledging the quality assurance analysts, business analysts, and product owners, you aren’t coaching the whole team.

I recently attended an event hosted by Johanna Rothman and Gil Broza, and I couldn’t be happier to have participated. I went in with the goal of learning how to better handle difficult situations on a (relatively) mature agile team, but what I came out with was far more introspective and focused on the formation of a team. As one feels after having attended an off-site training or conference session, I came back ready to save the world. However, because I understood that stating this would be met with rigorous eye rolls and would generally be ignored, I gave it a lot more thought before declaring that I had all the answers. What you see here is the result of my musings.

The drive within an IT organization to adopt agile development practices often comes from management, developers, or both, with other roles sometimes being dragged along, kicking and screaming. Far from feeling empowered by the idea of a self-directed team, these folks may feel that they aren't being heard and their needs aren't being met. When a coach goes through the process of helping a development team "go agile," he needs to make sure that he has all the players accounted for. Imagine the coach of a seasoned soccer team. Each player is accustomed to his position and plays it well. Now, take that soccer team and convert it to a hockey team; this includes the same players, and the same premise of the game, which is to launch an object to the opposite end of the playing area in order to score a goal. The deliverable is now smaller, but it still has to be deposited into the opposite goal in order to score. But now everyone is learning to do that on skates instead of cleats, and no one is sure of their footing.

Now here's where the coach comes in. What if he only coached the wingers and centers? Let's imagine that he, in his glory days, was a center himself, so he is most comfortable with that position. He can't spend all of his time and effort focusing only on the team members who most often score the goals. He has an entire team to coach. Goalies are just as valuable to the performance of the team.

Unfortunately, this seems all too easy to do when coaching an agile team. Generally speaking, it seems that a vast majority of agile coaches come from a background in writing code. Understandably, that makes it easier for them to identify with the developers on the team, but teams are also made up of quality assurance analysts, business analysts, and product owners. If we aren't taking them into account during an agile transformation, we aren't coaching the whole team.

Recognize that, while you may be delivering the good news about agile, not everyone is going to see it that way. (This applies to any individual in the organization who is content with the status quo.) Processes like waterfall feel safe and familiar. Yes, we all know what great results we can get from shorter iterations and more frequent deliveries, but to an analyst who has thrown documentation over a wall at developers for years, lighter, frequently-changing requirements sound overwhelming and, quite frankly, scary. Acceptance test-driven development sounds like pure Nirvana, until you realize that the only ones on-hand with the skills to write the automation code are the developers; to a naturally skeptical QA analyst, this sounds more like the fox guarding the henhouse.

Be mindful of the first tenet of agile: Individuals and interactions over processes and tools. Recognize that these individuals are people first, team members second. Spend more time with those who are the most reluctant to accept change and make sure their concerns are addressed. They're going to need more support during the chaos of turning their process on its head. The desire for quick results is understandable, especially when the mandate to adopt these practices comes out of a push for better software faster, but this may be a case for slowing down in order to speed up.

Taking the time early in the change cycle to bring everyone on board and up to speed may save time, money, and pain in the long run. Pretty soon, your goalie will stop showing up at the ice rink with cleats on, and the team will be more productive for it.

User Comments

Leyton Collins's picture

Hi Mickey, Great article -- love the reference to 'go slow to go fast'. :-)

June 1, 2013 - 12:54pm
Mickey Merritt's picture

Thanks! It's something that I believe applies to many areas in life. It's the "measure twice, cut once" principle. A little more work up-front pays of greatly later.

June 6, 2013 - 9:57pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.