Why does management have to "buy into" Scrum?

Question

I have read over and over that in order for Scrum to work, "Management has to buy into Scrum." Can you tell me why that is? What management are they talking about, the company stakeholders that have paid you to build it, but are not on the development team?

What happens when Scrum is used, but Management hasn’t bought into it? Why does it matter?

What is it that Management doesn't see that they don't like not seeing? You don't have deadlines and budgets using Scrum?

It seems to me the bottom line is trust the dev team and give them what they need and they'll do you right.

Answer 1

Speaking from experience...

I once attempted to bring Scrum into a situation where:

• We currently had little-to-no defined process for development - people just got assigned work, did it, then got more work.
• Our direct manager was indifferent/mildly hostile (think "I don't like this new-fangled way of doing things, but I'll let you work how you want. Just keep me out of it.")
• The Team was relatively enthusiastic but used to a non-Agile mindset
• The CEO was very waterfall-oriented (and communicated only with other executives, who were also waterfall-minded).
• I, someone who had 3 months' experience as a developer in Scrum, was chosen as the Scrum Master (as no one else knew anything about it), with no budget for training or hiring an Agile Coach.

Now, while this might sound like a disaster, it wasn't... terrible. We completed our big, 2-year project only about half a year late, and having completed all features.

However, we could have done better.

We tried to keep the manager aware of our process and status, but he grew increasingly uncomfortable (due to how strange he found it), and eventually simply wanted no part of it... and was later upset at being blind-sided by a certain delay in the project that, had he been involved, he could have mitigated.

As I noted, we completed all features... because once a feature was accepted, it must be included... even if the users never really wanted it in the first place. There were some features that, years later, had never been used once. Had we started by developing a Minimum Viable Product and then soliciting further requirements, those features would have shriveled up and died. But we were forbidden from showing the incomplete product to the users.

Nonetheless, both my Team and I felt, at the end, that our mangled, half-Scrum approach was better than what we'd had before. We didn't regret attempting it, even without stakeholder buy-in. It just could have been so much more.

---

You added:

What is it that Management doesn't see that they don't like not seeing? You don't have deadlines and budgets using Scrum?

in response to:

Many traditional managers are accustomed to "knowing" Scope, Budget and Deadline upon committing to a project.

The point is that in a Waterfall mindset, the idea is to plan enough that you are capable of divining the future, and therefore, once development has started, you get fixed scope and fixed cost and fixed schedule. Because they won't change, because you planned perfectly and the future never changes.

In an Agile mindset, you can only ever have, at most, 2 of those being fixed. Because you can't ever accurately predict the future, because the future will change. So there must be room to adapt. If all three iron triangle constraints are fixed, then there is no room to adapt.

Yeah, but you can't put them off forever. What do you say, "Oh, btw, this will change and we can't know when it will be complete?"

If you have fixed cost and fixed scope, then yes, you cannot know when a feature will be complete - until it is. As you get closer to that point, the cone of uncertainty narrows, but it only becomes a point once the feature is done.

Anything else is blinding yourself to reality by pretending you know when something will be done, when you actually don't.

Answer 2

Many traditional managers are accustomed to "knowing" Scope, Budget and Deadline upon committing to a project. Scrum takes all that away and promises to do its best.

Now you get one of these outcomes:

• Management says: In that case you are not doing Scrum. Outcome: No Scrum.
• Management says: Sure you do Scrum, we do waterfall and what we do counts. Outcome: Twice the administrative effort and no Scrum.
• Management says: OK but we'll remodel Scrum so we still get fixed Scope, Budget and Timelines. Outcome: Perverted Scrum.
• Management says: We see the benefits and agree to support this approach. Outcome: Eventually, hopefully Scrum.

Edit: Scrum does not concern itself with budgets. That's the job of the stakeholders/customers/management to determine if the progress being made is worth the funding invested. Deadlines are similarly meaningless in Scrum. In principle you can ship or shelve the project after any iteration and simply walk away. The argument of Scrum is that while it can't predict how far it will come by date X or when feature level Y will be done, it can tell you that at any point in time you will have the best product that can be had for the investment you have made.

Answer 3

There's a huge misconception (or difference of perception) of managers of programming teams.
What they think: "We set the project, features and timeline, and it will be done in that time"
What programmers think: "We have a certain pace that we can work at, work will not get done any faster regardless of what management is doing.

In waterfall management sets the specs and timeline. In scrum management asks for features and programmers give an estimate of when a feature is done.

Managers think that going from waterfall to scrum gives them less power over when and how things get done. Again, though, just giving a programmer a deadline on when things need to be done doesn't make the programmer be done with the feature within the deadline.

When management doesn't buy into scrum they're not involved in the process. They don't give the necessary feedback, they might dictate deadlines. All this might lead to more overhead, more meetings and unnecessary features.

Answer 4

Scrum can deliver software faster, better, and cheaper. But to realize the potential time and cost savings, stakeholders have to understand the process and be committed to fulfilling their role in it.

Understanding the process means letting go of the idea that everything can be planned up front. Business people are accustomed to having detailed plans and contracts set in stone at the beginning of a project. In my experience, the main obstacle to non-developer managers accepting Scrum is that only minimal planning is done up front, and the plan is not only allowed, but expected to evolve over time. This idea is central to Scrum. A detailed plan takes significant time and effort to produce, yet is inevitably inferior to a dynamic plan because even someone intimately familiar with the domain cannot envision how everything should work or anticipate every opportunity for improvement.

TL;DR:

• Management likes detailed and inflexible plans.
• If you're following a detailed and inflexible plan, you're not doing Scrum.

Answer 5

To add to existing answers, using my girlfriend's experience of her current place of work...

Agile development hinges on sprints. A key feature of a sprint is that you decide at the start of it what you'll be delivering, and that's all you deliver. The delivery date and the deliverable content are locked down at the start, everyone knows what they are, and they're set to be achievable. If new requirements come up, they go in the next sprint. Sure, you can cancel a sprint if it turns out to be fundamentally wrong, but otherwise the point is to deliver work in small chunks. Sprints are intentionally short because requirements are intended to change, so holding back changes until the next sprint is not a problem.

What you don't do as a manager when a customer asks for a change is to say "hey guys, I've got a new requirement here, add this to the sprint". And you make sure that none of your team members independently accept new requirements during the sprint, from anyone, or invent new requirements themselves. The Scrum Master is supposed to make sure this doesn't happen. If the Scrum Master doesn't have the authority to tell the manager to follow the process though, or to escalate if the manager refuses to, then you have a problem.

Best case when you screw up agile like that, is that you overwork team members who suddenly have extra work to do, or you set them up to fail, because the planned achieveable work may no longer be achievable.

Worst case, the team as a whole no longer know what the deliverables are. Coders may add features which testers are not aware of, or omit or change previously-defined features. Tests will fail, and figuring out why failures happened as a result can be incredibly time-consuming. Worse than that, new features may not be tested, so they may be released without anyone checking that they actually work correctly.

Answer 6

According to Cambridge dictionary "buy into" is a phrasal verb meaning "to believe in a set of ideas".

It often happens that when a company or a team migrates the processes to scrum the overall performance or results might not look good especially in the very beginning. This declaration means that the management should believe in scrum and be ready to wait for results even if there is no instant value demonstrated.

Answer 7

In most traditional project management mindsets, people are more concerned with their budgets and schedules for a project than turning out a usable product. They want to know what something is going to cost, how long it will take, and what they will get for their investment, all before any actual work gets done. It also assumes that the people asking for the product actually know what they want before they have anything to see or try. This leads to lots of documentation, no or minimal feedback mid process, and a lack of flexibility. There is an over emphasis on status reports and making sure everything matches the plan as originally laid out, and insufficient allowances for uncertainties and ambiguities.

Scrum, and agile in general, recognizes that the real world isn’t that structured and ridged, and that the people drawing up requirements won’t know what they really want until it is in their hands. It takes the approach of focusing on the most urgent thing of the moment, get it done, and move onto the next thing. It also relies on showing completed work to the stakeholders and end users as soon as possible, soliciting their feedback, and adjusting the plan accordingly. The overall goal is to always have the most useful product for the effort invested to date.

This does not play well with the traditional mindset because we do not have fixed timelines and rarely have a firm plan for anything that is more than a couple weeks out. We can report on the things that have been completed, what we are currently working on, and what we plan to start on next. But we can’t tell you when the project will be finished, what order features will come out in, or even guarantee that our “what is next” plan won’t change before we get to it.

---

To give a bit of a long-winded example, I once worked for a government agency, first as a developer, later as a team lead and manager. I am also a Certified Scrum Maser and Agile Coach, and I have worn BA and PM hats a fair amount in the past.

There was a phase where we were trying to “do agile” without any real support from our administration or stakeholders. Essentially the developers adopted some “agile” ceremonies, but everyone else was still turning out 30+ page requirements documents without involving the developers, demanding estimates for projects months in advance of when we would actually work on them, expecting us to adhere to timelines that were set without our input, pointing back to the documentation when we raised questions, and throwing fits anytime the project outcomes deviated from the requirements, timeline, or budget, regardless of the reason.

At its worst, what should have been a six month project took almost 2 years, and had to be rewritten twice because stakeholders changed, which changed the requirements, and even after the first rewrite, what made it into the requirements documents was still not what the end users actually needed.

Shortly after I took over as manager, I convinced people to let me run a project without interference. At first I was handed was one of those 30 page documents, with an expectation that we give an upfront estimate for cost and completion time so that it could go through the approval process. Normally this would have involved the manager(me) and possibly a team lead or senior dev going through the document in a day or so, and handing back some numbers that were 2 or 3 times what we thought they should be to account for the things we didn’t know and didn’t have time to figure out.

Instead I pulled the entire team in to review the document, break it down into features of a size that we could give meaningful estimates on, and plug it into our tracking system. I had to fight our PMO and other management repeatedly because we were taking too long and using too many resources to come up with said estimate (several 1-2 hour meetings over a couple weeks). However, in the end, we had a rough map of the work that was needed, every developer was in the loop on the direction and decisions we had made, and all had the opportunity to give input on the estimates. When we were done we presented a timeline of about 10 months with a cost that was calculated based on which developers and other resources we expected to work on it, and for what percentage of their time.

When said project was greenlighted a few months later (there was never any real question that we would do it) the first thing we did was dust off our previous breakdown, decide where we need to start to have anything to show for it, verify our estimates for that block of work, and toss the requirements document aside. I then set the team up with a near scrum approach, we ran 1 week sprints, with a release every 4 weeks. We had a stakeholder meeting every 2 weeks.

When the stakeholder meeting aligned with our release, we presented the new features, solicited initial feedback, and laid out our objectives for the next release. For the off cycle meetings, we were soliciting and discussing bug reports, and adjusting the release plan based on feedback from the end user testing. Again I made a point of having no less than three developers in the room for each stakeholder meeting, with the expectation that they would ask and answer questions as needed, but primarily so the team had more than one perspective on what was said. And again I got flack for it because I was “wasting” the budget by having developers sit in on meetings instead of coding.

At first it was a bit of a struggle to get the stakeholders to actually show up to our meetings, to the point where we suggested that the project be shelved since it apparently was not important enough to demand their attention. But after we got them into three or four meetings, where they could see the progress being made, and see their feedback being incorporated, they started being more willing to block out time for us. After about the second time where someone came out saying “this is cool, but what we really need is” about a feature, and saw the issue corrected in the next release or so, they were sold.

During the entire project I also was fighting a constant battle with the PMO over my status reports. They wanted to see the same types of project schedules and reports they were accustomed to, with features being checked off in a preset order and on schedule, and be able to match our expenditures to their budget projections. Instead I was giving them a report on story points that had been completed and accepted, estimates on points in progress and when they should be done, and revisions on the original estimates and timelines based on issues that had come up during development or testing.

They would throw a fit every time we re-estimated a story based on new information, added stories to track bugs, or broke things down into more granular work segments, especially if the change ended up changing the number of points in the project, complaining that we were changing scope. They also hated that my estimates were in points rather than hours, and wanted to know how to translate between the two. Eventually I put together a tool that linked task hours to stories to releases, and gave them a running average for points per release and hours per point, but they still didn’t like that it was not a fixed number and we refused to commit to a hard completion date until we were entering our last couple of release cycles, and it was obvious when things were going to wrap up.

In the end we finished the project in 11 months, were about 20% over our original budget, and had people actively using the product on release day, without a huge list of defects to delay the roll out. It was by far the most successful project ever completed for that agency in terms of meeting timeline, budget and usable features. To give some perspective, the norm for that department prior to this project was to be over on time by as much as 50%, at least double the budget, and have low initial adoption because the end product didn’t meet the actual needs of the organization or users.

In this case, I as the direct manager had bought in, and had enough pull and support from my supervisory chain to shelter my team and get away with bullying people from other silos into playing along, but the organization as a whole was not on board. Over the course of the project we brought most of our business side stakeholders around to supporting the methodology, but the PMO still only tolerated us as opposed to appreciating what we were doing.

Answer 8

Scrum or agility is about reverse accountability when it comes to management.

A traditional manager tells what, how, when. The team is accountable. If it fails, it's the team's fault.

A modern manager tells why and what, then supports its team in whatever way possible. The manager is accountable. If it fails, it's his fault.

When introducing Scrum (or agility), your traditional managers need to give up command and control and move to modern managers "trust and support". Usually, they don't want to give up command and control.

If they don't, then whatever you ask the team "hey, this is our objective", then you ask the team "hey we need you to be efficient", the team comes back to you "ok we need A, B and C", and you tell them "sorry not possible, you will have to do without" (usually because it threatens their position/politics/objectives, or simply because they think those employees should simply work harder instead of asking for support) and then complain about efficiency anyway because they need to justify why it's so expensive.

That's why they should buy in, because a team gets efficient if the organization is shaped around its efficiency, and who can shape the organization ?

Then the even more interesting question pops-up: how is it possible to make management buy-in ?

sidenote: about deadlines and budget: yes Scrum has those, and Scrum is dead-serious about it, much more than "traditional style", because it's actually centered around making sure something will be delivered and it should be so as efficiently as possible (meaning cost-effective), unlike "traditional style" which is not much more than a naive oversimplification that wants to convince itself that "complex things are not my problem"

Answer 9

Scrum is designed to operate as "self-organizing teams".

For many conventional managers who assign work to employees, this is a colossal change.

This requires the management to trust the team to select their own work, and to get it done without the help of the manager.

The new role of a manager in a Scrum based environment is that of a leader, making sure their employee has the proper skills and training to help the team perform to its highest level.

Answer 10

Answer

"Management has to buy into Scrum." Can you tell me why that is?

Doing (real) Scrum means that management is giving up a lot of control. Managements needs to know that, accept that, and really live that spirit. This is very, very hard, especially as experienced project managers tend to be more of a aggressive/controlling character, and this tends to be more so the higher up you go (at least in my experience, and at least usually - exceptions nonwithstanding).

One of the biggest parts you will notice if you look real hard at Scrum is that Scrum has only three roles: Product Owner, Scrum Master, Team Member. There is no project leader/manager!

At the core, Management has to buy into Scrum because they have to trust the process a lot, without being in control at all.

What management are they talking about,

Literally everybody in your own company and the customer's company that is not either the Product Owner, Scrum Master, or a Team Member.

What happens when Scrum is used, but Management hasn’t bought into it?

This is what happens all the time: The project starts, for the first few sprints everything seems fine. Then management gets impatient, and asks for long-term timelines, guaranteed feature sets and prices/budget (all of which are absent in the Scrum process). From there on, mistrust, unhappiness, failure.

The reason for this is, usually, in my experience, that management simply does not know enough about the process, and (not being a Dev, a Scrum Master or a P.O. themselves) has not really experienced it. This is a real conundrum and not just a blame on management. It's easy to say "sure, I'll give up control", but it is very hard to see what that actually means.

If Scrum people say that you don't know and don't care what happens after the current sprint, they mean it. Many managers (I knew) somehow thought that all of this was just a happy charade to make devs feel empowered. Many sat down with the P.O. or the S.M. right away and started to draw up monthly or yearly milestone plans, setting up expectations that, by design, just cannot be met by Scrum.

Why does it matter?

Because classical management focused on time, budget and quality is managing actively against the Scrum principles, for example that only the current sprint has a fixed feature set and everything beyond that is up to the P.O. to prioritize; or that the time=budget required to complete work items beyond the current sprint are not planned out in advance.

What is it that Management doesn't see that they don't like not seeing?

They are missing dependable, guaranteed promises on long-term milestones, budget forecasts and feature-sets.

Also, a large point of Scrum is shielding the dev team (during a sprint) from willy-nilly management decisions. As nice as this is for the dev team, you are also taking away power from management => not nice for them, at least psychologically.

I know this is a late edit, but it seems to me the bottom line is trust the dev team and give them what they need and they'll do you right.

Kind of. If you are talking about management's trust, you really have to include the Product Owner, which has some parts of the responsibilities that a Project Manager has in a classical project. Management has to trust the P.O. and the Scrum process.

Outlook

It is easy to fall into the trap of either thinking that management is just dumb (Dilbert's "pointy haired boss"), or that Scrum people are trying to live on a Pony Farm. The answer is in the middle. There has to be a lot of education going on. Or, if the company (or the customers, or the particular software) is just not that suited to a strict Scrum approach, mixtures have to be found (and can be found) which give some amount of control and long-term transparency back to management. As long as everybody knows exactly what's going on, there are plenty of variables to tweak.

Hints

Some Scrum Masters like to introduce Scrum to new teams and management by doing a very visible approach - i.e., skip Jira et al and go to whiteboard/paper based approach. It is quite educating when people actually stand up and move sticky notes on a wall around.

I prefer to not start with Scrum at all (in environments where people are not used to any Agile method, or where it is not clear that Scrum is the exact right thing, necessarily). Instead, a very light Kanban. This means picking a few instruments (board, lanes, concept of WIP, introspection etc.) which are transferable to Scrum later, but where the lanes can be adjusted to be have any titles you might like, and changed around more freely than in strict Scrum, but you skip the sprints for the first time (introspection etc. should be regular, of course). This gets everyone used to the general "instruments", and you can gradually make the process more rigorous if you so wish. This also does not take anything away from management, they can even put a real project plan on top of everything; it mainly focuses on making tasks and especially WIP visible.

Answer 11

It is very much similar to the fact that the Project Sponsor/Executive should be part of the 'plan how to plan' workshop at the beginning of the project. In essence, you have to set up their expectations and they have to agree on the deliverables and project approach.

Agile is a very different mindset than waterfall. It is not easy to translate an Agile approach into firm deadlines and budget terms, and management (and contracts) are all about deadlines, scope and budget.

Answer 12

All project management softwares are at the service of the project manager. They were created to help the manager lower the cost, increase the revenues and make a profit in a product development. That looks simple written like that but it is not. Many managers follow their instinct on the ratio cost/revenues, but in complex projects it is not enough. It is the deadline of each step of product development that is important to control. A deadline not respected in phase 1 has repercussions on phase 2 and so long, limiting or making disappear the profit. The project management softwares are used to limit the human errors; but you have to know them well and use them properly and it takes time and time is money. If I understood well your question, some managers have for that reason be buy into using Scrum.

Answer 13

Conway's Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

This was first documented by Melvin Conway half a century ago & dubbed Conway's Law in Fred Brooks' book - "The Mythical Man-Month". The Law has since been backed up by further positive research.

When developing software systems the organisational structures tend to dictate how software will develop. This is why if a hierarchical, monolithic organization develops software it will tend to want it produced in the same fashion - with GANTT charts, planning sessions, lots of forward planning months in advance & so on.

In essense if management doesn't buy into scrum & adjust the organization to work in a flatter, servant-leader type way then any attempts to introduce scrum practices will meet so many obstacles that they will be short-lived at best. Been there, bought that t-shirt!

Answer 14

If management doesn't "buy in" to scrum then management will ask for changes to a project during the QA testing of the project the day before it goes into production. These changes delay the project going into production. This gives management more time to think up more changes. These additional changes cause additional delays in the project going into production. Eventually, upper management looks at how long the project has been going in and that nothing has gone into production yet and cancels the entire project.