Selecting An Agile Coach
I should have written this article many years ago.
Starting around 2004 and 2005 I began seeing an increasing number of teams moving to Agile, and of course the first thing they needed was training and often some coaching.
However, more often than not, I had to go into these companies after the training and try to clean up the mess that the trainer left behind.
I thought – incorrectly it turns out – that this would be a temporary issue, while the Agile community gained experience, especially with commercial product companies. Unfortunately, the problem of poor trainers and coaches has not diminished. While there are good choices out there today, in my experience they are still the exception rather than the rule.
Like with most things, it is buyer beware. However, if your team needs training, it’s likely that your buyers (your CTO, VP Engineering or VP Product) may not have experience with hiring Agile trainers or coaches, so the purpose of this article is to try to help true product companies select effective Agile trainers and coaches.
1. First, it is important to recognize that most software today is not commercial product software. Much of it is still IT (internal) or custom. So it’s no wonder that so many Agile trainers are bewildered by commercial product companies. But you do not want to be the product company that the Agile trainer learns on. So it’s essential that you make sure that any potential trainer understands the differences between IT software development, custom software development, and commercial product software development. See https://svpg.com/the-origins-of-agile/
2. Commercial product companies have some critical and different roles from other types of software. Any potential trainer must understand the roles of a true product manager, product marketing, and the product / user experience design team – interaction designers, visual designers and user researchers. See https://svpg.com/design-vs-implementation/
3. Given the key roles of product manager and UX designers, any potential trainer must understand how these people work with an Agile delivery team. The trainer should have direct experience with product discovery as well as product delivery. See https://svpg.com/dual-track-agile/
4. When running a software technology business, there will be cases where you need to be able to make actual commitments and reliably predict delivery. But we need to do this in a way that has integrity, and also acknowledges the reality that conventional roadmaps are likely littered with items that won’t actually work for the customer. So the Agile trainer must understand how commitments are made and managed in a product team. See https://svpg.com/managing-commitments-in-an-agile-team/
5. In a commercial product team, the product vision plays a key role in establishing the context and motivation for the team. The Agile trainer must understand key role of product vision and strategy, and how this fits in an Agile discovery and delivery environment. See https://www.svpg.com/product-leadership-is-hard/
6. Many IT Agile trainers consider trying out a few ideas every two week sprint as fast. In a commercial product environment, this would be considered prohibitively slow. Make sure your Agile trainer understands the role of speed in enabling true innovation, and how product discovery lets us validate most ideas without writing any code. See https://svpg.com/the-need-for-speed/
7. In a commercial product organization, we have a continuous cycle of building (prototypes and production), measuring the results, and learning and iterating. It’s critical that any Agile trainer understand this cycle and the key role that live-data prototypes, analytics and A/B testing play in decision making, testing and continuous learning. See https://svpg.com/product-discovery-with-live-data-prototypes/
8. Culturally, there is a very big difference between the developers in an IT organization, and those in a commercial product organization. The Agile trainer must understand that capability and experience level of the engineers is typically very different from IT, and adjust their approach accordingly. Many of the engineers on the team will have substantially more experience building true products than most Agile trainers, and it is easy for the trainer with the wrong attitude to fail to gain the respect of the team. See https://svpg.com/moving-from-an-it-to-a-product-organization/
9. Another profound difference is that in an IT organization, the team exists to serve the needs of the business. In a commercial product organization, the product team exists to create solutions for their customers, in ways that are viable for the business. This is not a minor difference. The Agile trainer must understand that this is not a service organization, striving “to meet the needs of the business.” See https://svpg.com/product-management-as-a-service-organization/
10. Finally, it’s critical that the Agile trainer not just understand commercial product companies, but also the demands and techniques of running truly mission critical SaaS services. Issues involving scale, reliability, fault-tolerance, performance, instrumentation, test automation and technical debt move from nice-to-have to non-negotiable. Moreover, a commercial product organization is no place for dogmatic and blind adherence to process. Some Agile people tend to confuse the means with the ends. The end that matters is successful product. See https://svpg.com/process-police/
Remember also that when selecting an Agile trainer or coach, the organization you engage with typically turns out to mean less than the actual person that is assigned to you. So assess the individual, and make sure they have the experience with commercial product organizations that you need.
Note that generally speaking, a trainer comes in and explains the theory to your team and then leaves, but a coach works with your team to actually apply the techniques in your unique environment.
