Once upon a time, there was a company. A large, multi-layered organization ordered with the task of developing and launching new software. And not just any software. Complex software unlike anything the organization or the public at large had seen, or used, before. The new software carried with it a set-in-stone launch deadline. The pressure was immediately on to go live. And not just go live in one small testing site; rather, to roll out the software and go live everywhere at the same time.
So, the company did what it had always done. Being an organization not run by IT people, the company hired many, many outside consultants from many, many well known places; each bringing his or her varied experience and unique work culture and expectations to the task at hand. The consultants put hundreds of developers on the project. Then, the company deployed the project using the common practice they always used, waterfall.
Don’t Go Chasing Waterfalls
Ahhh, waterfall. For those of you familiar with waterfall methodologies, you may just have groaned loudly, as you already see the writing on the wall for this project. For those of you thinking, “Waterfall? What’s the big deal? There’s a truck load of consultants getting paid big bucks to launch this thing. They’ll make sure waterfall gets the job done.”
To accurately set the scene, let’s revisit a few things we know about waterfall.
Waterfall:
- Requires highly structured, highly regulated project organization.
- Includes a detailed set of linear procedures and controls.
- Is best suited for stable software projects where requirements are established and never change.
- Necessitates that developers can predict problem areas and produce an accurate design before implementation.
- Demands that each phase of development be fully complete before proceeding to the next phase.
- Breaks down a project’s schedule so that approximately 40% of total time invested is spent on software conception and initiation and 40% spent on coding, leaving 20% for testing, implementation and maintenance.
Now, let’s revisit a few things we know about this big project.
This big project:
- Was completely and utterly new, unimplemented and anything but predictably stable.
- Was the definition of complex.
You can begin to see where this project was headed. Not surprisingly, the software was released and was, by all accounts, an epic fail.
Why the Epic Fail?
-
Little to No Testing
By the time all the conception, initiation and coding was completed, there was no time left allotted for testing. The software was pushed out live, with only hours of testing under its belt.
-
Too many Cooks in the Kitchen
All those consultants meant one thing. Everyone had an opinion, but no one had ownership of the project. Combine that with leadership that had no IT understanding and you’ve got a recipe for disaster.
-
Project Sprawl
All those large teams of developers translated into a lot of unfocused work and unclear expectations. Some work was duplicated; some was missed entirely.
How Scrum Saved the Day
After the complete disaster, the company had an epiphany. Sure, the project was a total mess, but there still was a need for the software. The process needed fixing. And, to do that, it came down to the people. People over process. That’s the Scrum way.
The truckload of consultants and large teams of developers were sent packing. A very small and very focused Scrum Team came in to get the job done.
The Scrum Team used an incremental, iterative and time-boxed approach to:
- Respond to changes in requirements as they arose.
- Make changes as the project progressed.
- Deliver early and often.
- Deploy the software in smaller circles; watch it, fix it and scale it.
- Have incredible success.
The project was saved. The software was deployed. And everyone lived happily ever after.
Think your company could use a little superhero help from Scrum?
We’ve got training for that.