Category: Uncategorized

The question how to scale Agile (especially Scrum) seems to be one of the biggest and most controversial topics in the agile community. I believe that the issue boils down to three major questions:

1. Where do requirements come from? A single backlog for all teams? A project manager or product owner for the product owners or a committee of product owners?
2. Where do the requirements go to? Or more specifically: How is it decided where they go to? Which team gets which task?
3. How do we deal with dependencies between teams? How does Team A tell Team B that it needs a sub-feature in the next sprint so that it can build on that feature in the sprint after that? How is the software ultimately integrated?

A lot of complex ideas have been built around these questions. I feel though that we are in a kind of „Emperor‘s New Clothes“ situation here where everyone is intimidated by these questions and in awe of those complex solutions, the big charts that have been drawn to explain them and the additional roles that have been introduced to make them work. Many people seem to be too scared to just point out that common sense should be the major guiding factor here, and that additional roles and ceremonies should come second.

I believe that this is true especially for the third question. How can Team A expect to tell another self-organized team which stories it must pull (and complete!) in the next sprint? Or to take it one step further: How can Team A plan two sprints ahead to be able to make such a statement in the first place? How is that still agile? Of course, it is possible to draw up predictions for the next few sprints and the next major release based on team velocities and rough estimates, but these are predictions! Once we create a dependency between the predictions of two teams, the predictions become plans – and not the nice kind of plans, but the ugly types of plans that result in a lot of stress, anger and finger-pointing when they inevitably go wrong. With this kind of planning, we give up the idea of limiting our risk to one sprint. We give up the idea of responding to changes.

And this is where many people seem to forget common sense, because the strikingly obvious common sense solution to the problem is not to plan dependencies, but to avoid them. At all cost!

A cross-functional team is capable of developing features from start to finish without requiring outside help. At least that is how I usually define „cross-functional“ when asked about the meaning of the term. Once we simply accept inter-team dependencies, we give up the idea that cross-functional teams can truly exist. The real solution should be to either make the team cross-functional or to trust it to become cross-functional. A team cannot complete a feature alone, because the feature affects code maintained by another team? Well, then the team is not truly cross-functional. I believe that the correct solution here is not to shrug and give up a handful of agile principles. The correct solution is to give the team the full responsibility for the feature. The correct solution is to trust the developers. To challenge them. To give them the support and environment they need to complete the feature. The whole feature.

And yes, I am fully aware of the difficulties of delving into someone else‘s code. I have worked in technical domains before, where it took even great developers many months before they could make meaningful changes in the code base. I am not saying that it is easy to build features in code that you have never worked on. I am saying that it is better than giving up on agile values and principles and that in the long run, it is easier and actually more predictable than trying to manage dependencies between a large number of teams.

I know that this is difficult to apply in many environments, because a lot of companies are built in silos with non-cross-functional teams and interdependent projects, but I challenge both developers and agile coaches to work on changing these environments step by step to introduce common sense into this problem space. A meeting like a Scrum of Scrums is not a solution – it is a symptom of a problem that we have so far avoided to solve.

I think there is one issue which is often neglected in agile transitions in favor of discussing about roles, responsibilities and processes: The technical basis for the work and the core requirements for successfully delivering high quality software to the customer

Scrum is often seen as a kind of value generation engine. I believe there is much more to Scrum, but it is certainly correct that Scrum does work like an engine which is fueled by requirements in the shape of user stories and which – through the time, expertise and motivation of the team – produces valuable output in a reliable cadence. However, it is important to remember that even the best engine needs oil to run smoothly, and I believe that this oil is represented by a certain basic technical groundwork. More specifically, I am referring to a functioning continuous integration pipeline and a solid set of well-maintained regression tests (both unit tests and system tests).

Without this groundwork, the Scrum engine will sputter and stall. It is inconceivable that a team can deliver high-quality software in a reliable cadence if it runs into problems every few days that often take several days to analyse and fix. I actually saw this kind of issue in the first agile transition that I witnessed. The coach in charge of the transition was told that we could never run two-week sprints, because it could easily take one week to integrate a finished change into the software due to various deficiencies in the development environment. Based on what I know now, I believe that at this point, the coach should have told the management to put the agile transition on hold until these basic problems are fixed.

In fact, if I were put in a hypothetical interview situation where I am told that the company only has the budget to either hire a Scrum Master or to introduce a decent continuous integration system and to write unit tests, I would gladly say „Ok, then let’s end this interview, and please take care of the technical issues first.“ I would do that, not because I am an altruistic person, but because I know how difficult my life as Scrum Master would be without having the most basic technical requirements in place to reliably deliver value to the customers.

I’d like to follow-up on the „water in a bottle“ metaphor from the last post, as this metaphor also says a lot about self-organization in the context of Scrum. Many mistake self-organization to mean “The team can do whatever it wants”. However, this is most definitely not the case. Most obviously, the team needs to deliver a product that conforms to the stakeholders‘ needs. Also, a team will be expected to adhere to both written and unwritten rules within the organization, on a technical, organizational and cultural level. For example, the company might want to enforce certain coding standards across all teams to ensure a minimum level of quality and mutual intelligibility of the code between teams. Or the company could have certain rules for handling bug reports from the customer. In these cases, a team cannot simply change these rules with the excuse that they are supposed to be self-organizing.

Also, a Scrum team is obviously expected to follow the Scrum rules. The water in the water bottle metaphor can flow freely within the confines of the bottle, but no further. The walls of the bottle are hard limits, and when the bottle is poured out, while the single water molecules are not controlled directly, the water is not given a choice as to where it can flow.

This might sound very strict, but the Scrum rules are indeed strict rules. This surprises many who have heard about Scrum only through hearsay and who equate Scrum or agility in general with chaos. I always like to emphasize that Jeff Sutherland and Ken Schwaber come from a military background, and while I have no proof that this influenced the strictness of the Scrum rules, I like to claim that it did, just to drive the point home.

Of course, in the true spirit of shu ha ri, a highly mature and experienced team will eventually begin to tailor the rules of Scrum and to shape them in a way to adapt to their specific needs. However, this is really reserved for experienced teams with a deeply rooted agile mindset and a great culture of self-inspection and self-improvement. This is not a first step for a team, but it is essentially the „endgame“ of Scrum. These experienced teams can shape their own framework, but the majority of teams will have adhere to the Scrum rules. And while this does seem confining, there are processes which give even less freedom, as they attempt to plan each developer’s work down to what they are supposed to work on each single day. The Scrum rules are strict, but they give the developers a lot of freedom to organize their own work and to decide how best to deliver great software.

 

Many people seem to find it difficult to understand how Scrum is a “framework”, so Scrum is frequently called a “process”.

When trying to explain the difference, I like to use the image of a bottle, which serves as a “framework” for water molecules. Let’s say your goal is to pour water into the bottle and then to pour it from there into a glass. The bottle serves as a framework for the stored water, making it conform to a certain shape, and when you pour out the water, the bottle’s neck becomes the framework for the flowing water, making it flow into a certain direction.

In the end, you have achieved your goal of getting the water into the glass. However, you have never attempted to exert control over single water molecules. You have not tried to determine where each molecule will be located in the bottle and you have not attempted to make them leave the bottle and enter the glass at a specific point in time. You have only given the water a framework for reaching the goal, but beyond that, the water was free to self-organize. And despite the fact that the movements of the water molecules are completely chaotic and unpredictable, you would probably be quite confident that you will reach the goal.

However, if you tried to pick out the water molecules one by one, transferring them to the glass in a predetermined order – that would be a process, not a framework. And that is essentially what the (for the purpose of this metaphor not very aptly named) waterfall process is trying to do.

I always feel that Scrum trainings neglect to mention one critical point: Not everyone is well-suited for every Scrum role. Perhaps the reasoning behind not mentioning this too clearly is the fear that some people might immediately think „Oh, Scrum is not for me!“ This would possibly even be a correct conclusion (I strongly believe that Scrum is not for everyone), but perhaps many Scrum trainers feel that they don’t want their audience to reach that conclusion during their training. When I introduce Scrum to people, I always emphasize that there are different characteristics or qualities that one should possess to fill a specific role in a Scrum Team.

So obviously, I have a long list of characteristics that I believe a Scrum Master should have. I am sure it is not an exhaustive list, and I am sure there are certain points which are disputable or controversial. Also, different Scrum Masters have different styles, so the different Scrum Master „flavors“ would influence the composition of that list.

However, I believe there is one point which in im opinion is absolutely essential: I believe a Scrum Master needs to be an optimist.

Scrum Masters need to be optimistic towards the teams: It can take a great amount of optimism about a team’s willingness and ability to self-organize when given the freedom to do so.

Scrum Masters need to be optimistic towards the project: Especially if you have already seen projects fail, it can be difficult to believe that a project can succeed (or even is more likely to succeed) without top-down planning, a command-and-control structure and intense micromanagement.

Scrum Masters need to be optimistic towards their role: They need to be intrinsically motivated to fulfill their tasks. Otherwise, they cannot expect team members to be intrinsically motivated, which is a key aspect of encouraging a true agile mindset. A Scrum Master who is a Scrum Master because „I do this, because it’s my job and I get paid for it“ must expect the team members to feel the same way.

I believe that optimism is the key quality of a Scrum Master not only because optimism leads to trust, perserverance and intrinsic motivation, but also because in my experience pessimism is deeply ingrained in non-agile processes. Cynicism, defeatism and mistrust can be found in many aspects of waterfall-like work modes, so I feel that a pessimistic Scrum Master will either not reap all the potential benefits of an agile approach or – even worse – will unwillingly assist in turning the Scrum framework into a Scrumerfall cargo cult process.

Many companies have multi-site setups, and there seems to be a general feeling that these sites have to collaborate intensively, or else the companies’ efficiency will suffer from the competition between those sites. The result is obviously a killer for agile teams, because when you take this site cooperation to the extreme (and I have seen it taken to the extreme), you end up with agile teams split up across two or even more sites.

So far this is nothing new. We all know that distributed agile teams are not as efficient as collocated agile teams. But the reasons why companies keep creating distributed teams are rarely addressed. I believe there are two fears which need to be understood here:

1. Fear of a lack of competence: Often, different sites might have different competencies. So obviously, if you want to build a cross-functional team, the first impulse is to bring in people from different sites to represent all the necessary competencies. What is the result? You cement those competence silos. After all, you can always count on those experts from the other site to help you out. Site collaboration is a part of the company culture, so why change anything? In fact, building up that knowledge in another site is seen as a threat, so don’t touch the status quo – and this brings me to the other fear:
2. Fear of competition: The naive assumption is that if sites do not collaborate, they compete. There is an implicit conviction here that there cannot be anything in between these two options. “What? You are not collaborating with site XYZ? Why do you hate those colleagues?” If two sites are not actively contributing to each other’s work, then they must be scheming to get rid of each other.

I believe the most important point to understand is that there is a middle way between collaborating and competing: Giving sites independent interesting long-term tasks and topics to work on. The disadvantage is that this actually requires managers to think about how to cut the existing work into such independent tasks. The advantage is that it eliminates all the inefficiencies created by forced collaboration and it forces sites to build up competencies to become independent. If there is any competition between sites in this model, then it is healthy competition. Nothing wrong with that.

The way there might seem difficult, and perhaps it is not something that can be achieved overnight, but I believe a company should make site independence a clear well-communicated near-term goal with a first intermediate step being the promotion of „T-shaped sites“.

And of course, I know that this model can create a third fear: The fear of obsolescence. When sites are completely independent, then any site could „lift right out“ of the organization when the management decides that it is time for headcount reduction. That is definitely not an irrational fear. But we should not see this as a problem but as a chance. A site that is independent and capable of delivering products to customers without having to rely on anyone else can also quite easily be transformed into a company by itself. When single employees are laid off, they have to search for new jobs by themselves. If an independent site is carved out of a company, it can survive as a complete entity even outside of that company.

So I believe we need to get away from the idea that site collaboration is a „good“ thing in a multi-site setup. It is not. Site collaboration is an efficiency killer. The real positive opportunities lie in letting go of forced collaboration and in promoting site independence.

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).