In the past two articles Doing Agile, Using Scrum and Including Values and Principles in Scrum, we took a closer look at the values and principles of the Manifesto and how these fit together. Though this could have been the happy end of the fairy tale, the reality is not that simple. I want to give you some insights into what reality revealed to me in almost 15 years of working in software development. And that is by far neither a comprehensive nor a universal list - just a compilation of some ugly truths to increase awareness and encourage inspection.

Getting Hands Dirty on the Job

Enough for the theory. In reality, the world often looks a little different - even with a deep theoretical understanding and, in the best case, with qualified training. Nowadays, there are a lot of people who are annoyed by Scrum. Or they are just indifferent. Why is that? Maybe because they might have had some bad experience with one of the following brutal realities.

Brutal Realitiy I: Fix-price projects

The following scenario is quite common: a project with more or less precise, long-defined requirements shall use Scrum. Why? Because Scrum delivers it fast, and the responsibility lies within the self-organized Scrum team.

Let us have a look at the term fix price project itself first:

Fixed price

• a set total price independent of the required efforts
• a defined scope

Project

• a set of interrelated tasks with a particular goal
• a planned start and end

So, there is a fixed price, a defined scope, start and end. Now, we add agile to this project description. Do you remember the definition of agile in the first article? Correct, agile provides the possibility to move quickly and easily.

Fix-price projects often include a Change Request process to add flexibility as people worship Scrum for in-time delivery. To add more agile flaws, the team works with the Scrum methodology by having the defined roles as developers, a Product Owner and, with some luck, Scrum Master. Et voilà!

This setup is so typical that it even got names like Scrumma-Fall or Water-Scrumm-Fall.

So, where is the problem? What makes this setup so brutal? First, it causes a lot of effort upfront to specify all requirements in detail. In addition, the contradiction of fixed duration, price, and scope kills one of the main advantages of agile methodologies: The quick reaction to new insights and market changes. The continuous improvement process is not exclusively meant for the functioning of teams but also for reacting to changing demands.

Brutal Realities II: Wildest Expectations

Because we gain a certain degree of flexibility with Scrum, expectations might go wild. But the reality is that everything comes with a price. Most of us have heard about the magic triangle. Consider adding another dimension: quality.

The rest of the story becomes clear: changing one of those dimensions affects the others. Adding more scope, e.g., impacts either time, quality or pricing. That might be nothing new. But it’s worth to mention it again and again.

So, one of those wild expectations is about the scope. Or even more specifically about the communication of it.

Communications often focus on the what and rarely on the why. But defining every detail upfront will probably mean higher costs. On the other hand, resetting the focus on the why allows a more collaborative and creative outcome. That is why you shouldn’t omit the last part of a User Story sentence („As a [role], I want [what], so that [result]“).

Communications can also suffer from time limitations. Let’s look into this dimension in more depth.

With a clear scope and a precise what, the assumption is tempting that everything should be clear and everything has been considered. Additional time, except for some tiny clarifications, is neither required nor planned. Reminding ourselves of the continuous improvement cycle being rather a nonstop process than a one-time activity, the impact of lack of time can be very diverse.

So, we inspect it briefly based on different roles.

Product Owner with limited capacity

• No priorities
• No clarification of the unknown
• No regular exchange with stakeholders
• No contact person for the whole ecosystem

Developers with a tight time budget

• No time for quality
• No optimization of processes and collaboration
• No time is reserved for exploration (everything is specified beforehand and is assumed to need no further attention)
• Should only code as told

Last but not least, the most underestimated role - end users and stakeholders

• No readiness to explore the current state of the new deliverable
• No sharing of what they need and use
• No feedback
• Etc.

These aspects make the reality brutal compared to expectations and leave no space for inspection & adaptation.

Brutal Realities III: Cargo Cult and Cherry-picking

What happens if you just mimic a certain behavior and expect a specific outcome? Nobody knows!

Again, the why is the key. Ask yourself why a behavior leads to a result instead of just copying it. That also applies to slavishly following a software development process without understanding its reasoning. If we do not know why we are doing a Retrospective or a Daily and how all those events interconnect, then it won’t have the desired effect. This behavior might be known as a cargo cult.

Missing knowledge also leads to declaring an event as unnecessary. A Retrospective is, for example, perceived as time-consuming, worthless or a blame game. That might be true for some teams. But the reason behind it is often a lack of knowledge or professional facilitation.

There might be exceptions. But knowing the purpose and having a well-facilitated event helps a team to reflect on their own (inter)actions and improve.

Another example is the Daily. The attitude towards this event is broad and controversial - no matter if people use it as a status update or an opportunity for discussions. The execution varies from “once a week” to “one hour a day”. A capable Scrum Master can not only improve its execution but also transport the value of the event.

Let’s come back to the aspect of cargo cult. Execution only does not guarantee success. Dogmatically following the described trails won’t spark pure magic. The Scrum Guide even states: “Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum”. That means we should be aware of why we are conducting such events.

No project is successful just for the sake of applying Scrum. It might even get worse. The trick is what you take out of this.

Scrum has one powerful side effect if we know how to use it: It uncovers problems. But what might happen is that people identify Scrum as the cause. That is much simpler than digging for the roots.

Brutal Realities IV: Visualization of Work and (subtle) Pressure

Estimations and a Sprint Scope help a lot to track the progress of a project. You can use the velocity a Scrum team has to plan the next steps. But what if the team did not finish the scope at the end of a Sprint? Or what if the estimation does not fit the needed time?

Maybe a new insight led to more effort or new dependencies. Or there is an inefficiency in the process that no one considered yet. Also, the velocity and estimations can be misleading if the team constellation is new or there is a change (of team members). Thus, these figures might be misleading and result in the perception of or exposure to pressure. Dealing with pressure leads to demotivation and a lack of psychological safety. This state can lead to multiple new issues. Since transparency shows this gap obviously, it can decrease appreciation for the efforts taken, more defensive and higher team estimations, a higher probability of inner resignation, and many others.

We all agree that simply accepting the miss is not an option. Blaming the team or an individual should not be the solution either. But how can teams move on from here? Maybe Scrum and all its time-consuming events are not the right approach? Whatever it is, do not answer this thoughtlessly.

Evaluating the root cause behind this is what matters. But beware! This part is multi-layered.

Although Scrum could be the wrong decision for the situation, you should justify this conclusion with objective reasons. Agile processes, as already stated, are not a guarantee for success, but what they are pretty good at is revealing issues. Stopping the evaluation at this point can be a waste of potential. Work together as a team, use transparency to dig deeper, and try to find the real reasons. That is more challenging than blaming somebody or something. But there are a lot of supporting mechanisms, e.g. Retrospective formats, which can help. Once you identified some areas, try to improve them together and inspect the results this brings.

With an attitude more open to failures, you might overcome those obstacles and learn more than just making a hasty judgement.

Failures are not bad per se

In terms of “inspect and adapt” failures are not bad per se. Learn from them and don’t do them twice. The same goes for the ugly realities presented. To sum all up, our takeaways are:

• know it - do not assume it
• choose your tools wisely (methodologies, practices)
• be aware of the why - not just the how (your goals you want to achieve / pains you want to heal)
• working agile is about people!

Keep calm and inspect & adapt