Coaches for Agile teams and organizations is a growing profession. I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams. I have recently started a Wiki to capture some of this information. (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.) This is an open invitation to participate in the wiki. I won’t make it fully open (like wikipedia), instead, it will be by invitation. Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.
Michael Badali, a good friend of mine, has asked a great question on LinkedIn: What is your Backlog for Agile Transformation?. From his question:
While I think that Band-Aid off quick is more likely to be successful than Band-Aid off slow, often Agile Coaches & Leaders are put in the position of Kaizen instead of Kaikaku. When asked for a detailed waterfall plan and schedule on how to become Agile… I generally refuse and create an Agile Transformation Backlog – a prioritized list of things that need to be done to become Agile. Please share your prioritized list of things that need to be done to be Agile.
In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later. He describes five types of people in relation to how they adopt new products:
- Innovators – always actively seeking out and trying cutting edge new products.
- Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
- Then there is the Chasm – many products fail here.
- Early Majority – willing to try new things but need strong testimonials or real-world proof.
- Late Majority – require time-tested proof before they will adopt a product.
- Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.
This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.
Implications of the “Chasm” Model
An organization attempting to do an Agile Transformation [Kotter's 8-Step Change Model] should understand how to use this model to ensure long-term success. This diagram illustrates the concepts (click on it to see it full size):
First, the organization should start the transformation by finding the innovators and early adopters. These people can then be recruited to run the initial pilot projects. They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility. If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment. Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.
In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups. These people will tend to drag on the results of the pilot projects. This is a common mistake in running a pilot program and leads to discouraging results. One way to help filter between these two groups is simply to ask for volunteers for the pilot projects. Innovators and early adopters will be much more likely to volunteer for a new initiative.
After the pilot projects have shown some good results, the next step is to go the general roll-out. In this step, you are now working with the early and late majority. These people need much more substantial support for a change of this nature. They will require intensive training, and hand-holding in the form of coaching and mentoring. This hand-holding can come partially from your innovators and early adopters. Some of the participants in the pilot projects will have the desire to share their success. From these, you need to carefully select and prepare a few who will act as internal coaches. If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.
The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated. This evidence partially comes from your pilot projects. However, this may not be sufficient. There are two other important sources of evidence for this group: the leadership team and external experts.
The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team. The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar. As well, this “Agile Transformation Team” must make itself very visible during the general roll-out. This can be done with communication and by taking up visible residence in a central conference room or bullpen. As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.
The second source of evidence comes from external sources. Published case studies are one valuable source. However, there is a huge value in a visible management investment in external support from recognized experts. This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like. When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.
The final stage of a roll-out is to deal with the laggards. For the most part this is a do-or-die proposition for these people. Either get with the program and engage like a committed employee or leave the organization. If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.
For some organizations, this transformation process can take many years. An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years. Often it will be longer. Good luck on your agile transformation effort!
Over the years working with clients, I’ve discovered that there is often confusion about what are the differences between mentoring, coaching and training. We all know that these are ways for an expert or experienced individual to help people do something more effectively. That’s the similarity. But the differences…
Mentoring is generally an informal relationship between two people. A mentor will do many of the same things as a coach or even someone who is a trainer, but there is no formal obligation on the part of either party. A mentoring relationship often develops gradually from a friendship or a professional association, intensifies as the mentor discovers he has valuable insight and experience to share, and as the person being mentored discovers his desire to learn from the mentor. The two people will at some point recognize the special nature of their relationship, but may not name it. And as life circumstances change, the relationship will gradually de-intensify. It will often turn into a friendship of peers.
In working on this article, I read a number of other articles about the differences between coaching and mentoring. All of them talk about how a coach does not provide solutions or answers. I beg to differ. Think of an athletic coach. An athletic coach definitely does not simply ask the athlete questions and help them bring out their own solutions to problems. An athletic coach helps point out problems, makes very definite suggestions, and sometimes even intervenes physically to help the athlete do the right thing. So what is coaching? The main difference is in terms of formality.
A coach is a coach from the start of the relationship with the person being coached. The person being coached has a specific goal to achieve. It can be long term or short term, but it is specific. The coach is there to help that person meet their goal. Once the goal is met, the relationship is re-evaluated.
Here are some of the ways that coaching can happen (actually, mentors do these things too):
- The Socratic Coach – asks lots of probing questions.
- The Hands-On Coach – shows people a way to solve a problem, but leaves it to the individual to mimic or do something different.
- The Intervention Coach – mostly observes and at key moments intervenes to help an individual choose a specific path of action.
- The Guiding Coach – provides constant (usually gentle) reminders to help an individual keep withing a specific path of action (guide rails).
Classroom training is the type of training we most often think of, but it is not the only kind. There is also on-the-job training and of course all sorts of e-learning methods of training. Training is very formal, should have well-defined learning objectives, and is often relatively brief as compared to coaching or mentoring.
Training can also include many of the types of interaction that are found in a coaching environment, but there is a very strong focus on the trainer being a subject matter expert. The trainer has extensive experience or knowledge in the subject that is being delivered in the training. It is expected that the participants in the training learn from the trainer – there is knowledge transfer. How this happens can be very flexible, of course, and good training is never just a speaker standing at the front of the room and lecturing for the whole time. Discussion, simulations, case studies, and other forms of interaction are critical for an effective training experience.
Some other links:
James Shore wrote a great post about the problems he is seeing with agile adoptions that start with Scrum called the Decline and Fall of Agile. Please please please (pretty please) read it before you read what I am about to write here! I agree with what James is saying 100%.
Now, let’s hear the truth:
Scrum is really really hard! Doing Scrum well is like quitting a heavy, long addiction (I think). Don’t ever make the mistake that because Scrum is simple (lack of complexity) that it is somehow therefore easy (lack of effort).
Doing Scrum properly takes:
sacrifice – sacrifice of our ways of thinking, our habits, our comfort
wisdom – wisdom to see the small improvements while struggling with the humongeous ones
and most importantly,
truthfulness – honesty to see and say the truth, integrity to act on the truth, detachment to avoid believing in what you want instead of what is real, courage to continue even when things aren’t perfect or easy
Scrum depends heavily on commitment both at the small scale of an individual committing to a small piece of work, and at the large scale of an organization committing to real deep cultural change. Without that entire spectrum of commitment, it is unlikely that adopting Scrum will be anything but the latest fad imposed by management or done stealthily by staff.
But Scrum isn’t the only “agile” method. As James points out, the engineering practices of Extreme Programming such as pair programming, test driven development, continuous integration, evolutionary design and refactoring are all critical. Do they have to be done and perfected first? No. But eventually, if you are using Scrum to build software (not everyone is), they do have to be done.
As a Certified Scrum Trainer, I have always emphasized how Scrum is hard, and how being a ScrumMaster is very very very hard. This is why my training class is three days instead of two. This is why I don’t encourage anyone to come to it, only people who will be ScrumMasters. This is why after the first day of my course, most students are actually feeling quite discouraged!!! It takes three days minimum for people to understand and process the incredible shift in mental model. And of course, even after three days, it is oh so easy to revert back to our normal thinking habits.
So what should people do? Do Scrum by the book. Yes that means putting a whole team in a single room. Yes it means that you have to really remove obstacles, and fast! Yes that means that your teams actually have to be cross functional (and not just in the weak sense of multi-skilled developers). Yes that means that it – will – take – a – long – time – to – get – it – right!!!!
And please, it is so worth getting help beyond just the training! If you think that I’m just trying to promote my own coaching services, please go check out:
They all have great coaches and I would absolutely way rather see you succeed than believe that I am just trying to promote my own business.
Someone recently said to me that I should offer individual coaching assistance to people based on Agile Work. This would be completely non-technical life/profession style coaching. It’s an interesting idea. I don’t think I’m quite ready for it, but here are a few links to coaching, life improvement, and related things.
Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.
Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.
Okay… I’ll bite.
I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I’m starting to see and hear some of the results of this training. There are a couple specific “smells” that I have become aware of.
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
Today I had a very interesting and unique opportunity. I went through my agile project management training materials with a single individual instead of a class. Was it training, or was it coaching?
On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!
Sometimes an agile team is innundated (or maybe just slightly distracted) by requests for individuals on the team to do work for people or groups outside the team’s official stakeholders. This can happen, for example, in a corporate culture that promotes the exchange of favors. This past weekend at our Agile Coach’s gathering, Deborah Hartmann shared her method of detecting, exposing and discouraging this unofficial work.
The coach’s gathering last weekend also got me thinking about the ethics of Agile Work and coaching. Is it okay to use agile methods for destructive purposes?
In Jean Tabaka’s new book, “Collaboration Explained : Facilitation Skills for Software Project Leaders“, she describes several methods of collaboratively prioritizing a list of items (for example a project’s work item list). The methods she suggests are excellent, and I would strongly recommend the book. However, there are a couple variations and additional methods that I have used successfully that I would like to share.