Confessions of a scrum master part 2- How to Succeed at Scrum by Guylaine Drolet

Don’t you hate it when people put pineapple on a pizza and still dare call it pizza? I’m kidding of course, but unfortunately that’s how sad I feel when people do Scrum without the adequate mindset.  

Grab a coffee and let me explain why they call me an agent of change.

(If you haven't yet read the first post in this series, I invite you to do it now!)

If a team implemented all the Scrum ceremonies, why do they need you?

Harsh but genuine question. It’s not because you organize Plannings, Retrospectives, and Reviews that you are Agile. I think that’s the most important thing to understand. Doing Kanban, Lean, XP, or even Scrum without being agile in the first place gives lieu to… something, but it’s not these frameworks.

These frameworks reside in the agile mindset and without that mindset the frameworks are incomplete.

Don’t get me wrong, Scrum can help. It means you track stuff over 2-3 weeks instead of months. But in the end, you’re still doing the same work you would be doing in a waterfall model.

Amidst all the preparation and ceremonies, I must make sure that the Scrum team and the organization embrace the agile mindset as well. The hurdles will be many, believe my experience.

What is the difference between Agile and Waterfall?

Waterfall attacks every different part consecutively. The point is to do things in a certain order and staying on a predetermined track. 

Agile on the other hand is an iterative process that looks like the graphics on the left

Rinse and repeat for every iteration. Agility is driven by goals rather than scope.

Agile values allow to understand this a bit better:

  • Individuals and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over Contract negotiation
  • Responding to change over following a plan

I’m going to go on a tangent here because I think people need to understand that it’s not because I’m a Scrum Master that it’s “agile way or no way”.

I genuinely don’t believe that.

Agile doesn’t fit in all work models and sometimes waterfall is the best choice. So, ask yourselves that question before you start making the transition to agile. Like building a house for example… please don’t Agile that. That would be terrifying.

Why adopt the agile method then? 

A Product owner I used to work with would say that the feature we are currently working on is either:

  • Already delivered by a competitor, or
  • Already late. Waiting is no longer an option.

I’ll say this, I’ve heard a lot of people saying, “Agile lets you deliver faster.” It’s not true. And it’s also not the point.

That’s not what Agile is about

Agile is about delivering the right thing. You don’t deliver more; you deliver exactly what your client wants. You base your value on your client needs: customer centric.

We don’t start with something massive. We start with something that works. A very simple something that works. A VERY simple minimalistic thing that works.

That’s what we call a minimum viable product or MVP.

If we threw the MVP on the market now, it would work, and we’d already be able to collect feedback on what works and what doesn’t. We’re shortening the feedback loop, which is crucial to building the right thing. Then we build over that MVP, refactoring in the process should it be needed. Iteration is key here!

When we fail, we want to do it as soon as possible so we can go back on the right track and learn from our errors. Noticed that I used “when” and not “if”. We will fail and we need to be in an environment that allows it.

Now for a perfectionist like me, this was a very hard notion to grasp when I shifted from being developer to Scrum master. The “what if” started filling my head and I was worried about building something wonky and out of place.

But that is also when I learned to trust.

The Product Owner I used to work with went on to say that it was all a matter of trust. He trusted me to make sure that he was efficient and that he communicated with the DevTeam properly and he trusted the team to make the right decisions on how they would deliver value.

What makes for success in scrum?

Success is everything I’ve just described. Being a Scrum Master doesn’t stop at Scrum ceremonies, it goes way beyond that.

Being a Scrum Master means that you try to present a culture that some people will adore, some will be unaffected by, and some will hate.

As a Scrum Master you must learn, deal, and juggle all of this.

But the success of Scrum does not come from one individual or one mindset. It comes from a highly cross-functional team with a safe space to just be their best.

Develop the mobile games of tomorrow, today!