A Scrum Master without technical skills?

Balance of Agile roles according to Hendrik Kniberg (Product Owner in a Nutshell)

If you look at the Scrum Master as being the coach of both the Product Owner and the Dev-Team, what skills does this person need to coach them?

The Product Owner has to blindly trust the team to build the thing the right way, but the Scrum Master needs to coach them on this. Would you bet on a football or soccer coach who has never played the game?

No. I wouldn’t think so, unless this person has super powers that would balance things out in your favour somehow.

I like to think that Ron Jeffries says the same thing here. You cannot coach Agile software development if you have never experienced it yourself while being knee-deep in with the team.


The land that Scrum forgot

While most founders of the Agile manifesto talked and wrote extensively about it, most Certified Scrum Masters still lack experience with technical skills and practises. Even if they do understand their importance, they likely lack the credibility to convince their team. Coaching only the process.

Scrum forgot to incorporate the technical disciplines that make Agile work.

I like how the LeSS framework puts it:

Organizational Agility is constrained by Technical Agility: In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organisation or what framework you adopt, you will be slow to respond to changes.

Most Scrum Masters (with a project management background) will have to trust the development team that they keep the cost of change on the product low. Time told me that most developers have no experience how to really achieve this. Most developers just think it is their job to make it work, not making sure the code is adaptable over time. Those that do, tend to over-engineer in such a way that they take all their past mistakes into account continuously. Leading to its own set of problems.

Over-engineering: Code that solves problems you don’t have.

Finding the balance of what you need now versus what you might need in the future is hard, certainly if you want to make sure your product is able to respond to change today.

Your team will need someone to coach the balance between making it work and good technical excellence practises, minimising the technical debt they create. While making sure the Product Owner understands the importance of these practises to minimise wrong discussions around this topic.


Building it fast

It is not about going faster and faster, but how your team stays fast over time. Some slowdowns will be organisational, but loads (if not most) will be technical. Carefully stepping around the traps of Flaccid Scrum.

Scrum without technical practises becomes a tractor pull. Every sprints it gets harder and harder and harder to make progress, because the code is getting worse and worse. — UncleBob

Scrum doesn't solve this as it is just a project management delivery framework and therefor it misses out on the necessary Agile practices. If you ask me the Scrum guide misses a chapter where it touches upon Agile principles like:

- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.

The Scrum guide has just one line at the end … and it lacks depth.

Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Make sure you start adding technical quality practises in order to have an adaptable codebase as soon as possible. What the minimal set of practises are is another complex story, but ThoughtWorks has a nice blog about their core-practises.


The perfect Scrum Master

Someone who understands the balance between structural, process and functional quality while keeping the Agile values and principles in mind. Combined with work-experience in all three area’s within an Agile team.

Therefor I would like to argue that an Agile Software Test Engineer makes the perfect Scrum Master, as they have experience with:

  • Structural quality: They have coded automated tests, while working close with the development team. Understanding the importance of code quality. While having a test-first mindset can help you get started with practises like TDD. Hopefully having enough credibility to introduce and motivate Clean Code to team. Preventing rigid application.
  • Process quality: They have worked in the full software process life-cycle. Going from feature requests till delivery. Being able to communicate with stakeholders, developers, product owners and managers on their own level. Understanding the need of a “A repeatable development process that reliably delivers quality software” as most of them have felt the pain of mini-waterfalls in their Agile teams.
  • Functional quality: With shifting their mindset from building features to a user-centric business view. They tend to understand the core functionality that makes your business tick. Hopefully helping you to find the 20% of features that deliver 80% of the value. Learning to say no is your best output maximiser. Hopefully they can prevent fragile applications, e.g. changing something here, breaks some else unrelated to the change.

According to Brent Jensen modern testers have a focus on “accelerating the achievement of shippable quality”. For me this means balancing all three aspects of software quality. Something your team coach should be able teach in my book.

Sure just these three aspects do not make the perfect Scrum Master, but it seems better than only having a developer background and certainly beats the crap out of the project manager making a transition to team coach.

The perfect Scrum Master is also an inspiring facilitator, a focus-coach and a servant-leader, but I wonder if those aren’t more natural talents as they do not come from a certain knowledge background. Read this for more characteristics of a great Scrum Master.

A great Scrum Master is also competent with XP, Kanban and Lean.

Project managers tend to lack the credibility when it comes to technical practices like XP. Why would a developer listen to a project manager for non-process related advice? This as they are still trying to unlearn their mediocre command&control people management skills while forcing the Agile Imposition onto its team members. But most just lack the technical and probably also the business skills. Probably leading to Cargo Cult Agile.

XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.

Even worse are the consultancy agencies that are leading the Agile Industrial Complex, where Agile is routinely forced on teams, which is in conflict with the fundamental of Agile principles, namely: Respect for People. I truly think large enterprises cannot and should-not try to Agilify their way of working, for example old banks and pension-funds are just not Agile, nor will they ever be. I guess investing in new modern Agilish banking tech-start-ups might help, but not pouring our money in large expensive transformations.

I think companies should stop blindly hiring Scrum Masters and Agile coaches without any proven technical background for their teams.

Really it does not make sense, unless you like to build train-wrecks. :)


I love Scrum, but hate how it is often being abused by non technical people. What are your thought on this? Should Scrum Masters be coaches with a technical background or did I miss anything obvious and strike-a-nerve? Please let me know in the comments.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.