How to properly teach C-level management about Scrum

Last post 06:35 pm June 1, 2022
by John Taylor
7 replies
Author
Messages
04:44 pm May 19, 2022

Hi Scrum.org community,

I've been reading through several threads and gaining lots of useful insight to aid our department's adoption of Scrum. As a department (R&D), we've grasped much of the concept and necessary mindset change to make the switch from waterfall to agile over the past few months. I've been fulfilling the role as Scrum Master and am now needing to expand to higher management in order to educate them on how this methodology works. My manager (who is the PO) has felt some resistance from the C-level execs in explaining Scrum to them. Their major gripe was viewing our department from the old-school POV of "why isn't everyone busy" or "this guy isn't working on anything".

While I clearly understand "making sure everyone is busy" is an impediment on it's own, how do I best educate upper management on the fundamentals so they understand why that mentality is no longer valid for Scrum? After all, I imagine their goal should be seeing functioning products out of our department, not ensuring all team members have something to do.

I apologize in advance if I've left any necessary details out. Just ask.

Thanks for the help!

07:40 pm May 19, 2022

My manager (who is the PO)

There's a problem, right there. In Scrum the PO is not your manager or the manager of anyone on the team.

It's important for a team to get its own house in order first, as far as possible, so organizational constraints then become more obvious. It's possible that this is one, in which case you can use as a vehicle it to promote action from senior leadership for systemic change. A Scrum Team is one of self-managing peers through which agile outcomes are then achieved.

01:57 pm May 20, 2022

One of my favorite lean quotes is to "watch the baton, not the runners".   Focus should be placed on the work being done and the progress being made, not on whether every individual has been prematurely optimized for productivity.

When purchasing software for personal use, do you ask yourself the question "does this product provide value to me?", or do you ask the question "I wonder if everyone who worked on this product was busy the whole time?".

If the team is delivering quality work at a pace acceptable to customers and the business, what difference does it make how busy some workers were in comparison to others?   Do we 'Trust' (one of 5 Scrum values) the team to self-manage around both the work and any effort inefficiencies within the team, or do we prefer to micro-manage them in a command/control dynamic?

Hopefully, this gives you some insight into engaging with your C-level management around this issue.

07:46 pm May 20, 2022

I agree with @Ian about your Manager being the Product Owner. What I typically see and advocate is that the Product Owner is someone that focuses entirely on the Product and has no other responsibilities.  The Scrum Master only focuses on teams ability to be productive and efficient at delivering consistent value to the stakeholders.  I also really like the baton reference from @Timothy.  That is such a great analogy. 

At the Executive level, the focus is on making sure you are not wasting money so that the company can remain profitable.  In the days of yore, that meant that you did not pay someone to sit idle.  That was thought to be the best way to make sure the money you are getting from customers was not being misspent.  However, it didn't take into account that some of those busy people were doing things that the customers didn't want or would not use.  Releasing new things was all that mattered.  In today's world of agile, the focus on delivering what the customer wants when they want it based upon their requests.  

You might want to look at the Evidence Based Management (EBM) materials on this site. I would also suggest that your leadership read it also.  This will help set a common level of understanding on how to evaluate the right things.

12:31 pm May 23, 2022

Thank you guys for the answers and feedback. We're most of the way through our second sprint and will bringing these points up during our retrospective this week.

Any other advice is still welcome!

08:25 am May 24, 2022

Hey John, I've been in this position so many times, what is x doing? could he be doing more? we don't have any front end work in this sprint, is y just sitting around ? Senior management sometimes have a habit of falling in the trap of fine tuning efficiency at the micro level. There's a word for that!

My preference to counter that and bring the senior management on the journey is to focus on the important metrics, like you say the value being created for the customer. Consider, with reference to your particular product, how you can surface those metrics, maybe less calls to the call centre, less bugs, less downtime, more ideas to customer thank yous, more customer satisfaction, even something as qualitative as customer confidence. 

I think this is expected as you move from waterfall to agile so please view it as a journey rather than an event. Happy walking :)

12:18 pm May 25, 2022

 "  the switch from waterfall to agile" indeed is a mindset transformation journey . I agree with all the contributors and suggest organizing an Agile Discovery Leadership workshop for better understanding and appreciation of the Agile way of working.  

06:35 pm June 1, 2022

Thank you for the suggestions and advice. It is somewhat reassuring to hear that it's part of the journey but I do understand that change is necessary. We'll continue to work at it. As some of the earlier ones suggested, we're taking a step back and really assessing our Scrum team first before branching out of the bubble.