3 minute read
The Project Was All About
frustration #1. We Had to Plan Our Entire Project Before We Understood What The Project Was All About
Without scrum, our teams had built and delivered entirely wrong software and hardware products that did not fulfill demands from our client.
Advertisement
We had times in our professional lives when some third party companies had imposed how we supposed to build our software products or software services.
Capability Maturity Model (CMM), ISO 9001:2008 and other derivates attempted to help our companies to ensure we build our correct software in correct ways.
How successful they used to be is not part of this book. This book was meant to focus on the scrum process and merits of the scrum framework rather than criticizing almost extinct procedures.
However, I have to add that these process improvement frameworks before the scrum software engineering framework recommended a phased approach. They advised a phased software engineering approach which we called the Waterfall Software Engineering Model.
With the Waterfall Model, each software project was supposed to start with requirement analysis, where we aimed to understand what our client needed and wanted.
Then we designed these requirements, we implemented them, we tested (verified) them, and we maintained them in our software production environments. Finally, we reached to end of the software engineering lifecycle.
Nonetheless, the reality didn't play out like that!
The Waterfall Methodology vs The Scrum Framework
Phases in the Classical Waterfall Software Development Model
The adverse effects of unforeseen delays happened during a particular phase of the Waterfall Software Engineering Model were inevitable to the following software engineering phases.
Studies have shown that in over 80% of the investigated and failed software projects, the usage of the Waterfall Methodology was one of the critical factors of failure. But why?
As shown on the left side, when deploying the Waterfall Methodology, there is a strict sequential chain of the different project phases. A previous phase has to be completed before starting the next phase. Going back is, in most cases, painful, costly, frustrating to the team, and time-consuming.
The project timeline is planned at the start. A releasable product is delivered only at the end of the project timeline. If one phase is delayed, all other phases are delayed too.
To avoid this, project managers of the Waterfall Methodology usually try to anticipate all possibilities beforehand. That means that in one of the earliest phases of the project, they try to define all requirements as fine-grained and complete as possible. However, requirement definition in an initial stage of a project is often complicated, and therefore many requirements
change (or should change) throughout the project.
Studies have shown that in more extensive and complex projects, about 60% of the initial requirements do change throughout the course of projects. Other requirements are implemented as defined, but some of them are not really needed by the customer. So those implementations consume time and money that could have been better used to implement functionality with a higher added value for its clients.
The separation into different project phases forces project managers to estimate each phase separately. The problem is that most of these phases usually are not separate. They are working together and in parallel.
For instance, no reasonable human-being can assume that the development phase finished before the testing phase started. And yet, this is precisely and unfortunately how the Waterfall Methodology used to work. The Waterfall Methodology for developing software can be used for implementing small and straightforward projects. But for bigger and
more complex projects, this approach is
highly risky, if not insane. It's often costlier and always less efficient than Scrum software development and delivery framework.
This was the life before the Scrum framework. Sending our software back and forth between various teams, without the guidance of professionals with the Scrum skills, made our work bureaucratic, complex and unproductive.
