The Stepford Coaches
(For background on the origin of the term Stepford, please refer to the Wikipedia article.)
Background
Apologies in advance for a bit of a rant.
As I’ve mentioned many times before, I came to the Agile “world” from the Extreme Programming (XP) community. Agile became “a thing” several months after I learned about and started practicing XP. I had learned about the XP values, which are similar to those in the Agile Manifesto. I learned about the XP practices that included numerous technical practices intended to ensure that the highest possible quality software was being delivered. XP also had a focus on close collaboration with a person deemed to the the Customer for a team’s work, with the intention of ensuring that the high quality software was meeting a real business need.
This approach resonated strongly with me, since the values and principles and even some of the practices had already guided my career as a software developer up to that point in 2000. In nearly 20 years since I began practicing Extreme Programming, I’ve learned a ton about what helps teams work better together. In that time, though, very little has changed with respect to improving on XP’s original technical practices. I have seen no other approach that produces software of a similarly high level of quality without a prohibitively high cost in terms of time, people or tools (or a combination of those).
Get On With It!
I attended Agile Ottawa last night at which a local company talked about their massive Agile transformation across 90+ teams. There was some interesting content in the talk, although a good portion seemed like an infomercial for Atlassian products (which is a completely different rant!). I was struck by two particular aspects of the talk and one about the people, which I’ll dissect here.
The first aspect was when the speaker — a coach at this organization — talked about getting teams to adhere to the process they selected from the list of Scrum, Kanban or Scrumban (which he defined as Kanban with Scrum ceremonies every two weeks). He also talked about tools, tools, and more tools. I was perplexed by this, having heard something, somewhere about “individuals and interactions over processes and tools”.
One tool he discussed that wasn’t from Atlassian is called Comparative Agility, which leads into the second aspect of the talk that struck me.
The product’s site calls it, “A Powerful Continuous Improvement Platform”, which uses assessment questions across 8 different dimensions that indicate a group’s level of agility (as defined by the tool). To be fair, the dimensions and the assessment questions are ones that I’ve seen a number of times in my journey through the agile world. I’ve used similar tools, usually in a spreadsheet, to help teams identify where they could use help and where they were already doing well. So, I’m not totally averse to using this approach as a coach.
The speaker showed a screenshot from one team’s self-assessment, and two of the dimensions immediately stood out to me. Most of the individual assessment criteria were above “0” (meaning good), with one glaring exception… Technical Practices. I couldn’t see the specific questions that were used in the assessment, but 80–90% of the responses for that dimension were below 0.
Meanwhile, for the Quality dimension, every single question had a response indicating that it was good to really awesome! My internal response to that was, “Bullshit!”
But what I’m damned sure of is that, if the team is rating their use of good technical practices below 0, then whatever they’re doing now to ensure that quality is high is not sustainable.
I have absolutely no knowledge of the team for which the assessment was done, nor the work that they do. If they weren’t bullshitting in their assessment, I would suspect that whatever they were working on was relatively new and still amenable to manual testing. It’s also possible that the group had implemented some “through the UI” tests using Selenium or a similar tool. But what I’m damned sure of is that, if the team is rating their use of good technical practices below zero, then whatever they’re doing now to ensure that quality is high is not sustainable. Manual testing becomes more difficult as a product grows. Full manual regression tests can no longer be performed each sprint, for example, meaning that defects will escape sprints and may not be caught before a product ships to actual paying customers. Test automation is the grease for the agile wheel!
This point came up about halfway through the talk that lasted a bit over an hour. It was the only mention of technical practices in the whole talk. This leads to the aspect about the people I mentioned above.
I asked about this noticeable lack of focus on technical practices in the Q&A at the end, and the speaker said that the Agile Coaches in this organization don’t handle any of the technical stuff. There’s a Development Centre of Expertise (CoE) that specifically handles the improvement of software engineering practices. I pointed out that exactly half of the principles from the manifesto are related to software, with one specifically calling out technical excellence. The response (paraphrased) was:
“That’s up to the Development CoE. We Agile Coaches focus on process and not the technical practices”
Sigh.
The session was also attended by several other coaches from this organization. Every one of them had a similar “vibe” to them, and one that I see quite often in the current generation of Agile Coaches:
- Boundless enthusiasm!
- Nothing but smiles!
- Everything is great!
- Scrum is wonderful!
- We only work with the process!
While there’s absolutely nothing wrong with optimism and enthusiasm, it strikes me as odd that I see the “everything is great” veneer and yet I also see numerous indications that all is not well at this organization. Any gains in productivity they have seen thus far will be eroded over time due to the divorce of technical practices from the overall process, and especially due to the lack of emphasis on technical excellence by the Agile Coaches.
Yet the smiling and enthusiasm for Scrum and other approaches that eschew focus on technical excellence persists.
Stepford Coaches.
