Had To Plan The Entire Project Before Understanding The Project? This Might Surprise You!
Without scrum, our teams had built and
delivered entirely wrong software and
hardware products that did not fulfill
demands from our client.
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 meri ts 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 define, 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.
Finally, it wasn't only the product which
suffered, but also employee morale and
commitment to our organizational mission
have wholly disrupted.
Share It With Your Colleagues and Friends to Help Them Learn:
Had To Plan The Entire Project Before Understanding The Project? This Might Surprise You!
|
|
|
|
|
|
|
SCRUM INSTITUTE™
