Most of the people behind the agile manifesto were expert software developers - How many of your Agile Coaches are?

When I started Agile, almost 20 years ago, most of the people who helped teams and organizations implement Agile, were well versed in software development, architecture and all of the engineering best practices.

This was before Scrum had become popular, at least here in Denmark. Agile was pretty much the same as eXtreme Programming. Agile was mostly implemented bottom-up, and our biggest problem was how to convince management that this new Agile thing was a good idea.

Today, Agile is on the agenda of most large enterprises. I think it is for a big part due to all the people with a strong management and organizational background that got into Agile. People that understood and could talk the language of the management, and the business.

So thank you all from the bottom of my heart - we needed you!

But I do think we have lost something very important in the process. As the agile transition is now mostly driven by non-technical people in the majority of the large organizations, the importance of technical excellence has largely been forgotten.

The developers know this of course, but as those driving the process do not - it’s hard to get the technical improvements prioritized, and even harder when we need to align the process and the organization with the architecture, or go across the established organizational boundaries to solve deep underlying technical issues.

When Scrum does not mention the technical issues, it is not because they are not important. It is because Scrum was designed to focus on the essence: A set of almost universal patterns that can be used in a diverse set of domains, not just software product development.?

Scrum is designed to be "obviously not enough". We are supposed to continuously inspect and adapt it to our local situation. The more rules and specific practices you lock down in the Scrum Guide, the less wiggle room we have to learn and improve things (which is one of the reasons it is a bad idea to have very detailed and prescriptive process definitions)

If you are building software products, you are supposed to constantly experiment and search for the best possible way to efficiently and effectively deliver quality software products.

If you ask Jeff Sutherland about the many software companies he helped excel using Scrum, they all had a very high focus on quality and technical excellence. This was essential in order for them to succeed.?

The Agile Manifesto talks about “Continuous attention to technical excellence?and good design”, and even SAFe, have the Lean principle of “Built-in Quality” as one of its 4 core values.?

As a non-technical person, it can be hard to see the technical implications of the way you structure your process and the organization, and how it impacts the quality and the long term ability to deliver at a predictable pace.

But of course, developing software products is not just about the software. It is also, first and foremost, about understanding the users, the services they need and the business of delivering those services to them.?So obviously if we are to mentor and guide the forming of the optimal process and organization, we also need people with expertise in these areas.

“But wait,” - you might argue - “we are agile COACHES, we do not need any domain knowledge. We simply use coaching to help the teams, and the organization to become more agile”.

And you would be absolutely right. As a coach you do not need domain knowledge. I am also a certified personal coach, and I have successfully coached a singer regarding her stage performance. Despite the fact that I have no business being on a musical stage myself, and I could not sing if my life depended on it.

But the objective as a coach is to help the clients discover the solution within themselves.

If you only act as a coach, you do not get to present a solution, or in any shape or form to define in any detail the process, the structure of the organization, best practices etc.

If you successfully have helped a large, decades old, enterprise; transition from a traditional top-down waterfall’ish culture to an agile organization, using coaching alone, I applaud you. You have my deepest respect and admiration!

But in most cases the transition is most efficiently done by starting with a fair amount of teaching, training, guiding, mentoring, structuring etc., and then gradually as the foundation has been established, and the organization becomes ready for it, you can slide more and more into a coaching approach.

Eventually the people doing the work should own the process, and its continuous refinement.

The ultimate goal of Agile Coaching is to eliminate the need for agile coaching.

So do you need a technical Agile Coach? No, not necessarily - But people with a strong foundation in software development should be deeply involved in the continuous learning and improvement cycle. What we are trying to optimize is the product development organization as a whole. It is not enough that they participate in a one hour retrospective within the individual teams.

What I often witness, is that the large-scale process optimization is mostly done by process people, with too little involvement from the people doing the actual product development. I see huge potential benefits of Scrum wasted due to a lack of understanding, and prioritization of the technical implications of developing quality software products.

Does the above also match your experience? What other focus areas have you seen missing from large Agile transitions?