Business value of Scrum

Usually when you read articles about Scrum you find out how it helps team to focus, to develop code faster, and with less bugs. You ship production quality product every few weeks, actually, after each sprint. Well, what you need is only product owner, product backlog, scrum master, scrum team, and other Scrum artifacts. When you find out and understand all benefits of Scrum you are starting with it immediately. But usually then you face with the first problem. Customer agrees to go with Scrum but is unable to take care of product backlog, cannot provide real product owner and actually has no Scrum orientation. And I have feeling that this situation repeats again and again.
From my point of view, reason for this is that customers very often do not want to educate them self about Scrum, follow strict corporate rules and number of articles describe benefits of Scrum only for software development teams, not for customers too.

If we take a look at mainly standard procedure within corporates, implementing project looks like this:

• they setup board for project
• board specifies requirements and creates budget
• they find responsible person that make details from requirements
• requirements are estimated and if they do not fit within budget, often project is not started
• if requirements fit into budget, project is started and board expects software product in some time frame
• after given time they receive product specified at the beginning. This product satisfies all requirements from specification, but the most often product is not what they expected, lot of functionality will never be used and after all, when they see product they can see that some requirements could be implemented much different (but they were implemented by specification)

Let us see how Scrum can help customers to avoid such situations. How would the same project run with the Scrum:

• board for project is setup
• board specifies project vision and setups initial budget
• responsible person, let call her product owner, specifies the most important features of project and development can start
• after very short time, 2-4 weeks, product owner is able to see first draft of application. She can review approach, notice some more important feature than planned sprint ago, change course of project if necessary.
  
• after a few months, the first simple version can be already deployed
• after this time, if board still things that project has future, additional budget can be assigned to the project. If they think that project has no future project can be canceled and not too much money is wasted
• project can go this way as long as really useful features exists. What is the most important, project can be canceled at any moment but valuable product will still exist. Project is finished when board or product owner decides so.

Let us try compare these approaches. Let call first approach traditional approach (waterfall :)) and the second one Scrum approach.

Budget and specification
With traditional approach you have to estimate budget of the whole project. To be able to estimate budget you need to specify most of the requirements with enough details. This means, even before project is started you must know how final product will look like because without that budget estimation is not possible. Well this is tedious, error prone work that usually does not give expected results. As you have to estimate all the future features, probability of big discrepancies is big.

With Scrum approach you can assign some initial budget to the project. This can be budget that is enough for few sprints, so it means no more than a few months. Project vision is enough, because what you really need to estimate is only the most important features of application. Don't tell me that all features of future application have the same importance :). As you have less feature to estimate, probability of big discrepancies is smaller.

I think that conclusion which approach is better is clear. At least, I would select Scrum approach.

Project development
So you have started your project with the traditional approach. In front of you is few months (or a years) of development, your team is struggling with requirements, ambiguous definitions, unclear descriptions, lack of support. No changes in specification are possible because it can influence budget, you have to stragle with hard change request process, you don't have time for it. Actually who cares if you new request is actually excellent idea, you should remember it during proposal phase. If you are lucky your project will be delivered on time and within budget. If you are lucky final product will be somehow similar to one you expected. Generally speaking, those projects are more or less always failures.

So you have started your project with the Scrum approach. In front of view is one sprint that will last from 2-4 weeks. After sprint you can review shippable product developed with production quality. You process with further sprint. After a few sprints your most important features are implemented and if you want you can even start using it. Your budget is almost spent so you need another meeting with a board. You present project to the board and they almost immediately after project kick off can see what a product will look like. If they like it they approve budget for next few sprints. But then you got excellent idea. It is real breakthrough within product. Well, this is Scrum :), no problem. Include it into next sprint and you will have it soon implemented. Thats all about complicated change request. All the time you are implementing the most important features of product. After some time your product is finished and you have product exactly by your expectation because you was able to review it and correct directions after each 2-4 weeks.

Well, which approach would you select?

Conclusion
I tried to have a look at the Scrum from business point of view. It is clear that Scrum is valuable for developers. But what is the most important in these days is business.

Business wants to minimize risk and maximize profit with minimum investment. That was the reason why waterfall model was introduced within first place. But as it turns out, Scrum can minimize risk and investment but at the same time maximize profit.