Prior to the popular Agile era which
started roughly in the late 90's, The waterfall model was widely recognized as
the most popular, and involved a sequential software design process, in which
progress is seen as flowing steadily downwards (like a waterfall) through the
phases of Conception, Initiation, Analysis, Design, Construction, Testing,
Production/Implementation and Maintenance.
The down-sides included time-lines and
budgets. A typical software build could
take 6 to 9 months, during which time the stakeholder had little or no
interaction with the product and what seemed to be business critical at the
start of the build would often be deemed unnecessary or secondary months later.
The client also realized no benefit from the project until the very end when
the entire system was presented in one wave- not always the all-singing,
all-dancing system it might have been sold as.
The four
core values of agile software
development as stated by the Agile Manifesto emphasize: Individuals and
interactions over processes and tools. Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
The Agile Manifesto, above, evolved processes somewhat and gives the
stakeholder a greater level of control at a much earlier phase of the build
time-line. As functionality is released, it can delivered incrementally,
enabling some benefits to be realized early as the product continues to
develop. This Speed-to-market can be beneficial for cost control and monitoring
quality before it's too late to do anything about it. Should requirements
alter, subsequent functionality and system design can be changed before being
developed, saving large amounts of wasted development costs. The end result is
optimum business Engagement and Customer Satisfaction.
Agile is not without its own challenges
though... with daily stand up meetings not always being possible and regular
involvement from stakeholders can be limited due to time and distance. Business
Analysis, Requirements Planning and Estimates might not always be totally
accurate and can change along the way, proving to slow down development and be
seen by developers as a distraction.
Ask any developer using Agile, they would
still rather not have estimates and planning around every corner and the
#noestimates movement is gaining momentum, adding the need for even better
tools to unsure that quality is not compromised by frequent delivery dates.The
#NoEstimates hash tag on twitter has caused a whirlwind of discussion about the
role of estimates in software development, with several books already writtenon
the subject.
The basic idea, is that it is possible to
do small chunks of work incrementally, leading as rapidly as possible to a
desired usable product, and that when you do that there is no need to do much
of anything in the way of estimating stories or the project. Estimates present
another challenge all together. When requirements are vague — and it seems that
they always are — then the best conceivable estimates could also be guestimates
rather than estimates. Accurate estimation of complex functionality often
requires a fair amount of work and quite frequently some initial coding to
validate. It is still almost impossible to know how long something will take, without
research and validation.
Estimation is challenging and we would be
well off if we could avoid it, that’s why the #NoEstimates idea is so
compelling, however there are many real business questions that will always
need to be answered before they become obsolete. “When will it be ready?” “How
much will it cost?”
“Accurate estimation is impossible for
complex technical projects, but keeping to agreed budgets and deadlines is
achievable by using feedback and change.” Seb Rose from
Clay Snow
George Toursoulopoulos, CEO at Synetec Ltd,
who delivers bespoke software to small and medium size hedge funds is aware of
his development team shouting No Estimates, yet insists that his clients
require commitment in terms of deliverables and costs and estimates are
currently still essential.
