Waterfall Method (Plan Driven)
The waterfall method can be thought of as a plan-driven method of software development. In the past, this method of development was used by many—not because it was the best way to develop software, but because it was the only method known.
A project that used the waterfall method involved a large amount of risk, mainly because everything was done at the beginning of the project. All the requirements gathering, and discovery and scope definition was completed before the first line of code was ever written. Customers had to know up front everything that they needed or wanted the system to do. At times customers did not know exactly what they wanted, but yet, they had to define every last detail of their needs; and once they defined the details, they could not change them—even if they later realized that their needs had changed.
This approach destined the project for failure before it even began. The entire process led to problems that were hidden until toward the end of a project, simply because the customer had not considered every little detail, and there was no way make changes as the need arose. Sometimes it was too expensive to make a change. Scope creep was rampant in these kinds of projects; developers didn’t understand the problem that the customer was trying to solve—and the customer didn’t either.
Plan-driven development could be like a hoop jumping process: you started at discovery and once you jumped through that hoop, it was on to the requirements-gathering hoop, and from there you went on to the design hoop. You could not jump through one hoop until you had jumped through the previous hoop, and once you were through a hoop it was near impossible to go back to a previous hoop if the need arose. There was no allowance to do a little bit of everything and then pause to make sure you were still on the right path. The waterfall process did not foster an environment where developers could go to a customer and say, “I would like to show you what I am working on to make sure it is what you want.”
Usually the big issues would surface toward the end of a project, which was rather late in the process. This led to many development teams being behind on their projects. When teams got behind on a project, they would just throw more bodies at the project, with the hope that the more people on the project, the faster it would get done. That rarely happened. Most of the time the project would remain behind schedule, so the team had to cut the scope, cut testing, or both.
Scrum Method (Value Driven)
Scrum is considered a value-driven method for software development. Scrum is a dramatic change over the waterfall method for a number of reasons. Instead of first gathering all the requirements needed for every feature of the project, completing all the designs based on these requirements, and then coding the application based upon these up-front designs, Scrum looks at doing iterative, incremental development.
Scrum is all about taking small passes at a problem and reassessing that problem after each pass. Scrum is all about small:
• Small time blocks called sprints
• Small features
• Small teams
Small time blocks are how the team works on a solution for the customer. Each sprint can be looked at as a mini waterfall project. This is because in every sprint you are doing everything you would normally do in a waterfall project, except you are doing it on a smaller scale. In each sprint, you take a feature and you gather requirements on that feature, you design that feature based on those requirements, and you code and test that feature based on those designs. In Scrum, unlike waterfall, you are not trying to do everything up front; you are doing everything you need to do when you need to do it. The goal of each sprint is to deliver an increment of the final product—but an increment that is potentially releasable.
So how can we do numerous waterfall projects in each sprint, when we could barely do one waterfall project before? By doing these sprints against small features. Small features are pieces of a project that try to solve a particular problem for the customer; they don’t attempt to create the whole application. The massive features of the project are broken down into smaller chunks that can still provide value to the customer and are able to be completed more quickly. As more and more of these features are completed, the customer will start seeing the entire application coming into view.
All of this is done with a small team of developers, testers, and designers that are dedicated to getting the project done. This team is cross functional in that every member knows how to do everything. Each member may not be the best at everything, but everyone knows how to do everything necessary to complete the project. Think of them as a SEAL1 team, where every member knows how to do everything needed, but there are also experts on every aspect of the operation.
By doing things on a small scale, problems are less likely to arise near the end of the project. In fact, Scrum works to expose problems as soon as possible. Issues can’t hide because the process is broken down to a manageable scale. When a problem does surface, it causes major discomfort for the team until they address and fix it. They can’t ignore the problem because it is visible to everyone.
There is one important thing to realize about Scrum, however: it works to expose problems to the team as soon as possible, but it is not designed to fix the problems. It exposes the mud, but it is still the team’s job to clean it up.
With Scrum, you are not just creating features for the sales and marketing teams to show the customers, you are creating solutions for the customer. This is done by prioritizing the features that need to be completed based on the customer’s needs and wants. If a customer deems feature A to be more important than feature B, then the developer would be wasting his time working on feature B before feature A. Give the customers what they want when you say you can deliver it.
Source of Information : Pro Agile .NET Development with SCRUM
0 comments: on "Plan-Driven vs. Value-Driven Methods"
Post a Comment