The following is excerpt from my eBook Agile Basics in 60 Minutes.
Why Are Changes Needed?
Software development has had some historically monumental failures. In 2011, a financial
services giant had a software glitch that cost investors $217 million, which resulted in a $25
million fine from the U.S. Securities and Exchange Commission. The typical waterfall process
has produced lots of these scary disasters that make headlines like this. The traditional process
of gathering requirements, designing, coding the solution, integrating the pieces, and testing at
the end has many drawbacks, including:
● Its simple, linear and structured approach;
● A great amount of time spent in the requirements and design phases to reduce cost
for coding and testing;
● Being more disciplined in its procedure, which translates into less flexibility in the
entire development process.
Additionally, the requirements are not totally understood. Before I worked on Agile projects, I
would cringe when I heard, “I think we want to change this.” Or, “We already talked about that.”
Many times the users don’t know what they want until they see the first output (page layout or
even simple calculation functionality) of your software. Even with mock-ups or wire-frames, we have a hard time zeroing in on what the customer may want.
In 2001 a group of software development leaders got together and created a declaration of their
views on software development that specifically outlined the changes they wanted to lead. This
is called the Agile Manifesto. It states the values they want to advance:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
The key is to make the process lightweight and adaptive to change. They want to remove strict
processes that we sometimes use to construct software, and collaborate with customers to
produce working software. It’s about welcoming change and embracing it as part of the iterative
process to get what we (software development team AND customers) want.
In working on a healthcare job site, we would try to get the priorities for the upcoming year. We
would complete a project, ask for feedback and would end up missing the mark many times.
When we switched to Agile, we had many more opportunities for feedback built in and we were
able to better achieve customers’ objectives. The iterative nature of Agile development facilitates
feedback at numerous points through the development process.
Agile asks us to have frequent check-ins with stakeholders. The daily Scrum meeting is where
the team checks in with each other on progress in the current Sprint; the Retro is a look back to
identify what did we do right and what can we improve on. In traditional waterfall projects, we
might work six months or a year before doing something like this. An Agile discipline demands
collaboration and communication that will result in efficiency and quality.
For more check out Agile Basics in 60 Minutes.