Agile vs… Waterfall –
the wrong debate
I have always been not-so-sold on Agile. The reason is that
I remember my textbook in Software Engineering Project Management (http://www.amazon.com/Software-Engineering-Project-Management-Edition/dp/0818680008/)
that what people call agile is actually the Evolutionary Development Model.
(p.108). So, essentially – nothing new - we are using small versions of the waterfall
model. We just decreased the time frames.
The problem though is that Agile has become like religion in
the middle centuries. Even to express some doubts about it equates to calling
the Earth not flat in the 1600s. It’s like heresy. One day I ventured to a
colleague who sits far from me and we spoke about software development
methodologies. I expressed some of the thoughts I am expressing here. He said “what
then, doing waterfall?”. I said that the whole “debate” has become Agile vs
Waterfall which is so wrong.
Googling "Agile software" I have found that one of
the first websites states: "The Agile movement proposes alternatives to
traditional project management.”. Traditional? I guess, yes, again it’s Agile
vs Waterfall – a model that is not responsible for the software crisis. It’s
all about a disciplined approach. Things were programmed and done excellently
before all the Agile talk. Simply by following a plan and applying discipline (and
desire).
I maintain that Agile is just a buzzword to sell consulting.
Essentially 17 developers gathered at a winter resort in 2001 and started
calling an existing methodology "agile".
We all know what happened next - almost the whole industry
takes it on, spends millions on consulting with some success stories and some
not so. It's not the silver bullet to the software crisis and it is unlikely to
become. It’s ok for shorter and not so complex projects but try to create the
GSM (cellphone) system (created in Europe in the 1980s) on that! So first we'll
say - we need a controller - voila - version 1. Then oh, no, version 2 - let's
add SIM (subscriber identity module). Developers go rework, refactor, redesign
and add SIM. Then they add security, then interoperability. It’s clear that all
these aspects should have been though about upfront.
Agile Waste
Since all those builds and testing are done at each
iteration there is so much in-built waste. Yes, there is an inherent waste
built-in. Doing a build every 2 weeks (takes 1+ day of activities at the place
I currently work at) means that a team member has to do the same over and over
again. So much work, so little gain, but well we can say “we delivered”.
Yes, I work in a company where we practice Scrum and we play
this game – the “answer what you did yesterday, what you're going to do today”.
We often don't even work on the same things and still talk and answer those
inane questions. It's like kindergarten for adults. The success of scrum seems
to me is due to the fact that everything is very visible and controllable by
management. It’s not about quality, engineering or creativity or innovation. It’s
about control.
Creativity Killer
Agile can produce good results but often they also kill
creativity. (Nobody, being constantly under the projector, is going to be
creative. Creativity comes from mode B of our brain - when we relax or think about
other things for a change or when we’re allowed to “play” with things.).
Consulting,
consulting…
I got into a 1-day Scrum training. The guy was not from the
software field, yet he stated: for hardware (bridges) we can use waterfall, but
for everything else agile is the way. If only those people stop and read some
textbooks!
