Is Agile only about being faster?
Is the sole purpose of Agile to help programmers work faster? Is it about being ‘agile’ in the literal sense? Or is there more to the Agile methodology, asks software architect Lewis Foti.
In a recent talk on digital leadership the speaker recounted hearing a developer saying “Agile is not fast enough, we have to be liquid”, apparently the speed of delivery achieved using Agile Development was insufficient. This got me thinking, what exactly is the purpose of Agile Development, to develop systems faster or something else?
Agile Development (or more commonly Agile) is a project methodology that originated in the software industry. It has achieved considerable popularity over the last decade and is now often preferred to traditional project management techniques (commonly referred to as “waterfall”). Agile is based on lightweight planning, incremental development, early delivery and flexible response to change.
This is a marked contrast to waterfall projects which start by producing a detailed plan for the systems build and the resources required. The plan sits at the core of the project and is expected to deliver the system on time and budget. Empirical evidence shows this is often not the case. The software industry abounds with projects that have suffered significant overruns and failed to deliver what was required. It seems that waterfall projects and their plans are fragile entities that frequently fail to achieve their purpose of providing a robust and reliable delivery process.
SEE ALSO: Do slower programmers get there faster?
It strikes me is that the plan is created at the beginning of the project, when all participants know the least about what is required. Inevitably as the project progresses all concerned gain a better understanding as to what they are trying to achieve. This can range from the customer needing to change the requirements to the developers discovering the estimate to produce a given component is incorrect (mostly that more effort is required). Both of these are symptoms of an underlying problem, that there is no way of knowing how complex a system is before it is implemented. More formally, there is no calculus of complexity, i.e. no science that can predict how complex a system will be prior to its implementation.
So back to my original question, what is the purpose of Agile if it is not greater speed of delivery? Looking at how Agile differs from waterfall projects some pointers.
Understanding what you are delivering
A key participant in an Agile project is the Product Owner. Their role is to represent the customer/end-user, continually assess progress and decide on priorities for the next delivery. Plans in Agile projects are high level, rather than detailed and subject to continuous revision in light of experience gained and progress achieved. Agile projects deliver at regular intervals, typically every two to six weeks. Consequently the investment in a given delivery is low compared to the overall budget.
A key milestone is the minimum viable product, the simplest implementation that delivers value to the customer. It has just those features that allow the product to be deployed, and no more. The goal is to maximise the learning for the minimum investment.
Taken together these allow all concerned to rapidly gain a better understanding as to what they are delivering. As this understanding increases so shortcomings in the original requirements can be identified and remediated in a timely fashion. This short feedback loop is key to why projects using Agile are more likely to deliver successfully. It exploits the increased understanding that arises as the project progress and provides a mechanism by which this can be used to improve the project plan.
To answer my original question, Agile is about recognising the realities of project delivery, namely that we know least about what is required at project inception. Agile provides a mechanism and environment where plans and priorities are adapted to take advantage of knowledge gained. The increased visibility of progress and the frequent validation of what is being developed reduces the risks associated with project delivery. Agile projects may deliver faster, but it is by ensuring that effort is invested appropriately and driving up quality of delivery, not encouraging developers to type faster or work longer hours.
This article first appeared on bigarchitecture.technology.