Author: Marc Greis

Various Scrum ceremonies are unpopular with developers for different reasons. One reason many developers give for not liking the Daily Scrum is: “We talk to each other anyway.”

Of course, it is true, especially when the team is collocated in one room – as it should be.

Still, it is one of the worst fallacies about team interactions, and it is not uncommon. Many people believe that only because they have said something, every intended listener has heard and understood the information. However, there are many cases where the information is either not heard or not understood.

If a team member is concentrating on other things, is listening to music, has left the room for a moment or is attending another meeting, then whatever communication is taking place in the team room will not reach that team member. So one purpose of the Daily Scrum is to consolidate all the communication that is probably happening anyway and to bring it into one short meeting where everyone gets on the same page. The Daily Scrum concept works directly against the “We talk to each other anyway” assumption.

But how can a Scrum Master convince a team that the Daily Scrum is necessary? I think the best way is to do this by recording events where the Daily Scrum has produced value. Every time when someone goes: “Oh, I didn’t know that” (or a variation thereof), the Scrum Master could point out that the Daily Scrum has once again proven its worth. Alternatively, the Scrum Master can record such occurrences, and the next time the team challenges the Daily Scrum, the Scrum Master provides a list of cases where the Daily Scrum was useful.

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.