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

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.