When can you use Scrum? When not to do Scrum? Can you use Scrum in a manufacturing environment? Can you use Scrum for implementation or roll out projects? How about ERP? All questions that are high on the agenda of any Agile workshop, being it for management, projectmanagers, architects or SAP consultants.
Fact is that a project is ultimately a container for something we do that we expect to bring us value, and it induces some risk! Where we are willing to invest a certain amount of money and time to deliver the value and control the risk. Scrum is based on the idea that in order to deliver maximum value in a risky uncertain environment, we need to have fast feedback and amplified learning. That fits the need of mentioned project pretty well….
Scrum is a pretty simple framework. If you really look to what it boils down to, it is nothing more than a formalized way for a team to have amplified learning, and a maximum effect on the valuecreation from that learning.
The answer to all above questions typically lead to asking back one root question: “why are you even considering Scrum?”. What problem are you trying to solve?
If the desire or investigation tomuse Scrum is to solve the problem of budget overrun or timeline overrun, it could prove worthwhile. Scrum is designed to deal with maximum unpredictability; it is based on an empirical mental model. Results of the first timebox (sprint) lead to more understanding and knowledge of the job at hand for the second timebox, and so on. Scrum is perfectly designed for the unknown, unpredictable wordl.
One example outside IT that I have proven this with myself is in the reconstruction of my house. There is always a large amount of unpredictable work and a lot of uncertainty in a reconstruction. You will encounter unexpected things. By using Scrum, i was able to deal with this uncertainty in a very controlled way, which led to a reconstruction within time and money constraint (i finished early by 4 days, and with 60 euros (!)) and because of the continuous feedback was able to get approximately 30% more ‘features’. I have documented the while thing, so that is for another blog 🙂
The first argument is often: we know exactly what to do, and it is very risky to not define the scope fully upfront, because if we have one thing wrong this will lead to high costs. However, the question should really be: “what does NOT have to be defined upfront? Any choice you can postpone leads to a risk-reduction, which is value in itself. Aything you do know upfront that is already actionable, you should start doing to increase value and early feedback. This is not Scrum, this is making sense. In anythng that is unpredictable, we tend to think about ensuring we have mitigated all risks. We forget that there is at least a couple of things that are pretty safe to pursue. In parallel, one could startup the further depthening of the scope.
This line of thinking is often challenged by ‘but in our situation, it is impossible to slice things into smaller pieces’. Really? People actually cannot do a job without slicing it up into smaller pieces. There is nobody who will work for longer than a gew hours and look if ‘it is working’. The question is really if you are able to guide this slicing process in such a direction, that every slice either reduces risk or adds value, for your cause.
The second most heard argument is: our scope is fixed, so we can not use Scrum. Even if this is true, scope is fixed, risk is not. Uncertainty is there, or there would not be a project. For very repeatable things, a project can be defined, of course, yet I don’t see why. A well drafted plan and a well commanded crew can do the job. Like the prefab home industry. Projects are defined, mostly to construct a temporary organization that can execute the predefined plan. If the plan is executed 10 times, it is likely to get 10 times the same result. This can hardly be called a project.
If risk is at hand, a shortcycled monitoring system makes sense, to ensure and assess that value delivery is still sensibLe. In such an environment, using a shortcycled feedback driven system based on timeboxes makes perfect sense.
The third argument i hear a lot is that the work is too complex to fit into sprints, and that shortcycled delivery is not possible because of complexity of the chain. My question in such cases is always: how will people do their work? If you have to build, test, construct, configure something in a very complex environment, you need to think in advance, agreed. The only point is, you can never assess the impact of your changes to that system to its full extent. Just in time thinking ahead and implement to prove you were right is actually the most sensible way to do it.
Finally, when testing the full thing is too much work to perform on a shortcycled rythm, that is an imepdiment for shortcycled delivery of value. That is actually a problem. You are more or less forced to take that type of testing out of the shortcycled delivery, and do it on a slower rythm schema. That is not to say it is the wisest thing to do, it is regretfully the only thing you CAN do. The strategies for getting out of such a scenario are numerous, and are worth a blog of their own.
I hope to have given you some thought on the question ‘when (not) to use Scrum’. Not by giving you answers to that question, but by providing you with the line of thought behind Scrum, very much based on Lean thinking.