CHAPTER 2 MANAGING AGILE PROJECTS WITH SCRUM
15
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