Essay On Agile
How I learned to stop
This document is a brief essay on Agile worrying and
“Agile methods are adaptive rather than predictive.”
The ability to adapt is the core philosophy behind Agile. Change is a constant in any project
and the Agile approach embraces this concept so in planning a project, plans also tend to be
Adaptive rather than Predictive.
On an Agile project a detailed schedule is not created beyond a relatively short time horizon.
The reason for this is generally long term schedules are subject to a larger margin of error (+/-
25% to be precise), this is commonly referred to as the cone of uncertainty. To provide an
analogy, it is like trying to predict what you plan to do in a year’s time as opposed to what
you plan to do in a week’s time, it is naturally easier to predict what you plan to do in a
In software development, project schedules are affected by many variables, even if all the
variables were to be listed, it is extremely difficult to anticipate the degree to which these
variables can affect a project. An Agile approach caters for these changes by providing a
process that helps adapting to these changes.
Example: A team plans to implement a solution using a new technology, with a predictive
approach it is hard to estimate when development will complete when a team is exposed to a
new technology. An Agile approach makes no upfront attempt to predict when development
will complete, but instead as a team familiarises itself with the new technology over the
lifetime of a project an Agile approach can “adapt” to the teams growing confidence or
alternatively the approach can adapt to issues raised from having used the new technology,
this feedback (adaptation) then paints a better picture of when development will complete.
Historically projects have run as sequential waterfall style projects. In a typical waterfall
project analysis and requirements definition take place first then followed by design,
development, test and release. Waterfall style projects are based on a predictive approach.
This sequential approach faces two common problems;
1. “Down Stream” risk management, this happens as quality assurance (internal and
external) typically takes place in the last 10% of a projects lifetime. A more common
sense approach is to move the risk as far upstream as possible in the software
development life-cycle, step in Iterative and Agile development.
2. The deliverable takes so long to arrive it might be out of date (not practical in a fast-
moving market) by time it reaches the market.
Figure 1: Waterfall Timeline
Iterative development is an evolution of the sequential approach, it is still based on a
predictive approach. Iterative development is about “time boxed” development cycles (Note:
this does not imply a fixed length for each time box). This time boxed approach helps
manage complexity to a certain degree by breaking the project up into more manageable
iterations based on two common forms of Iterative development, Risk and Client driven
(Note: a project may use both forms).
In risk driven development the riskiest, most difficult elements are incorporated into early
iterations to push the risk as far upstream as possible. Client driven development implies that
the choice of features for the next iteration comes from the client. So with this approach the
customer implicitly manages the risk.
Figure 2: Iterative Timeline
Sometimes the defined differences between an Iterative and Agile approach can be quite
vague. Agile is an evolution of the iterative approach, they are not the same thing, Agile
development incorporates the concepts of iterative development but not vice versa.
There is a significant paradigm shift from Sequential and Iterative development to Agile.
Sequential and Iterative development takes a vertical approach where as Agile takes a
horizontal approach where in a single iteration an Agile project can cover all the phases in the
Software Development Life-cycle, so at the end of an iteration the approach encourages the
delivery of a tangible working product.
Figure 3: Horizontal vs. Vertical development
The core philosophy behind Agile is simplicity, lightness, communication, self directed teams
and programming over documentation and importantly in Agile progress is measured in terms
of deliverables as opposed to a project plan.
Note: Agile does not suggest we abandon documentation, on the contrary, it encourages
developers to write self documenting code, in other words, code that’s easier to read.
Agile is more of a mindset than a best practices dictum as it favours people over process, the
ownership is on the team to chose and implement the practice that best suits them, the team
and the organisation.
In an Agile project, iterations are the equivalent of a mini project. As mentioned earlier an
entire holistic software development life-cycle takes place in a single iteration from discovery
right through to test and ultimately deployment. The key is to develop a demonstrable
working product at the end of an iteration. This is how risk is managed further by pushing it
even further upstream. Agile is not however just about managing risk, it is also about
managing complexity. A large project broken into essentially smaller projects can help teams
focus on only the problems relevant to the current iteration.
Figure 4: Agile Timeline
We have mentioned that an Agile approach allows adaptation, it relies on a system of constant
feedback. Feedback is mandatory in Agile and relies on strong communication. The following
list is an example of how proper communication works and is fostered in Agile;
• Co-located teams
• Open plan
• White boarding
• Test driven development
• Pair programming
• Continuous integration
• Project tracking
• Iteration/Project retrospectives
• Functional and demonstrable code
“A project that begins using an adaptive process won’t have
the same process a year later. Over time, the team will find
what works for them and alter the process to fit.”
Example: A new technology is posing a problem in development and a developer has picked
this up as he/she was alerted to the problem through his or her test driven development
efforts. The developer brings this to everyone’s attention at the next daily stand-up to
socialise the problem. The team decides to have a white boarding session to tackle the
problem. The team finds a solution but concludes that the fix will take long too long for the
current iteration, so the fix is placed in the backlog as a to-do for a consecutive iteration. The
time spent on the issue by the discovering developer affects the developers other deliverables,
the developers team lead and development manager are alerted to this through the project
tracking tool, so the three sit down to work out which of the developers remaining tasks need
to be placed in the backlog. At the end of the iteration the team demonstrates the application
to the customer, the customer develops a better understanding of their own requirements and
changes are placed in the backlog for the next planning and design workshop, the team then
follows this with a retrospective, the technical issue discovered earlier is the talking point, the
team discusses action points for mitigating further potential issues the newly adopted
technology might present.
The example above demonstrates how the Agile process adapts to a change in the
environment due to a technical problem.
“In building business software requirements change are the
norm, the question is what are we do we do about it?”
We have talked a bit about the core principles in Agile, so what are some of the common
• UP (Unified Process)
In addition to adaptation the Agile approach also embraces change. It is a well known fact in
software development that solutions and the understanding of a particular problem domain
matures over a projects lifetime. This maturity in understanding naturally results in changes.
The Agile approach embraces change by assuming that change is a constant and by providing
a clearly defined process for incorporating it.
In some circles Agile is perceived as an undisciplined approach, this could not be further
from the truth. Agile is in fact very disciplined and does contain process but the key
difference is that Agile places People over Process.
“People first, Process second.”
In summary to understand Agile we need to remember the following key points;
• Agile is an adaptive practice as opposed to a predictive one
• Agile is nothing new but a formal evolution of existing best practices
• Agile places People over Process
• Agile relies on a system of feedback based on fundamental communication elements
Agile helps manage complexity and embraces it
As a final note it is important to remember that executing an Agile process is not easy. In
particular it requires a very effective team and the team needs to be effective both in the
quality of the individuals and in the way the team blends together.