Google Tech Talks December 7, 2006 ABSTRACT Adwords introduced a Scrum implementation at Google in small steps with remarkable success. As presented at the Agile 2006 conference this exemplifies a great way to start up Scrum teams. The inventor and Co-Creator of Scrum will use this approach in building the Google Scrum implementation to describe some of the subtle aspects of Scrum along with suggested next steps that can help in distributing and scaling Scrum in a “Googly way”.
Most of us working in Agile now, have moved from waterfall to Agile at some moment of time in their career. You must have experienced lot of questions in your mind while doing so. Many of us moved for various reasons – their own interest, due to project requirement, due to management decision, customer demands etc.
Why Agile? and Why not waterfall?
This was my first question while I was stepping towards Agile methodology. I would not say that I don’t like waterfall, but it would be worth while to look in what difference you would see while moving to Agile.
Waterfall has it’s strength in believing what logical path a project can take. Looking at the requirements, all great ideas can be implemented well in design phase, code and test and deliver. All those deliverables are given to customer that were planned. But any ideas that are introduced say later in the testing phase, might make you think 10 times whether to incorporate and how to incorporate without affecting schedule and cost of the project. You might remember the cost of defect equation which stresses upon defects found in later stage of the project cost much more than in design phase. Now you can compare good ideas coming at the later stage that require lot of change in system design with defects. Sometimes even good ideas coming up in later stages of the project could prove to be threat instead of doing any good for the project. Unfortunately it happens more often than expected as not all good ideas are brought up at start of the project itself.
At the same time, biggest strength in Scrum framework lies in adapting change and it becomes easier with it’s interative approach. Agile suggests to work in rapid iterations, deliver working product and get as much as inputs from customers on the way as possible (or product owner if he can play the role of a customer). This feedback loop is very important to make sure that the product delivery is as expected by customer.
Business value from Scrum
I remember a very good difference between these two, waterfall and scrum – business value at some moment of time in project life cycle.
If I remember correctly, it was explained by my scrum trainer. In this example, we run two projects for identical requirements, same time period (For example: say 1 year) with same team, but one in waterfall way and another in scrum.
Assuming you know how scrum and waterfall both work, if you look at the project delivery after 6 months, it would be very interesting output. In the 6 months, the waterfall project might have reached a stage where the requirement analysis is fully complete, design is complete, programming has started and half way through. If I am a customer, how much business value this stage would give me, think about it.
At the same time, the scrum project team would have against prioritized product backlog and started delivering shippable product after every sprint (say of 1 month each). If as a customer, I ask them to stop working after 6 months, they would have at least bunch of product backlog items done, and shipped as workable product. Simply because it focuses on shippable product in small iterations, and that not only gives the best business value at certain moment in project life cycle but also allows change during the development process that can be taken up in future sprints.
This is huge difference between what Scrum can do, and what Waterfall might not help in.
Credit: Abhijeet’s Blog (Certified ScrumMaster)