Agile Leadership can be non-technical.

The agile reformation is a fractious movement. We are clear about what we oppose but struggle to interpret our stated values consistently. It is why we have so many bitter disputes within the movement. Today, I am inserting myself into one of those disputes.

The people who created the Agile Manifesto had no idea how a wider world would adopt their values. Still, as professionals, organizations sprung up to provide training and credentials to people willing to lead change in organizations. Scrum.org and the Scrum Alliance were born. I said this was a positive development because a standard body of knowledge is possible, and organizations know that if someone has a certification, they understand the fundamentals of an agile role. Now, a developer or business person could take a class and, ultimately, receive a credential to ensure they understood product ownership or scrum mastery.

The unintended consequence is that organizations began to use the credentials as a filter. Now, business leaders and HR professionals can easily select agile talent based on the certifications they have earned. It kicked off a gold rush for non-technical professionals and former project managers to earn the certifications to get into software and technology without having to do the work or learn code, testing, or data architecture. It also created resentment as Product Owners and Scrum Masters began to serve teams without understanding the unique challenges technical professionals face.

The situation was more stark in large software implementations as project management professionals earned advanced SAFe credentials and passed themselves off as coaches. A person with no experience in source control or unit testing was unexpectedly assigned to lead a release train at a client. Three months later, he was gone because upper management discovered that the release train could not deploy software under his leadership. Behind the scenes, this incompetent leader was quietly pushed out of the company. Surprisingly, they're now the CTO of another firm, likely due to their impressive resume of failed software projects. Stories like this are familiar in the technology business as living embodiments of the Peter Principle rise in organizations. At the same time, those who do the work often suffer for their lack of capability and understanding.

This trend in the business world is creating friction within the agile community. Developers respect knowledge and experience, yet many servant leaders need those skills. Thus, more articles are appearing by agile professionals demanding that Product Owners and Scrum Masters have basic technical skills before receiving training and credentials. The authors argue that a two-day class does not provide the foundational knowledge necessary to lead a technical team.

Like many things in the technology business, the answer to this valid criticism is, "It depends." We must consider the context of each situation and then determine if the Scrum Master or Product Owner is helping or hurting the team's productivity. When I became a Scrum Master, I was an intermedial level C# developer working with web tools. I knew which questions to ask and when to defer to the team's technical lead. I did not know the more expressive part of being a Scrum Master. I was rigid in enforcing agile practices, and at times, I behaved like a robot, going through the motions of scrum instead of helping the team negotiate its agile journey.

I look back on those years as crucial learning experiences, making me a better coach, Product Owner, and Scrum Master. In my case, I had the technical skills but not the leadership experience when I started. So when I say the technical expertise of a scrum master depends, I mean a team that needs strong servant leadership can weather a scrum master who is non-technical. A team with many technical debts and struggles to deliver demands a more technical scrum master. So, leadership over the team should be on the lookout for what kind of Scrum Master the team needs rather than a one-size-fits-all template.

Currently, we are at the end of the Agile Gold rush. Business leaders want people to deliver and provide value, so they are culling plenty of people from this profession. Those left behind will provide more value because we understand the leadership and technical skills necessary to do the job. If people are willing to put in the work and grow their teams, it should not matter if they come from a technical background. It is all about delivering values and following the spirit of the Agile Manifesto.

Until next time.