Half in jest about top Scrum challenges

Scrum Master comes to the rescue

Yes, as I have already revealed in the intro, most of the time, I am a “life-buoy” Scrum Master, which means I show up when all that could go wrong in the project has in fact gone wrong: nothing seems to work, the project is behind schedule, and everyone is frustrated. As you can imagine, that hardly makes for a comfy work environment!

Just between you and me: the projects I find the hardest are those in which the team is 100% confident they have been working in Scrum.

When this is the case, they will usually start with a complaint: “Um, Scrum doesn’t work! We’ve tried!”. It really takes heaps of patience and determination to turn their thinking around and show it’s not Scrum that’s to blame, but their inability to use it.

Scrum team

When this happens – and I say it only half in jest – I first need to step into my therapist role (and believe me, I’ve had some experience in this department!). This is especially helpful at the outset, when the Scrum Master is called in to make the Scrum team (including the Product Owner) shift from survival mode to creative mode.

You can’t really work efficiently with a knife at your throat, so when I come to the rescue, I first say “cut” and try to go back to the roots. Unfortunately, very often rituals are the only agile element in such projects.

You know, the project team uses Jira and holds meetings, but they don’t really understand why they do it at all (if it’s on the calendar, you just have to do it, period). By going at it this way, they get the false idea that their project is in fact agile.

I’m not saying this to accuse anyone of anything. I just want you to realise that, as I see it, the only sensible way out of a fix like this is to actually cancel ALL meetings.

And then what? Then you set a date for a new “first” meeting, when I will calmly explain the real meaning of the Agile framework exactly and outline the fundamentals of Scrum.

Scrum methodology

The essence of agility, including Scrum, lies in continuous decision-making that stays in touch with reality. You can accurately calculate your travel time from point A to point B, even including weather conditions and usual traffic jams, but you will never be able to predict things like, e.g. a road accident.

Your team needs to understand that project reality is no different from reality as such. This idea must be fully internalised; I don’t go on to introduce any practical applications before everyone has caught on to this fundamental truth.

The upside is that most project teams at this stage are slowly getting wind in their sails and really want to know how to put agility into practice and how to start building requirements. These seem like really good questions to me, especially since sometimes, during an audit, I go through the team’s Jira, see tasks marked as user stories, and guess what the only entry there says…?

Larger font.

Seriously.

What do Kant, Lean and Agile have in common?

Before I sat down to write this article, I took a moment to reflect on what happened in my life that made me turn to Agile.

I must confess that everything started a long while back, in the 1980s, when we read Kant’s philosophy in school. The categorical imperative that impressed itself on my memory at that time was that under no circumstances must we ever treat man as a means or tool to an end.

Later, in early 1990s, I learned about Lean or, more specifically, about the production system at Toyota, which was very popular among the company’s founders at the time.

So when Agile and Scrum first came into fashion, I was no longer able to think outside the Lean framework. In my project practice, I always fall back on Lean problem-solving methods or adapt my tools accordingly.

In my opinion (and I will always stand by it!) tools should always be secondary to principles. In emergency situations, the team first needs to cool down, and then it is our duty as Scrum Masters to make them understand why they should pick the Agile over the YOLO methodology😉

It is only then that any organic work, such as productive meetings, can properly take off. You can learn more about the meanders of scrum methodology in an article written by my colleague: Scrum Masters in early project phases.

Measurement: oppression or optimisation?

At this point, I must emphasise that the role of a Scrum Master is to keep their finger on the pulse and monitor process effectiveness.

They also need to make teams realise that performance measurement is not meant to control them; it is to help them see if they are on the right track and understand how they can optimise the process. In addition, the burndown chart is not the only benchmark you need.

During meetings, Scrum Masters may use Jira tools, for instance. My personal favourite is the Fix Version chart, as it allows me to visualise important facts as a springboard for discussion: is the outcome good enough or is there something we can still improve on? And there is almost always some room for improvement.

If you want to know more, read this article: Scrum like Waterfall, or how to manage team work to deliver software development projects on-time.

Of course, you can also put more pressure on your team and push the envelope, forcing people to work themselves to the bone.

But just as a nitro car will only take you so far, your team may burn down a lot of story points in one or two sprints, but then it will go through three more sprints of crisis before they recover. And who will laugh last if frustration and fatigue hit the zenith midway through the project and people start to hand in their resignations?

And this is how we have come full circle. Kant was right: you need to treat people like people, not tools.

Scrum Master vs Project Manager vs Product Owner

Often, when I am asked to audit an ineffective software development process, I come up against a lot of resistance from the Project Manager or the Product Owner. This is probably because of a basic fear that my presence there means they have done something wrong and now I’m going to oust them and take over.

It is true that sometimes the roles of Scrum Master and Product Owner can clash a bit but let’s keep in mind that, after all is said and done, we are all working on the same software. We are not rivals, we are not adversaries; rather, we want to know how we can help each other.

I don’t want to take the Product Owner’s job and create requirements myself. Quite the contrary! It’s my role to make sure they do their job as best they can! And since one of my tasks as a Scrum Master is to engage in process thinking, I will also support them in process mapping.

My experience has taught me that sometimes, caught up in the middle of things, the Product Owner fails to see the wood for the trees; they can’t see the process as a whole the way that an outsider can.

An outsider like me, for instance. You need a certain degree of distance to ask seemingly naive questions that nobody else will ask and put the team on a more effective track.

As a wise man once said, “he that nothing questioneth nothing learneth”, and Scrum Masters especially need to question a lot.

Watching client needs

Let me give you an example. I once met a Product Owner who had been tasked with creating a product that would process incoming bookkeeping notes more efficiently.

My first question was: Bookkeeping notes? But what on earth is that? If they made a mistake in their paperwork, they explained, their accounting office would issue a note telling them what they needed to fix. 

This sounded easy, but when I saw the sheer scale of it, how many such notes they got each month, I started to dig further. Was their problem really to do with bookkeeping notes? Maybe the root of the whole shebang lay elsewhere? Like, in the way they issued their documents? 

It looked like everyone needed a cold shower to understand that if they filled out their documents correctly, there would be no more bookkeeping notes, and the new product would become completely redundant. 

Product vision review 

And this, too, is the role of a Scrum Master. Scrum Masters need to break the mould, declutter project space and clarify the scope of the project.

Sometimes habits die hard and make it difficult to step out of your mindset; fortunately, the Scrum Master arrives to help you with a completely clear head. 

It is also my role to keep things realistic. Let’s be honest, not all functionalities are really necessary and people (including POs) sometimes overdo it.

Especially when competition in the market is keen, companies try to outdo one another creating new solutions and adding functionalities nobody else has released yet. 

They will often find it hard to admit, even to themselves, that if nobody has released these solutions it might be because nobody really needs them. 

Scrum Master vs Project Manager  

Hmmm, and what about the Project Manager?    

Sometimes, I am approached by a Project Manager who asks: OK, so what do I do now? I usually tell them I don’t know, because the Scrum Guide does not discuss their role 🙂 

In reality, however, the Project Manager is extremely helpful in terms of organisational and administrative tasks; they also help me eliminate obstacles faced by the project team. My role, in turn, is to relieve them of many of the tasks related to team performance and provide important performance measurement data, as well as relevant explanations. 

Myths and misconceptions that hinder agile management

In this section, I would like to discuss several problems and misconceptions that I often come up against and which are the kiss of death for Scrum. Let these examples come as a warning to show that the methodology can’t work miracles if you don’t understand it or stick to its principles.

Too much of that Scrum

I remember a project where everything was ready and we were all set to go when, suddenly, the client burst out: but I don’t want too much of that Scrum, OK? We were stumped because: how do you tell if there is too much Scrum? It soon turned out that what the client meant was too many “weird” meetings with complicated names. 

The team was expected to focus on c o d i n g.   

And again, I had to take a step back, run a quick primer workshop on methodology, and explain what these exotic-sounding “sprint reviews”, “refinements”, and “retrospectives” were all about.

This is why I so often emphasise that our role is also to make people aware that Scrum is a carefully designed methodology, which plays an important and common-sense role in maximising performance and productivity in agile teams. 

In this particular case, it was only after the second iteration of the workshop that it finally dawned on the client that a refinement, which only takes two hours, will actually save them six more they would otherwise need to spend answering the same questions and clarifying doubts.

The bookstore curse

Have you ever been to a large bookstore and seen a shelf crammed full of motivation and management books? Dozens of titles promising you can do much more, much faster. The problem is that some managers only read the titles and never look between the covers. 

In this way, for management, it often becomes an end in itself to do more and do it faster, just because the experts say they can.

So when the project suddenly begins to fall to pieces and the Scrum Master steps in with their usual talk of rules and principles, the first thing they usually hear is: no, no, we need to do more, do more, do more. 

There is never any time for Scrum, even though, in theory, that’s supposed to be the methodology of the project!

The clickbait plague

As you can see, unfortunately, Scrum is often looked at through the prism of clickbait titles and blown up promises.

Many people still think that if they’re agile, they will easily handle any extra challenge that might come up during the project. And this is true in theory, but it will also take its toll on project budget and schedule. 

There are no miracles. 

And let me add something that may sound controversial: Scrum is a product development methodology, but not necessarily a project management framework.

As Scrum Masters, first of all, we try to keep our finger on the pulse and make sure we are creating a valuable product.

A penalty Scrum Master

To wrap, let me tell you what I was told once. I’m still laughing…to keep from crying:  

If you don’t work well enough, you’ll get a Scrum Master, and he’ll scrum you up nice and good before you know it. 

Scrum Master as team member

To recap: in an emergency project, or a project where I am “let in” to somehow improve outcomes, the big challenge is to make my role clear to the team.

First, I need to make them realise that I’m not an extremely well-paid secretary; I’m not there to put events on the calendar. I’m there to stand guard over the logical development process, in perfect alignment with the product vision, and ensure a methodical approach to problem-solving. 

My role is to make sure that those in charge of delivering value can deliver it with as few obstacles as possible. 

And under humane conditions. 

After all, we are all at our most creative when our dignity and agency are respected. 

This article started with what may have sounded like a complaint: that I all I do is audit and look at other people’s processes. But, in fact, a lot of cool feedback can be gathered through an audit.

Not everything is always wrong; sometimes all it takes to boost the quality and effectiveness of your software development process is just a little procedural fine-tuning.