Author: Marc Greis

When interviewing for a new position last year, the topic of whether or not a Scrum Master should have a technical background came up quite often. Despite the fact that the Scrum Guide does not list any technical tasks for Scrum Masters whatsoever, the default assumption seems to be that they must have a technical background or that ideally, they were software developers themselves at some point. In fact, many job listings for Scrum Masters explicitly ask for software development experience.

Still, there are many Scrum Masters who have no technical background at all, and they still seem to be able to support their teams well enough. Or are they even better than technical Scrum Masters?

I think both sides have distinct advantages and disadvantages. A technically versed Scrum Master can certainly help a team, for example by encouraging the team to  introduce or reinforce software development techniques like TDD, continuous integration, etc. A Scrum Master with deep experience in software development might be more likely to discover “unspoken” technical impediments plaguing the team. Additionally, the Scrum Master could act as a kind of “free radical” in the development process, picking up some small tasks, filling little gaps here and there – for example by helping write that one last corner case unit test that the team just couldn’t wrap their heads around anymore, by pushing the pixels into just the right place in the CSS when the frontend developers have already gotten tired of further optimizations after staring at the same page for three days, and so on.

For some of the points listed above, many would object that these are not Scrum Master tasks – and while this is a topic for another post, it already points towards a potential problem: Handling these technical tasks could cause Scrum Masters to neglect their actual duties to the team. Especially software development tasks can demand quite a bit of attention (possibly more than initially predicted), and if the Scrum Master picks up a task from the task board, it might be psychologically difficult to place it back, thus disappointing the team.

Also, there is a high risk that the technically knowledgeable Scrum Master will become involved in the planning by interfering e.g. with the estimation process. Ultimately, technically experienced Scrum Masters always have to be careful not to turn into overbearing know-it-alls with their fingers in every little aspects of their teams’ work.

Non-technical Scrum Masters can actually add some highly useful diversity to a team, especially if they come from areas that are completely orthogonal to technical topics, such as psychology, philosophy, social studies, etc. They might be quite well-equipped to deal with interpersonal problems in the team which can frequently pose significant impediments, and they would be seen as more neutral in technical disagreements and especially in disagreements which are technical only on the surface but which are actually based on unresolved interpersonal problems.

One major disadvantage for a non-technical Scrum Master is probably that it is more difficult to discover unspoken technical impediments. Teams often deal with technical problems that have long been accepted as “unfixable”, so they are never brought up in dailies or retrospectives. A technical Scrum Master could help a team to bring these topics back to the surface. A non-technical Scrum Master will have to take the more difficult path of teaching the team how to (re-)discover these impediments (which on the other hand is more desireable as a long-term goal).

An additional issue is that it might be more difficult for non-technical people to be accepted as Scrum Masters by their teams, especially when the teams are not very mature in their agile mindset. In this case, a non-technical Scrum Master will have to put significant effort into continuously educating the team about the services a Scrum Master provides to the team.

I think it is obvious that both technical and non-technical Scrum Masters have advantages and disadvantages. But in the end, it is more important to choose a Scrum Master who has the right servant-leader mindset and who understands agile values. Beyond that, Scrum Masters need to be aware of their specific strengths and weaknesses and they need to actively work to cover their weaknesses, or ideally, to turn them into strengths.

Having said all that, there is one thing that I want to impress especially on non-technical Scrum Masters (though apparently, also many technical people are not aware of this): Software development can (and should) be fun and software development can (and should) be a creative process! As I have said in other posts, I believe that “Development for fun” is at the core of why we do Agile. Agile allows for software development to be a creative process. Many people who have never developed software themselves might have a difficult time understanding this, as a “naïve” understanding of software development is that you tell a machine what to do, and it executes your commands. But software development goes far beyond that, and it is important for every agile practitioner to understand this, and in my opinion, this is far more important than a detailed technical understanding.

 

I apologize for the intentionally provocative title, but it is a bit of a counterreaction to the frequent questions “What is the difference between Scrum and Kanban?” or “Which one is better?” – questions which in my opinion do not make a lot of sense, so I am more and more tempted to give a provocative answer (which I will still try to partially justify below).

I feel that Scrum and Kanban are like “eating Italian food” and “eating with chopsticks”. Both eating Italian food and eating with chopsticks achieves the same purpose: the ingestion of food. The end result of both approaches is that you have eaten food. Still, both approaches are conceptually so different that nobody would ask “What is the difference between eating Italian food and eating with chopsticks” or “Which one is better?” And even though it is not common, it is possible to combine both approaches – you can certainly eat Italian food with chopsticks. In some cases, it might be counterproductive, in other cases, you will not gain anything from it, but in some cases, it might even be better than the “traditional” approach.

In the same way, it is probably pointless to compare Scrum and Kanban. While the end result of both is working software, both are conceptually so different that a 1:1 comparison does not make sense. And you can obviously even combine both – which in some cases might be counterproductive, in some cases pointless and in some cases great.

Still, the question “What is the difference” will still keep coming up, so it is worth coming up with a concise meaningful answer (outside of giving fully-day Scrum and Kanban classes).

This takes me back to the provocative headline though. I find the idea of viewing Scrum as a “type” of Kanban quite intriguing. Obviously, every Kanban or Scrum coach would (and should) object immediately to the idea that Scrum is a variant of Kanban. After all, it seems that both have only very superficial or general commonalities. Obviously, both foster self-organization and force the teams to visualize their work. But what about limiting the work in process (WIP) and managing the flow of tasks? These are core concepts of Kanban but not of Scrum. At least you will not hear anything about limiting the WIP in a pure Scrum training.

But that is the interesting part: Scrum DOES limit the WIP. It just happens more implicitly. In Kanban, it is done explicitly, e.g. by writing WIP limits above the task board. Kanban teams should talk about their WIP limits frequently and tune them. That is not a common explicit topic in Scrum retrospectives. Still Scrum limits the WIP implicitly. The WIP in Scrum is limited by the number of story points the team is willing or able to accept into a Sprint. And the goals in Scrum are similar to the goals of the limited WIP in Kanban: Do not build up a large “inventory” of in-work tasks and do not allow analysed, implemented or tested tasks to “decay” in their respective states. Give the customer quick results and solicit feedback as early as possible to avoid going down a wrong path for too long.

Both Scrum and Kanban limit the WIP and try to get tasks through the workflow to the “Done” column of the taskboard – Kanban by focussing on pulling tasks through the flow aggressively and Scrum by giving the team a goal at the end of the Sprint.

But this is also where the similarities end and where the “Scrum as a Kanban variant” idea breaks down. Kanban does much more than limit the WIP. Kanban is strongly focussed on getting tasks into Done – not at the end of an iteration, but as soon as possible. Scrum does not have the same intense focus on finishing work immediately but instead asks the team to finish the work by the end of the Sprint.

Also, as I mentioned before, in Scrum, the team usually does not make it a constant top priority to discuss the WIP and how it affects the flow of the work. The WIP is usually not being tuned frequently, but the team examines other aspects of the work to find ways for improving the performance.

So which value does this kind of a provocative statement have? Well, I believe that it is an interesting starting point for facilitating a discussion about how Kanban and Scrum are different on a conceptual level while still pursuing many of the same basic goals.

Also, the Sprint length is a frequent discussion point for Scrum teams. The development teams frequently try to push for longer Sprints for various reasons. There are various ways to try convincing the teams of how shorters Sprints are valuable, but perhaps an additional approach would be to view the Sprints not as “mini projects” with the goal of producing shippable increments, but as WIP limiters. It could be useful to look at the way how shorter Sprints affect the flow of the tasks, while discussing a concept like lead time and its impact. This might actually give one of the most common discussions in introducing Scrum a fresh perspective.

 

The first answer to that question is: Not the Scrum Master (as I wrote in The Scrum Master is not a Project Manager!).

Now that we got that out of the way, let’s acknowledge the fact that a LOT of people will scream now: “There is no project manager in Scrum!” – rightfully so. Because the Scrum Guide does not define a project manager. The word does not appear there.

But that doesn’t mean that the most common project management responsibilities just disappear in Scrum. They still exist – they are just not distributed to one single person who rules the project in a command-and-control manner.

Let’s dig a bit into the responsibilities that are traditionally assigned to a project manager. I would like to split these into two categories, which I will call, for a real lack of better terms, “environmental” and “internal” responsibilities. I am still looking for better words, but for now, these will have to do.

Environmental responsibilities: In this category, I place all tasks that are not directly related to enabling the value creation. These tasks can feed into the value creation activities or they can process their output, but they do not impact them directly. By this, I mean the project management tasks that relate to:

• Defining the scope of a project, the vision and the higher-level requirements as provided by the customers/stakeholders.
• Being aware of the project budget and how the value created by the Development Team relates to the budget.
• Evaluating the project’s business impact and viability.
• Prioritizing requirements for maximum business value.
• Discussing project progress and further plans with stakeholders and customers.
• Perform release planning to communicate planned release content to stakeholders and customers.

If you have the descriptions of the different Scrum roles in mind, it should be quite obvious where these responsibilities move to in Scrum: The Product Owner. So this answers the first half of the question. The Product Owner handles some of the traditional project management responsibilities. The Scrum Master assists with many of these tasks, but they are nonetheless the direct responsibility of the Product Owner.

The other side are the internal responsibilities: These are the tasks that directly enable value creation:

• Breaking down high-level requirements into detailed technical tasks and estimating the effort of all requirements and tasks in the project
• Planning the execution of the work
• Assignment of tasks to developers
• Monitoring the outcome and predicting the future progress
• Presenting work results to the customers/stakeholders.

Who handles these tasks in Scrum?

Yes, that might be a bit of a surprise to some people: These project management responsibilities are handled by the Development Team.

And that is the reason why so many people scream “There is no project manager in Scrum!” whenever that topic comes up – because the Development Team is self-organizing and the idea of a project manager seems to work against that. The developers in a Scrum Team do not have a manager. They manage themselves! But that statement actually leads to the more correct (and useful) answer:

The developers in the Development Team are the Scrum project managers!

I think this is a very very important revelation, because it explains a LOT about how Scrum is structured.

The great thing about Scrum is that it turns the developers into project managers without making them feel too much like project managers, because – let’s face it – most good developers do not want to be project managers. They want to create code. They want to be creative. They want to solve technical problems. They don’t want to deal with convoluted processes, management reporting, creating project plans, and so on. But Scrum takes the developers by the hand and surrounds them with a simple set of rules and constraints that automatically turns them into project managers.

And why? Simple: Because the developers are the best possible technical project managers for their area of work.

Like I said, this explains a lot about Scrum. Developers often ask why they have to attend daily standup meetings for example. Well, what do project managers do to get an idea of the project status? They ask the developers for a report. That is exactly what happens at the Daily Scrum: The developers report to the project management (= the developers).

I have heard many times that good project managers always have to challenge the estimates they are given by developers. So what happens during planning poker sessions? The developers come up with estimates and the project managers (= the developers) challenge the estimates. And in this case, the challenge comes from project managers who have a deep technical understanding of the product and the requirements. These are not project managers who challenge an estimate on principle, but project managers who do so because they have real technical objections.

So in my opinion, it is a big mistake to say that there are no project managers in Scrum. I think it is much more correct to say that the developers handle the project management (without forgetting the Product Owner’s important contribution from an environmental perspective, of course), because this motivates the way the Scrum ceremonies are structured. It answers a lot of the common “Why?” questions people ask about Scrum. And most of all, it reminds the developers of the great underlying respect and trust they are given when they are assigned to a Scrum Development Team.

Why do so many people believe that the Scrum Master is a project manager? Is it perhaps the word “master” which gives people the impression that the Scrum Master is “in control” of the project? And why do people believe in the first place that there has to be a single person who takes over the responsibilities of a project manager? Are they so stuck in their command-and-control waterfall box that they cannot imagine a different setup?

Perhaps the idea of the Scrum Master as project manager has become a kind of self-perpetuating myth by now. When HR managers see hundreds of job openings for “Scrum Master / Agile Project Manager” positions, then perhaps they start believing that a Scrum Master is really a project manager.

There is one positive aspect about this misunderstanding: It is actually a fairly simple test to prove that someone has never actually read the Scrum Guide, because I struggle to find many project management tasks in the description of the Scrum Master role in the Scrum Guide. If the Scrum Master manages anything based on the description in the Scrum Guide, then it is Scrum itself – and I consider even that to be a bit of a stretch.

So how does the Scrum Master role compare to that of a project manager? As that seems to be such a difficult question for many people, let’s break it down as simple as possible, first by describing what a project manager does, using a kind of simple XML notation:

A <actor>project manager</actor> <activity>manages</activity> <target>projects</target>.

Sorry if this seems stupidly simple and obvious. Bear with me for just a second, because this leads to the apparently not-so-obvious question what the “activity” and “object” are for a Scrum Master. Here is the answer when you condense the Scrum Guide description of the role into one sentence:

A <actor>Scrum Master</actor> <activity>helps</activity> <target>people</target>.

The description of the Scrum Master role in the Scrum Guide is all about the Scrum Master “serving” people. The Scrum Master helps the Product Owners to deal with their responsibilities, helps the Development Team understand Scrum and helps them by removing impediments. The Scrum Master also helps everyone else who is not on the Scrum team to better understand Scrum and to interact in a productive manner with the Scrum team. A lot of “helps” there and a lot of “people” who are the targets of this help.

Perhaps now it is more obvious, why I used an XML notation to break this down into little pieces? Because now the difference between project managers and Scrum Masters becomes too glaringly obvious to ignore. The Scrum Master does not manage. The Scrum Master helps (or serves, if you prefer that term). And the target of the activity is not a project but the people who are involved with the project.

Also, I hope it becomes a bit clearer why I do not think that “managing Scrum” makes the Scrum Master a project manager. Yes, the Scrum Master ensures that the Scrum rules are followed and moderates Scrum meetings. But managing meetings and managing a project are two different things. In the end, the background here is still that the Scrum Master helps the other team members to apply Scrum correctly.

Going from being a project manager to being a Scrum Master is a bit like going from baking bread to farming wheat. Even though both tasks can appear in the same value chain, they are still completely different activities with completely different targets.

I am not saying the Scrum Master cannot take over any project management responsibilities. All I am saying is that this is definitely not the primary role of a Scrum Master. I am also not saying that a project with Scrum teams cannot have a project manager on a “higher” level. That is a completely different discussion which I am definitely not going to touch here.

Most importantly, I am not saying that the project management tasks and responsibilities as defined e.g. in a waterfall process just evaporate when moving to Scrum. Some of them become obsolete, but most of them are meaningful and necessary, so someone has to handle them.

And someone does handle them in Scrum. Yes, that is described in the Scrum Guide, though it’s not so immediately obvious.

Now you wonder who handles these project management responsibilities in Scrum? The answer might actually be quite surprising to many people, but it is a very important key aspect of Scrum, as it helps with understanding many aspects of Scrum that are frequently misunderstood and questioned.

I’ll leave that answer for the next post though (sorry for the cliffhanger).

 

There is an interesting development that I call the “Google Imitation Fallacy”. More and more companies try their best to make their employees’ breaktime a wonderful experience. They try to inject the maximum amount of fun and/or relaxation into those breaks. It began with simple things like gaming consoles and foosball tables, but now, companies are building whole playgrounds in their offices. I see reports about this on TV every now and then, and everyone goes: “Oh, wow, what a great company!”

Don’t get me wrong – that is not a bad thing! A fun break is better than a boring break.

The problem is that many companies seem to confuse “enjoying your breaks” with “enjoying your work”. But these are completely different things. Sure, a great fun and relaxing break can radiate into your work. It can help you free your head, it can help you be more creative, it can lighten your mood. But if you hate your work, then at the end of your break, you will still go “Oh no, I don’t want to go back to my desk!” Nothing you do during your break will change that. Nothing at all.

Giving you a lot of breaks and filling them with activities is, after all, strictly extrinsic motivation. And extrinsic motivation is lazy motivation. It is easy for the company, because all the company has to do is spend some money. Sounds difficult, because money is something a company is not supposed to waste. But it is so much easier for a company than thinking about how to motivate employees intrinsically. Giving people interesting task, allowing them to self-organize, giving them the opportunity to improve their skills and to respect themselves, their work and their team mates – that is incredibly difficult. It actually means that people managers have to do their job as opposed to just pulling some money out of their budget. Motivating people intrinsically is really hard. Spending a few thousand bucks on the other hand – that is comparably easy. And lazy.

So once again, It is great for employees to have fun during their breaks, but it should not be a replacement for intrinsic motivation. It should not even be a companion for it. It should come only after management has really thought about what they can do to make their team members enjoy their work.

Otherwise, fun breaks (like all types of extrinsic motivation) become the equivalent of the little food samples you are sometimes offered at supermarkets. The strategy there is that after you get a “free” sample, you feel obliged to buy the product, even if you did not like it all that much. And later, you regret it. If you are a manager, do you want your employees to work for you because they feel obliged to do so? Or do you want them to work for you, because they actually want to work for you? And what do you think will yield the better performance and the higher amount of creativity?

Companies should not try to be “cool like Google” by installing swings and slides in their offices, but by actually thinking about how to really motivate people, and managers need to understand the difference between enjoying your breaks and enjoying your work.

I have already mentioned the concept in a previous post: In Agile coaching, people often speak about the Shu Ha Ri – a theory coming from martial arts about how people learn new skills. First, a set of rules is introduced (Shu), then people learn to apply these rules properly to their given situation and possibly to “bend” them, where necessary (Ha) and finally, they understand how to grow beyond the rules, how to live the “spirit” of the rules without even thinking about them.

It seems that in introducing Scrum, there is often a focus on the Shu part. The rules are introduced as strict laws. Fairly little reasoning is given for them. The goal is to establish the rules and to achieve improvement e.g. in performance or quality through whatever benefits Scrum provides. And obviously, Scrum does provide benefits, even if the Scrum team does not understand anything about the agile principles behind Scrum and the greater framework of thoughts and ideas that Scrum is embedded into. Early testing will increase quality. Frequent retrospectives will lead to constant improvement. Iterative work will allow the team to fail fast.

However, I believe that this “Shu-focussed” approach can lead to Scrum implementations that go down a completely wrong path – abominations such as Scrumerfall or tailored Scrum versions that omit the parts which are good for the team and focus on the parts that look good to management. Also, a Shu-focussed team would end up going through the motions of implementing Scrum as a process (which it isn’t) instead of working towards a goal that goes beyond being able to say “We are doing Scrum”.

So in my opinion, just understanding the Scrum rules is not sufficient. The rules are simple. The Scrum guide explains the rules in quite a bit of detail on twelve pages, though I am sure it would be possible to squeeze them onto one page and to learn them in less than ten minutes. So the complexity of the Shu part is quite low.

Consider examples like the games chess or go. The rules for both games are extremely simple and would also easily fit onto a single page. But if you study the rules for chess, you still will not be able to play a very meaningful game of chess. You need at least a basic introduction to the many other considerations that transcend the rules – a few simple openings, general strategic considerations and end game strategies. You need to get an idea of what the Ha and Ri look like before you really get what the game is all about. And I believe it is the same with Scrum.

So it is not enough to just teach people the rules of Scrum or to give people a rough idea of agile principles. I strongly believe it is necessary to motivate Scrum and other agile approaches beyond the pure rules and to at least give people are rough idea of what can be achieved with Scrum beyond just a higher performance.

If someone is needlessly dogmatic when dealing with frameworks like Scrum, it indicates in my opinion that they are still stuck in a Shu mindset and have trouble moving on to the Ha and Ri stages, where instead of blindly following a rigid set of rules, they would learn to apply the rules according to the given situation or even to transcend them and to go beyond a lazy copy&paste implementation of the Scrum Guide.