Thursday, April 26, 2012

Executive Guide to Peer Coaching

You have decided to go agile. You have delegated the responsibility to your staff. What should you do now?

A peer (fellow executive) approaches you from the business. They are upset. They have been told the team is doing their development is pairs. Your peer says, “Do I have to pay for pairing”?

Your organization has been doing agile for 6 months. Teams are functioning well and software is releasing quickly with high quality. Your peer says, “Your quality is too high, I would like to pay less and am willing to lower quality”.

Another peer approaches you and says, “Your teams are too ridged, they insist on using the agile practices, I need teams that are willing to compromise”.

How do you respond to these comments? More importantly, why are your peers making these statements to begin with?

Some companies subscribe to the myth that anyone can be a good executive if they know how to manage relationships, have executive presence and shape perceptions. Knowledge of your domain, practices, skills or technology isn’t necessary. Such organizations have a difficult time with excellence. Projects and transformations are frequently started but many stall and fail. Such companies are littered with projects that never completed successfully. It can be very difficult to lead what you don’t understand.

In the previous post, I identified a number of reason’s executives don’t coach their peers. In this post we will focus on what will happen if you don’t coach and more importantly, what sort of coaching you should provide to your peers.

Looking at the first comment, the misperception is that it will take a pair just as long to complete a card as one person. Having two developers complete a card means they have to pay more for development.  The person who made the comment is revealing his or her lack of knowledge of pairing. It is also an indication that the person making the comment has received insufficient, if any coaching.

A properly coached peer will know that a pair will complete a card in nearly half the time. That is because the bottleneck to development isn’t the number of keyboards or the typing speed of developers, it is problem solving. Two heads will solve a problem faster than one. The solution will be cleaner and require less lines of code. Given that two eyes have reviewed the code in real-time, the code will have significantly less defects. Thus, the pair is more likely to work on a new feature tomorrow instead of fixing what they broke today.

In addition, the knowledge transfer between team members will spread like a virus. This relates to the product, business domain, source code, practices and use of the tools. A new person in a pair can be effective nearly immediately instead of the six months it takes a person sitting in a cube.

Thus, an informed peer instead of expressing fear over additional costs should be pleased with the money and time saved because the team is effectively pairing. This is a much more enjoyable conversation to have.

As you can see, there is sufficient coaching that needs to take place to prepare your peers for the transformation to agile. If this is not done, the misunderstanding will lead to significant waste. It may also make your staff gun-shy. No one wants to make enemies in the executive ranks.

The second comment is amusing. We have learned that defects add to cost. The later you find defects, the more it costs to fix them. To lower cost you find and fix defects sooner or prevent them to begin with. The practices that are used to bring about a reduction in defects reduce cost and ensure that the team can spend all of its capacity delivering new features and not fixing yesterday’s mistakes.  I am unaware of any test methodology that allows one to filter on defects by severity or impact when developing software.  Mistaking proofing development is an effective way to reduce cost and increase a team’s productivity.

The person making the comment has revealed his or her lack of understanding of quality. They visualize and extended period of time to do additional testing. It is visualized that every defect on the list found late in the process much be fixed. For this reason, it is determined that it cost more to have high quality.

Such a person has never been coached with regards to the impact of pairing, test driven development, acceptance criteria and acceptance test drive development. It is unlikely your peer is aware of the automation of regression test thus regression tests are run daily. These practices enable software to be delivered with quality, faster and at a lower cost. But how are they to know if you did not provide coaching?

Are you prepared to coach your peer past these misconceptions? Better yet, are you able to anticipate this type of confusion and provide the coaching needed prior to the transformation?

The last comment is code for, “I don’t want to have to change the way we work. Can’t your agile team follow our process”?

Such a request is rooted in ignorance. Understanding agile and the benefits it brings has never been presented to your peer. If executives don’t understand agile, they will take such a comment at face value. They will decide that compromise is good and that the agile teams are being ridged. Such feedback can bring an agile transformation to a halt or destroy the effectiveness of teams that are already highly functioning.

Why would you want to compromise on cost, schedule, scope and quality? All should be motivated to bring the most value to the business at the lowest coast, shortest time, with the most features and highest quality. It is not about compromise, it is about continuous improvement. It has to be led by effective coaching.

Perhaps the most important coach in an agile and lean transformation is the executive coach. An enterprise agile and lean transformation needs a champion that has the clout to bring his or her peers up to speed to ensure the transformation occurs and is sustainable. Such coaching must come from at least one executive champion. Organizations are dynamic. Leaders come and go. Until the transformation becomes part of the organizations DNA, it requires an executive coach. An executive coach’s job is finished when his or her coaching is no longer needed. It is no longer needed when the system is in place and staffed by an organization where everyone coaches.

No comments:

Post a Comment