I found a tweet I saw this morning rather disconcerting:
I just completed a 4-month coaching contract in which I spent 4 days a week with a team doing hands-on development, testing and process coaching work. This team didn't ask to "go Agile", their management picked their project as the next one after the pilot. According to Daniel's assertions, this situation was ripe for failure because the approach was mandated rather than accepted by the team.
When I arrived they were open to trying new approaches and very receptive to pretty well anything I suggested. I didn't need to sell concepts like Test-Driven Development or functional testing with Cucumber. I had no trouble teaching the group how to split Stories into tiny, wafer-thin increments with just enough functionality to be valuable. There was no resistance to eschewing Story estimates of any kind, and simply counting completed stories at the end of an iteration. The product manager latched onto the Story Map concept very easily, as did the team. I facilitated a number of retrospectives, then turned over that role to the team itself.
When I left, I was confident that the group would continue to provide valuable, high quality software that met the immediate needs of the people who would be consuming it. I was confident that the group would be working on the most important features, avoiding gold plating and keeping technical debt to a minimum. I was confident that they would do all of this at a sustainable pace, and would continue to build trust with the people in the business.
Daniel suggests that all of this is gambling because it was mandated:
First, I understand that Daniel is positioning mainstream coaching this way in order to market his approach and services. Second, I consider his approach using OpenSpace to be a valuable part of my own toolbox. Third, I'm sure there are companies that are more interested in making money than providing value.
To Daniel's defence, I have worked in organizations where Agile was mandated without any explanation as to why. Not surprisingly, those initiatives were challenged at best. I've also coached in situations where Agile was mandated, but clear, concise reasons were given. Those generally worked just fine. I've also seen grassroots-led initiatives, Daniel's sweet spot, fail because they didn't win the support of management beyond the first level, regardless of any success.
So, what are the keys here? My experience suggests:
The experience a coach brings allows that person who adjust to the context of the group with which they're working. The scrapes and bruises incurred while obtaining that experience differentiates a coach from a brand new CSM, for example, by giving him or her the ability to know when to deviate from what is taught. Finally, coaches who have seen and experienced failure or challenged situations will be able to see those situations developing long before most other people and can help get a group back onto a smoother path.
I actually don't strive to teach a group a specific method or practices, but instead provide value by coaching in areas that need the most attention. For example, if I insist that all developers use pair programming all the time when product management is the group's real pain point, am I providing value? Similarly, if I insist on rigidly following the Scrum practices while defects and technical debt are spiralling out of control, am I providing value?
As a concrete example, the group with whom I just worked had quality issues with their previous release. With the new release (which was a new code base), we used TDD and BDD from the start. There was a learning curve, but the whole team improved quality tremendously. There were far fewer instances of missed or misunderstood requirements or features, and even fewer simple programming mistakes. After the high stress of the previous release, the next one was almost relaxed. When I started teaching TDD & BDD to the group, I knew from experience that the final outcome would be a low-stress release. I knew that, if the group stuck with it, quality would be orders of magnitude better. As the project progressed, so did the team's confidence that I wasn't just spouting BS and actually knew what I was talking about!
So, while I do agree with Daniel's assertions to a point, I have first-person counterexamples. The good news is that I know quite a few other coaches who work from the perspective of providing value versus teaching a process. Some of that group may charge $2500 per day or more. The value that they provide, though, is worth much, much more than that.
An embedded #agile coach billing $2500 a day for 221 days can in theory generate this much per yr: $552,500. Q: What does the client get?
— Daniel Mezick (@DanielMezick) August 12, 2014
The clear implication is that coaches, like all consultants, follow the mantra, "If you can't be part of the solution, there's plenty of money to be made prolonging the problem." In the case of this tweet and numerous others in his Twitter stream, Daniel is suggesting that companies that provide coaching services are simply in the business to make a buck. Any value provided is a nice bonus.I just completed a 4-month coaching contract in which I spent 4 days a week with a team doing hands-on development, testing and process coaching work. This team didn't ask to "go Agile", their management picked their project as the next one after the pilot. According to Daniel's assertions, this situation was ripe for failure because the approach was mandated rather than accepted by the team.
When I arrived they were open to trying new approaches and very receptive to pretty well anything I suggested. I didn't need to sell concepts like Test-Driven Development or functional testing with Cucumber. I had no trouble teaching the group how to split Stories into tiny, wafer-thin increments with just enough functionality to be valuable. There was no resistance to eschewing Story estimates of any kind, and simply counting completed stories at the end of an iteration. The product manager latched onto the Story Map concept very easily, as did the team. I facilitated a number of retrospectives, then turned over that role to the team itself.
When I left, I was confident that the group would continue to provide valuable, high quality software that met the immediate needs of the people who would be consuming it. I was confident that the group would be working on the most important features, avoiding gold plating and keeping technical debt to a minimum. I was confident that they would do all of this at a sustainable pace, and would continue to build trust with the people in the business.
Daniel suggests that all of this is gambling because it was mandated:
Most #agile adoptions are mandates-of-specific-practices by #management. This is a recipe for a very large & very POOR bet. It's gambling!
— Daniel Mezick (@DanielMezick) August 11, 2014
First, I understand that Daniel is positioning mainstream coaching this way in order to market his approach and services. Second, I consider his approach using OpenSpace to be a valuable part of my own toolbox. Third, I'm sure there are companies that are more interested in making money than providing value.
To Daniel's defence, I have worked in organizations where Agile was mandated without any explanation as to why. Not surprisingly, those initiatives were challenged at best. I've also coached in situations where Agile was mandated, but clear, concise reasons were given. Those generally worked just fine. I've also seen grassroots-led initiatives, Daniel's sweet spot, fail because they didn't win the support of management beyond the first level, regardless of any success.
So, what are the keys here? My experience suggests:
- Coaching provides value when it's a "teach the people to fish" endeavour, where the coach renders him or herself unnecessary for a given team by transferring skills and knowledge;
- Mandated or otherwise, the people directly affected need to know why they're being asked to change; if they aren't feeling any pain with their current approach, they will resist change;
- If a group isn't feeling any pain with their current approach, you need to ask why they should change at all;
- Agile methods provide a wide variety of tools to use when coaching a group; it's almost silly to assume that one "canned" approach is appropriate for anything more than a starting point;
- Regardless of all that, being effective at delivering software is what really matters and that is extremely dependent on a group's context, i.e. domain, people, technology, etc.
The experience a coach brings allows that person who adjust to the context of the group with which they're working. The scrapes and bruises incurred while obtaining that experience differentiates a coach from a brand new CSM, for example, by giving him or her the ability to know when to deviate from what is taught. Finally, coaches who have seen and experienced failure or challenged situations will be able to see those situations developing long before most other people and can help get a group back onto a smoother path.
I actually don't strive to teach a group a specific method or practices, but instead provide value by coaching in areas that need the most attention. For example, if I insist that all developers use pair programming all the time when product management is the group's real pain point, am I providing value? Similarly, if I insist on rigidly following the Scrum practices while defects and technical debt are spiralling out of control, am I providing value?
As a concrete example, the group with whom I just worked had quality issues with their previous release. With the new release (which was a new code base), we used TDD and BDD from the start. There was a learning curve, but the whole team improved quality tremendously. There were far fewer instances of missed or misunderstood requirements or features, and even fewer simple programming mistakes. After the high stress of the previous release, the next one was almost relaxed. When I started teaching TDD & BDD to the group, I knew from experience that the final outcome would be a low-stress release. I knew that, if the group stuck with it, quality would be orders of magnitude better. As the project progressed, so did the team's confidence that I wasn't just spouting BS and actually knew what I was talking about!
So, while I do agree with Daniel's assertions to a point, I have first-person counterexamples. The good news is that I know quite a few other coaches who work from the perspective of providing value versus teaching a process. Some of that group may charge $2500 per day or more. The value that they provide, though, is worth much, much more than that.
Comments