The Alternative To Agile Coaches

If you’ve been following the news recently, you probably saw that one of the large financial companies in the US made the unusual decision to eliminate their entire Agile job family (1100 people).

I don’t have any inside information on what was behind this, so I can only guess, but after my last article I did receive quite a few notes from people asking what this might mean more broadly for our industry?

A couple of months before this announcement, I gave a talk to Agile coaches at the request of Crisp. In that talk, I discussed two different product team archetypes, team red and team blue.

Team Red has a certified Agile Coach, Scrum Master, and Product Owner, and they diligently follow all Agile ceremonies.  Yet the team is not empowered in any meaningful sense (they are a pure feature team), and they release once a month at best, usually quarterly.

Team Blue thinks Agile as it’s practiced in so much of the industry is ridiculous.  There are no Agile coaches, no Scrum Masters, and their product managers scoff at the idea of a Product Owner.  Yet, they are truly empowered, given problems to solve, and focused on outcomes, and they have been doing CI/CD (continuous integration and continuous deployment) for literally years.

So which team is actually Agile in any meaningful sense?

So if Team Blue is actually Agile, yet they don’t have any Agile coaches and never have, how did they become this way?

The answer is that this is what competent managers do at good product companies.

The engineering managers (along with the more senior engineers) have a responsibility to coach and develop their engineers to learn difficult skills such as getting to the point where the team can ship frequent, small, reliable, uncoupled releases.

Similarly, the managers of product management and product design have a responsibility to coach and develop their product managers and product designers to work with engineering to consistently and responsibly discover solutions to the problems they’ve been asked to solve. 

If you’ve never done the work to get production software to the point where you can reliably release on demand, or get your product discovery skills to the point where you can quickly address the product risks and discover effective solutions, then you may think this is easy.  But it’s not.

If whomever is coaching the product team doesn’t have the actual hands-on experience, it will be very difficult for them to truly help the team.

If you have someone with the title Agile Coach that doesn’t actually have either of these skill sets, and all they can really coach the team on is following a particular process, then this is what we mean by process people, and for a serious product company, this just isn’t very helpful.

I was happy to see that the company laying off all these Agile people was helping them find other roles in their company.  I’ve already heard from some of them myself.  My advice to those that asked was to change their focus from the process, to the specific product discovery and/or product delivery skills that they have the relevant knowledge to help people with.  For some of them, there’s a terrific career opportunity in true product coaching.