Article: Mind The Gap

Mind The Gap: Let a Coach Help You Bridge the Gap between Book-Learning and Your Team's Reality

"In theory there is no difference between theory and practice. But, in practice, there is." – Jan L. A. van de Snepscheut

Agile Rules helps businesses identify which agile methodologies are best suited to their situation and company culture, and guides clients through the change process. This paper examines the decision of whether to use a coach, given that a decision to use Extreme Programming (a leading agile methodology) has already been made.

Some teams adopt Extreme Programming (XP) without any outside help. Mine did; I introduced the practices and shepherded them along till the team took true ownership of the new process. But many teams try XP and are disappointed. Success depends on a mix of technical skills and interpersonal communication skills. This article is intended to explain what XP coaching is, what the potential hazards are, and to help readers decide whether they can benefit from the help of a coach on their path to adopting XP.

How to tell when you Don't need a Coach

• Current software development process
• Condition of the code base
• Interpersonal dynamics of the team
• Management

Below, we'll start a worksheet for checking off each of the above areas.

Current Practices

"Freeing the Slave with Two Masters: An Embedded Programming Team's Transition to XP" which can be found here

If you have decent unit tests (covering at least 70% of the code) that can be automated to run daily, then check off this item. It would be nice to have some of the other XP practices, but they'll get covered in the next sections.

Code Base

Can you add features with a reasonable expectation that a nest of new bugs won't pop up?

Do you have someone on the team who understands all of the design? (It doesn't have to be a detailed understanding of everything, just a solid overview plus good knowledge of the tricky areas.)

If you can answer 'yes' to the above questions, check this one off. So far, so good.

Interpersonal Dynamics

If your team members were told now that anyone on the team is allowed to modify any of the code, so long as they test it, would there be strong objections?

Is there a dominant person on the team who intimidates others?

If you answer 'yes' to the above, you have some team-building to do. It's "touchy-feely" work that most techies dread, but it is crucial if the team is to function as a team. They must be able to make that leap – it's the heart of XP. By the way, the above is NOT meant to be an exhaustive list of the interpersonal dysfunctionalities to be wary of.

Check off this item if your team members generally work well together, and can be persuaded to a new view by the facts of a situation.

Management

What is the nature of your team's relationship to management? By "management" I mean those who are sponsoring the project, and who decide what features should get implemented.

Have you fallen into a pattern where they never believe your estimates and just issue a deadline and threats of dire consequences if you fail to meet it? Do new "requirements" fall on you from all directions like rain from the sky?

On the other hand, if there is a bond of respect for each other's role, and capability for give-and-take when working out schedules, estimates, etc. then you can check off this item. You can also check it off if management appears not to know or care what you're doing. If your management is this detached from your practices then you can bring in XP "under the radar". This can lead to better software that will improve your working relationship with your managers.

If you've checked off all the items listed, then proceed confidently on your way to XP coach-free.

How to tell when you Do need a Coach

How many of the items in the previous section did you not check off? If your current process is very much "big design up front", with modules owned by individuals with varying dedication to unit testing, then it may be difficult to map out a path to XP without the help of a coach. If the code base is a problem, you may need to break out key areas of the code base and create tests for them. A coach can help you create tests for legacy code. If the habits of team members are going to become a stumbling block in implementing XP, a coach can help.

If you're dealing with issues that stop you from improving your software development process, you need to communicate with your management about it. Sometimes an outside perspective can be very helpful. Contact us. We may be able to help.

If you believe that you must take a few pieces from XP, a few from another practice, and so on in order to tailor the set of practices for your situation, don't. Your sense that your situation is unique is correct, but the best way to adapt a methodology to your team is to stay with a proven, cohesive set of practices and let a coach help you to "mind the gap" between the books and your reality. It's not crucial to decide beforehand that pure XP is where you'll end up. The point is to improve.

If you create a new methodology, you're adding risk. OK, what if you feel XP just isn't the best fit for your company? We can help you toward a more general, though agile, process. Generally though, you won't really know whether XP is right for you until you start down the path of adding agile processes. The important thing is that these practices will help you improve immediately.

If you think the only way to move to XP is by taking a big plunge into all of the practices at once, that's not so. It may be the most efficient way by some measures and some well-established consulting firms recommend it highly. However if you or your people are not ready to take such a leap then you can go step by step. But the sequence of steps matters, and again here is where a coach can help.

Ironically, those teams who most need help have a bad relationship with their management. The downward spiral of poor estimates, mistakes, mistrust, imposed deadlines, etc. cuts off constructive communication. If this is your situation, then the most important thing you can do is find a way to improve that relationship. That will open doors to the use of new software methods, and to getting coaching, if appropriate.

What will a Coach actually do?

It's not possible to say in detail because every situation is so different. A coach from Agile Rules will look at the situation and give you objective advice about how to improve it step by step. This includes technical as well as people issues. For example, if there is disagreement within the team on a question about the software design, we'd bring the focus up a level and ask what are the pros and cons of the proposed paths. Then we'd help the team apply the "simplest thing that could possibly work" idea.

A coach will help you do any of the practices that you have difficulty with. The key is that the coach doesn't make herself (or himself) indispensable. The whole idea is to get a 100% knowledge transfer. Our goal is to enable teams to function on their own, confidently using the XP practices without us. What if you're not sure you want to use all of the XP practices? No problem – the key is to do what makes business sense and technical sense for your situation. The bottom line is that each practice should prove its worth, and the software team is the judge.

A coach will make sure your management can see the business value in improving your software processes. Helping to improve communication between the software team and management is part of the job. The coach will watch over two fundamental things: the team's relationship to the code base, and management's relationship with the team. Both of these have to be healthy for you to get that "greater than the sum of the parts" power XP can deliver.

Conclusion

When I got my team to transition to XP, I had many conditions stacked in my favor. I had been keenly interested in software "best practices" for years and had been using my own "custom brew" of the ones I'd picked up on previous projects. I had a sense of what could work, and what just wasn't worth the effort.

I was confident that I could persuade my team of each of the new practices on its merits – not because it's some new bandwagon everyone else was jumping on. I believed that we could build trust between the software team and management by delivering high quality code. We did do it, though it was anything but easy.

With all of that said, I still am keenly aware of how much luck was involved. I did learn XP from a book (Kent Beck's Extreme Programming Explained) without any sort of external assistance. I didn't even know anyone else who was using XP. I suppose my prior experience adopting best practices helped me to make most of the decisions correctly. Looking back, I know I could've benefitted from having a coach.