The old way of doing software development just did not work. Projects failed left and right and customers began to believe that developers could not produce the solutions that the developers said they could produce. Something needed to change.
Scrum was one of many answers to the problem. Under the umbrella of agile, scrum focuses on small teams and small time blocks for implementation. In the first part of this series of blog posts, I want to show the differences between the old way of doing things, and the new way, scrum.
Plan Driven vs. Value Driven
Waterfall method (Plan Driven)
The waterfall method (also know as the Plan Driven Method) was the only way to do software development for the longest times but it was not the best way. Using this method meant dealing with high risk and the likelihood of failure. The reason why it was this was way was because of the fact that everything was done up front. Everything that the customer wanted or needed was supposed to be laid out at the beginning and the customer never changed their mind. This led to problems becoming hidden until towards the end of a project because not everything the customer wanted or needed was laid out. Scope creep is rampant because what the customer wanted was always changing. We as developers did not know what the customer wanted and neither did the customers.
What plan driven does is create a list of features that the development team needs to provide to the customer in the given timeframe.
When companies were behind on a project, like they usually were, they would just throw bodies at the projects. Their thinking behind this was that the more people that are on the project the faster it will get done. That rarely happened. Most of the time the project would remain behind schedule and companies trying to get the project completed on time tended to cut scope, cut out testing, or both.
Scrum Method (Value Driven)
Scrum (also known as the Value Driven Method) is a dramatic change over the waterfall method. Instead of trying to gather all requirements, do all the designs, and then code the application, scrum looks at doing iterative, incremental development. Small time blocks where the team can work on a solution for the customer. You can look at each iteration as a mini waterfall in that the team will everything you would do in a waterfall method, except do it at a smaller scale. This is done against small features that solve a problem for the customer, not the whole application. The goal of these iterations is to deliver an increment of the final product that is potentially releasable.
This approach makes problems visible sooner. However, contrary to popular belief, scrum does not fix the problem. It shows you the mud but won’t clean it up.
In scrum, you are not just creating features for sales and marketing teams to show customers, you are creating solutions for the customer. The way this is done is by prioritizing the items that need to be completed based on customer value. Only the things that the customer deems most important are worked on in any given iteration. If the customer does not want something then it is not worth the developer’s time to work on it. Finally, scrum is all about small; small teams, small features, and small iterations.
Fixed vs. Variable
In plan driven, your scope is usually fixed with your resources and time being variable. In this method, your scope dictates your resources and time. Since you cannot change your scope your only how is true try to throw bodies and technology at the project and hope for the best. Usually to varying degrees of success.
In value driven, your resources and time are fixed. You know the size of your teams and you know how roughly how many customer items they can complete in an iteration based on previous iterations. Scope becomes the variable in this equation. Here your resources and time dictate you scope. Since you are able to potentially release workable and valuable software to a customer at the end of each iterations, scope creep becomes near impossible. This is because as new features are presented to the team, they are prioritized. After this prioritization, the “must haves” are at the top with the “would like to haves” at the bottom. Over committing the team goes away.
This was a brief introduction on the differences between the waterfall method and scrum. In the next article in this series, I will talk about a component of the scrum process, the scrum teams.