Final Tech Report HD - Flipbook - Page 8
The SDLC process, by its nature, facilitates hand-offs of
information and builds controls to ensure common
understanding at the time of hand-off. Therefore a reliance has
evolved on the process for controls. An industry has now been
spawned around this process, roles like Business Analyst and
Project Manager have evolved to help people navigate through
the process. For large changes, requirement spreadsheets can
run to thousands of rows. The problem is that despite the
controls, single points of hand-off leads to single points of
failure. More fundamentally, requirements change. Don’t get
me started on the change control process.
Another weakness is creating and managing all the test
environments to try and recreate what will happen in
production. The larger the technical stack, and the larger the
change project, the more complex this is.
An alternative method for implementing software changes
relies on the tenets of the Agile manifesto:
individuals and interactions over processes and tools;
working software over comprehensive documentation;
customer collaboration over contract negotiation;
responding to change over following a plan
To be clear, I am not talking about the versions of this
approach that depend on process and creation of roles, e.g.
Scrum certification and roles like Scrum Master, Release Train
Engineer. I am referring to self-empowered, multi-functional
teams who are clear on what they are delivering and why, are
in constant communication with each other and have regular
feedback from customers and end users on what they are
developing.
In an agile development team with effective ways of working,
features are regularly developed and tested for feedback to
make sure that the right things are being built and that they
are being built in the right way. Without this feedback loop,
teams cannot adapt with customer expectations.
7