Obtaining Management Buy-in on Process

Question

The company I work for has historically had very little process as far as software development. Currently we don't really follow any specific method. The problem is of course it makes it difficult to plan, successfully have a decent release or even attract good software developers.

I think I may be able to convince them to do some sort of Scrum process. Key however is getting management/owner buy-in. The idea of locking into specific features for any period of time I think scares them off.

Does anyone have any suggestions on how I can make my case?

So far I plan to:

1. Give presentation on how Scrum works. how I see it working with the people we currently have and how it will benefit the business.
2. Ask for training for specific people so we aren't "making it up as we go along"
3. Set a date to implement, there is some planning and loose ends I probably have to tie up to start a process fresh.

Answer 1

Run the Joel Test to determine how much work you have to do. If you are having trouble estimating release dates, look into Evidence Based Scheduling.

Answer 2

Provide some sort of argument that shows how Scrum will address past pain points experienced by the key decision maker. Extra points if you can also provide evidence that demonstrates this.

Answer 3

Keep in mind that it is also possible that you don't have a process because the management doesn't know and doesn't care about it. If your managers have no interest or no understanding of a process, such a process could also be started by getting all the programmers to agree to it (or at least team leaders) and telling new employees, "this is how things are done." Of course, it is necessary that you pick a process that is compatible with your manager's requirements if you do this (e.g. if your managers ask for daily updates on milestones, don't pick a process that has no coding for the first two weeks).

This is really only appropriate if you have a discussion with a manager and their basic reaction is "It doesn't matter, as long as you keep writing code." If you present a process as being a means to redistribute order of work done rather than as one which adds new work, you're more likely to succeed in such an approach.

Answer 4

If your projects are like the standard / typical IT projects, then chances are your projects have failed, or been buggy, or cost too much, or didn't do what the customer (internal or external) needed, or took too long to develop.

If you are going to advocate a process, it needs to be shown that you will not lose flexibility just to have structure.

Points to make to decision makers:

• Having a Scrum-like process will improve how much information that management has at its fingertips, and allow them to make decisions more quickly. Consider the scenario that you have a 6 month project. Well, with no processes, how do you know how much work is done until it is released? With Burndown charts, you can track how much time is left in a visible way. If you couple that with TDD, where you define say 100 test cases, they can see that 50% of the test cases are left to get working, but from the burndown rate there is only enough time to do 25% (remember Managers like it simple, so this isn't a perfect state of the project, but it is an easy to understand one that was better than what they had before). .e.g. they will feel more in control because the projects have better visibility.
• Having process allows you to improve quality, which long term will result in less bugs, less time spent on bugs, more knowledge transfer (what happens if your star developer is hit by a bus), and all this means that the company will get developers focused on a better product than on continuously fixing bugs. e.g. this will save them money

• A small set of changes will be implemented first. This will be a proof of concept, and safe and easy to back out of if needbe. e.g. this shows that you are mitigating perceived risk . And you need to mitigate perceived risk because that is what they'll be focusing on. That said, you will want to gather some data before you even make the proposal. Why? Good question: you need a baseline for 2 reasons:

  1. You'll want to know how much the changes have helped. So you can propose more changes.
  2. You'll likely have a manager complain about a problem while the proof of concept is going on. You'll want evidence that shows that problems in a chaotic process free environment are the norm, and this is not a worsening of the state, and perhaps a slight improvement. You can bet on something going wrong in a process-free environment. And you can bet that the proof of concept process changes will be blamed. So be ready for it.

Answer 5

In my experience it's easier to sell management on a design methodology or practice after it's been piloted once. I would cherry-pick a small project, usually internally facing if possible, and ask to "pilot" your new scrum process. Generally it's a lot easier to get people to buy into a pilot because they only have to commit on a limited basis.

As your new scrumified pilot project moves along, be sure to document (post-its, notepads, Word doc, whatever) how scrum is making your project more or less successful than the previous (lack of) method. Be brutally honest here, and try to quantify things in real terms whenever possible.

After the project completes, compile your notes and present to management your findings using the completed project as evidence. Use findings such as:

• "product backlog provided users with real sense of progress on featureset X"
• "pigs/chickens meetings style saved X man/hours a week by keeping meetings in control"
• "sprints allowed developers to work more closely together and resulted in X% less buggy code"

Generally, if you can bring leaders to a spot where they can draw dollars-and-cents conclusions, they will go for a new product or methodology. Also, and this is important as well, be prepared to walk away from your original process ideas if you find them not bearing out during the pilot.

Good luck and happy productivity!

Answer 6

You can sell Scrum as a "No Lose" proposition. Look at what happens when you use Scrum:

1. All development work is always focused on the highest priority tasks.
2. Progress is 100% open, and inspected daily.
3. Users/customers get to examine the progress at the end of every iteration.
4. Shifting requirements are handled automatically.

The only reasonable objection that I've ever seen to Scrum is that it isn't really possible to predict how much a project will cost, or how long it will take. This is because Scrum acknowledges that everyone will learn as the project commences, and the requirements will change. Waterfall pretends to be able to do this, but we all know how well this works.