We do Scrum but…

Our management doesn’t

A Kick in the ScrumBut — Episode 2

So, your team is exercising Scrum, however your management doesn’t (really get it).

Are you, as a Scrum Team tasked by your management to:

  • “Make sure to finish the Sprint on time?”
  • “Increase the performance/velocity of the team?”
  • “Make sure the team meets its commitment?”
  • “Report productivity and efficiency metrics?”
  • “Manage JIRA?”

Poor souls.

Perhaps management is not providing the support needed for the team to truly experience Scrum in all its glory. In that case you team might not be empowered to be as multi-disciplinary and self-organising as it should be.

  • Contracts are still fixed scope-price-time topped with extra strawberry, vanilla buttercream, iced-sugar toppings;
  • New employees are still shown around the company as if they are taking a tour in a Zoo:
“This is where we keep the Marketing Macaws, the Sales Lions, the Service Giraffes, Legal Penguins, and… in the basement… we keep the IT Ticket-Monkeys.”
  • Everything has priority (so nothing really does);
  • Management only involves itself post-mortem to lecture on what could’ve been done differently.
  • Forecasts are treated as deadlines;
  • Everything is just lipstick Agile; a major terminology facade:

As Scrum is a framework for developing, delivering, and sustaining complex products, and, if your management isn’t actively engaged in this exercise, it indeed may not make immediate sense for them to adopt the framework. Scrum could thus be perceived to be for developers only. Or perhaps Scrum was introduced by and is still contained to the development organisation.

In this case it may make sense to talk about the definition of ‘Product’. Would it make sense for the Management Team, to consider the organisation itself as a product? Could Scrum then be a framework within which they can address complex adaptive problems, while productively and creatively delivering an organisation of the highest possible value?

To us, Scrum Geeks, this would make sense; and perhaps, if your organisation is a Product Development oriented organisation (of any kind), or a maturing start-up, this may even be reasonable to consider. However, this is generally not the case. So then…

How can Scrum work as a container within an organisation?

This is where the play gets dirty. I took the liberty to take your organisation as a use case:

  • The corporate zombie army is dreaming up all sorts of playful, colourful roadmaps;
  • Targets are moving all over the place;
  • Everybody is getting on an off hype-trains;
  • Slide decks are thrown around as everyone fancies themselves to be the next Steve Jobs;
  • Meanwhile spaghetti mail-threads and limbo meeting chains pre-occupy half the enterprise’s FTE, thus generating a massive corporate comms pool of waste;
  • To make matter worse, this is all archived in the most dreaded place in corporate the web: your Intranet…

Dum-DUM-DUM! and you just feel like:

Now, in this series I promised we’d be kicking ScrumButs; and in this case, I really do need your help. There are many different approaches to take and it really does come down to you, yes you, to pop the bubble you are in. So here is a suggested approach:

Try to establish an Executive Action/Transition Team

To truly reap Scrum’s benefits, the C-Suite must lead a cultural change, right? Ok, maybe some of you will think: “NO!”; that is fine, I agree with you too; but if this is what it takes to get the Royalty in on the game, then such a cool, important sounding name will be hard for them to resist joining.

The EAT will manage a list on all actionable organisation change related to Scrum. We’ll just name the ‘Backlog’. Explain the EAT will get together routinely to keep track and review and inspect how things are going.

See what we are doing here?

Please take note that the members of the EAT, as they encounter challenges, will persistently challenge Scrum. It is important the Enterprise Transition Backlog lists all the ‘ScrumButs’ you encounter while the organisation is being dragged through its own mud. Explain what value is lost through this incorrect and incomplete application of Scrum (this series should help you with that).

Your go-to companion

“The Enterprise and Scrum” is your go-to companion during this journey. It will tell you when things will get truly hard, when they will get impossibly hard and that, when you finally made it through, it will tell you the princess is in another castle.

A disclaimer though: consider well, if this is what you want; the EAT could, and likely will, at first impose a form of micromanagement on your team(s); for better or for worse. The members of the EAT will, at first, have little understanding of what this transition actually entails. Your team will jump out of the frying pan into the fire.

Train the leaders to ‘Agile Leaders’

Surely, if change is happening, wouldn’t it be best for the organisation’s leadership to maintain the appearance it is powered through true Agile Leadership, instead of it being some rogue initiative by those dreaded rebellious developers?

Right! offer them Scrum.org’s Professional Agile Leadership Essentials Training.

Scrum.org is truly serious about Scrum. The leadership will not be able to sleep through their courses to get certified. They’ll truly learn that managing the organisation in an Agile way can be quite different from what they are used to. As a result your team might get sponsors who will actually empower, facilitate and enable your team(s).

Remain rebellious! 🏴‍☠️

It is very likely that your team is heavily underestimating its executive powers. Does your team understand that management too can be informed on a need-to-know basis?

Just casually get things rolling, and the rest, slowly but surely, will follow suit.

It is essential that the team empowers itself. In any case, they should make sure that continuous training and improvement is embedded in the routine. Even under pressured deadlines, keep taking the time to make it right.

This is about your development as a professional. Don’t allow anyone to limit you in your development, or limit the team in its development. What your team produces, represents you. Don’t forget this. When you are late anyway, at least deliver something great to make up for it. If you deliver shit under pressure, you will be associated with that shit.

Your team should take collective stances and display courage to uphold them. They should be somewhat cheeky while self-organising. Often it is better to apologise then ask permission; and better so when those apologies can be supported with awesome results.

Perhaps this bit of advise isn’t fully in line with the values of openness and transparency of Scrum, yet in any case:

Make progress visible (and colourful)

Nothing motivates management more than a big impressive wall with post-its flying across lanes, stacking the “Done” lane. Now, write some motivating clichés and some proud customer quotes — it’ll become a ‘must-see’ on the Zoo’s itinerary.

Help others out!

Now, to some of you battled Scrum veterans out there, who have gone through this painstaking, but oh so rewarding journey, please reach out, drop a comment, share a thought, present an idea, or barf all over this post, in support of our fellow Scrum practitioners.


Next episode

I hope you enjoyed this article and that it helps you in your quest. Please share your techniques in dealing with the above mentioned ScrumButs. Just drop them in the comments below, highlight the statements you found to be helpful, share them, or just have chuckle. Oh right, and don’t forget to clap! 👏 it truly means a lot to me if you do.