Googled by ‘scrum master coding ability’

Recently, my blog was found by a search engine using the search term ‘scrum master coding ability‘. I think, somebody asked here for the programming skills of a Scrum Master. This makes me feel urged to a short reply.

So, should a Scrum Master be a skilled programmer? In my eyes: Definitely yes!

Why? Well, I think, that is quite obvious. One aspect of the the Scrum Master role is his responsibility for the team. The Scrum Master has to improve the team. There are a lot of facets of what can be improved, one of these are programming skills for sure. Improving the programming skills lead to better code, to clean code in best case. If a Scrum Master finds his team (or a part of it) needing some help in that area, he has to coach it. First, this requires that a Scrum Master is able to recognise this. And second, the Scrum Master must be able to demonstrate to the team better techniques, best practices, and so on. (This is not meant as a prescript for the team. It is more a hint how things may go better. Still, the team can decide in what way it wants to work.) Therefore, to fulfil this part of his role, the Scrum Master must own programming skills!

By the way: Meanwhile, it should be clear what my understanding of a skilled programmer (or better: skilled developer) is. It is not only the knowledge of one or more programming languages, frameworks, and development environments. It is rather the things, that CCD comprises, behaviour/test driven development, domain driven design, design patterns/principles, just to name a few… I think, both sorts of skill are requirements for a skilled programmer which make him a skilled developer then.

The particularity of the Product Owner

In Scrum, the three roles Product Owner, Scrum Master, and Team are all important in their own way. In few words: The Product Owner is responsible for the project roadmap, i.e. he has to decide which features from the Product Backlog should be realised next depending on his prioritisation. The most important jobs for the Scrum Master are to keep the Scrum Process running, to protect the Team from impediments (or resolve them), and to act as a moderator. Last, but not least, the Team is responsible for the technical decisions and the accomplishment of the Sprint Goal.

But there is one thing that makes the Product Owner role quite particular for a project: The quality of the Product Backlog Items is crucial for the project progress. When put into the Selected Product Backlog of a Sprint, these items have to be worked on by the Team during the Sprint.

So, what happens if the items are of poor quality? And what do I mean by poor quality?

The description of a Product Backlog Item of poor quality is incomplete, ambiguous, unclear in such a way that the Team is not enabled to satisfy the Product Owner’s idea regarding that item. If such an item is part of the Sprint, it causes – in best case – a lot of unnecessary communication during the Sprint which as a result decreases the Team Speed. But normally, the effect is even worse. If the Team does not hit the Product Owner’s need, the delivered piece of software will not work as desired. Agile Processes often measure the project progress in terms of software features. Using this definition of project progress, there is no or slow progress in case the implemented features do not work as expected by the Product Owner!

To gain high quality Product Backlog Items, these are some basic demands on the Product Owner:

  • The Product Owner has to know what he wants.
  • Yet more important: He must be able to tell the Team what he wants.
  • Most important: The Product Owner must have an urgent need for high quality Product Backlog Items. He must feel the necessity for items of high quality; he must recognise that poor quality items hinder the project progress. So, it is in the Product Owner’s interest to have good items and in some way he should feel responsible for that.

The Product Owner does not need to be left alone with the task of producing high quality Product Backlog Items. The Team can help: It just has to insist on good or exact descriptions. Moreover, the definition of acceptance criteria is crucial. The Team may work with the Product Owner on their respective formulation (at best during Estimation Meetings). The goal of Estimation Meetings is to produce high quality Product Backlog Items. Furthermore, the Team can improve its knowledge of the business domain which in turn leads to Product Backlog Items of better quality. A ubiquitous language is quite helpful here.

So, for short and as a summary, in my eyes the Product Owner role is the most important one in Scrum with respect to the project progress. The Product Owner has to internalise the need for high quality Product Backlog Items. He must not be content with poor quality Items. He must recognise that the latter slow down the project progress. Together with the Team, the Product Owner can produce high quality Product Backlog Items.

Scrum Master part of the team?

It is said almost everywhere that a Scrum Master should not be part of the developer team. And in my experience, this really should be avoided.

Due to several circumstances it may be that you have a part-time Scrum Master, who has to switch between that role and the one of a team member. But there are several reasons for that a Scrum Master should do his mastering job rather than being occupied with working on Sprint Backlog items:

  • The Scrum Master role defines a full-time job if it is taken seriously. Serving all the facets of that role consumes all of the Scrum Master’s available time.
  • Having the Scrum Master role alone avoids conflicts of interests. How can a Scrum Master be neutral and propose an appropriate solution if there is a conflict between the Product Owner and the team, and he is a team member the same time?
  • A Scrum Master has a better position for moderation if he is not involved in the everyday business of working on the Sprint Backlog items. This makes him have a more abstract and less emotional view on what happens during the Sprint.
  • In case the Sprint Goal is in danger: I bet, a part-time Scrum Master will decide to concentrate his work on the Sprint Backlog items, neglecting his alter ego. This definitely results in a weak Scrum Master and means a danger for a proper Scrum process.

For sure, these aspects are even more important when you want to carry Scrum into your enterprise for the first time. At that time, obeying the Scrum rules is crucial for success. And so, the Scrum Master should not be distracted from doing his job. Part of this job is implementing Scrum and comprises – among others – creating an understanding of the underlying concepts in the mind of the people involved. He acts as a change agent!

If you do have a Scrum Master who is a team member also, you should check the option, that he is not the Scrum Master of his own team. This prevents him from at least a few conflicts of interests and puts him in a better position for his moderation jobs.

Fortunately, we recently had a change. We do not have Scrum Masters any more, who are members of the developer teams the same time. A Scrum Master now is responsible for up to four teams and the same number of Product Owners.

Just two more ideas concerning the Scrum Master role, which may lead slightly off topic, but I find them worth mentioning here:

First, when starting to implement Scrum or trying to do Scrum seriously, I advise a Scrum Master not being part of the company originally, i.e., he should not be recruited from the existing staff. This helps him

  • to have a better standing towards the management. A prophet has no honour in his own country.
  • to have a better standing towards the team as well. For the team members do not know him, they have an open mind to what he tells.
  • to be impartial, because he can be more objective. He does not know all the internal things of the company at the time he starts his job.
  • to find out the skills and abilities of the team, because he can have an unprejudiced look on it.

Second, I hardly dare to mention, that of course a Scrum Master has to be well versed in Scrum, agility, etc. in general and to be well versed in his role in particular. I.e., when the decision for doing Scrum is made, an experienced Scrum Master should be engaged. Furthermore, the Scrum Master role requires a lot of soft skills – first to mention communication skills. (But the latter is worth another blog post…)