Michael James is on a rant against Agile Coaching as it often appears to be practiced, but what he describes doesn’t sound much better, to me.
Michael describes Agile Coaching as “push[ing] processes and ways of working on teams,” and “trying to ‘change management culture.'” He suggests “starting with a clear system optimization goal stated again and again from upper management.” Never mind that this, itself, is an example of trying to change management culture, assuming that’s not what they’re already doing.
More and more, I see advertisements and hear people asking for a Coach to come for a period of time and help their organization on a full-time basis. They seem to assume that it’s necessary to Coach the team 5 days a week, every week. This makes little sense to me.
Teams need time to acclimate to new knowledge. They need to try it on their own, making decisions without immediate help. Otherwise they come to depend on the coach making the decisions, and they don’t learn how to make them, themselves. I’ve seen this happen when I’ve been working too steadily with one team.
It’s also important to limit the presentation of new information to the rate at which it can be absorbed. Time the team spends practicing without the presence of the coach is an important part of this absorption. Without such “soak time,” the team will get lost in the details, trying to climb the proficiency ladder without learning to practice the simple things fluently.
If you try to go faster than you can, you’ll only end up going slower.
Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.
I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.
This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.
I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?
This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them. Read More
I’ve heard stories where organizations have “tried Agile” and the results were so bad that they’ll never make that mistake again. In some of these stories the blame is laid at the feet of bad coaches. In some it’s blamed on lack of coaching. In some, the blame is placed on clients who aren’t ready for Agile . If blame is to be lodged, then any of these will do.
The more interesting question, to my mind, is how can we achieve a better result. Read More
I’ve just spent the past week at Junior Sailing Camp, helping kids circa age 10 become better sailors. At this age, they’ve learned many of the basic concepts: that pushing the tiller to starboard turns the boat to port, that they need to pull the sail in when going upwind, and let it out when going down. Yet they often struggle to get the boat going in varied conditions. They steer too vigorously in light air or choppy waters, killing the delicate momentum they’ve achieved. They position the sail inefficiently–sufficient for a moderate breeze, but insufficient for zephyrs. And in heavier air, the wrong sail trim may result in an impromptu capsize drill.
Much of my coaching depends on helping them observe these varied conditions and how the results of their actions are affected by them. Their current skills work fine when the conditions match the way they practice them. When conditions change, the same actions fail. Without keen observation, the cause of that failure is a puzzle.
I’m teaching them to see the wind. Read More
How long does it take to take a team from where they are to becoming an Agile team? Of course, that depends on many things, including where they are and how badly they want to succeed at Agile. It’s reasonable to think they can make a transition in six short months.
If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer. If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.
When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.
Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.
Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? Read More
A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started. Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization. At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.” The earlier post was a description what an Agile project needs. This one is a recipe for creating what an Agile project needs. Read More
Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question. And so I answer,
That people could ask for, and could accept, the help they need and want. Read More
A few weeks back, in a conversation with a colleague, I raised some issues that were important to me. Well, I tried to raise them.
“Don’t worry about that. Besides, I’m working on these other issues that are more important.”
That response reassured me–NOT! Read More