Classic waterfall software development approach originates in the manufacturing industry and is sequential by its nature. Phases follow one after another: requirements gathering, design, implementation, test, deploy. But currently this process doesn’t meet the needs of modern business. A medium sized project can last for a year, larger projects can take even more time to be completed. In a year original detailed functional requirements are often completely outdated. You can get a product that you don’t need.
One more thing that often makes this traditional development cycle unacceptable: there is no business value until development is completed, and a lot of risks are actualized at the very end of development, at the deploy phase. Waterfall development often works as a black box. You put your money in it and wait for what happens. Sometimes you get what you want, sometimes you don’t.
Any request for change costs much and puts the system in unstable condition. New business needs can require changes in the system design which can cause a lot of redevelopment.
Why use Scrum?
What can software industry propose in the state of the art to address the problems? The answer is Agile methodology. Please find the Scrum process diagram below:
Scrum development process is a sequence of iterations each of which looks like a small waterfall with all the phases. It should be mentioned that iteration length is less than a month (usually 2 or 3 weeks). And by the end of each iteration you get a viable product. You can see the actual result of the team’s efforts, you get the features you want to be implemented. The product can be deployed on real production servers and can be tested and evaluated.
You get business value from the very beginning of the project implementation. Not all the applications can be shown to the end users until the development is completed (but some enterprise applications can be shown), therefore, you can use an application for clarifying your requirement, for testing on your side, for attracting investors to your business.
You don’t need to have accurate requirements to the whole system. You only need to have a general plan of features you want to be implemented and descriptions for user stories to keep the team busy for the next iteration. Any of your ideas are put into the product backlog, and on each iteration you revise the backlog and prioritize them. Actually you are forming the product gradually. With Scrum you can have flexible requirements without additional efforts for change requests processing.
How to deal with risks?
And what about risks? In Scrum they are sufficiently lower and well controllable because of process transparency. Every two or three weeks you have a viable application with all new functionality in place. There is no risks of deployment or integration failure at the end of project, for you can test it right after it is implemented.
But nothing comes for free. At what price do the benefits come? First of all, close collaboration between developers and product owner is needed. Lack of formal requirements is compensated by communication. You can involve an analyst to describe user stories in more detail, but you can’t just forget about your project for a couple of months.
You should be flexible in your plans as you are flexible in your requirements. When you add something, you should be ready for budget and project time frame increase. But Scrum offers you great transparency for your planning. It is almost automatic: product backlog contains all the user stories prioritized, and development team just implements the top of it which is really critical to Go Live.
So if you want to decrease your risks, maximize the business value of you product and have really transparent and well-controllable development process, then you should try Scrum!
Do you use Scrum in your processes? Do you find it beneficial compared to other methodologies? Share your thoughts in comments!