What the Heck is Agile?

This post is another in our series designed to help our clients prepare for early-stage analysis and project implementation. It's aimed at non-technical readers, or anyone that's unfamiliar with approaches to software development.

The topic of this post is 'Agile'. The trouble with writing about Agile, is that Agile means different things to different people. More controversially, the ideas surrounding Agile have been around long enough now for there to be mixed views about whether 'Agile' as a whole has had a positive impact on software development, or not.

Let's start with the 'optimistic' view of Agile.

Agile is an iterative approach to software development based on a set of guiding values and principles. You can read the original Agile manifesto here  along with a great ‘look back and reflect' article from Atlassian Agile Coach  here.

The Atlassian article above considers Agile's relevance today, and how the term (and in fact all methodologies) can be used and abused. I particularly like their reference to the tenets of the scientific method  - to observe, ask a question, form a hypothesis, make a prediction, test the prediction, and iterate.

The Agile manifesto arose out of frustration with what is sometimes referred to as the ‘waterfall’ methodology - a method of progression from one step to another, without explicitly allowing a project to reverse or change course. Waterfall is also often described as a methodology with a formal and lengthy period of up-front analysis. The risk with this style of project is that with so much effort and resources committed during the planning and analysis stages, changing direction, or even just admitting that mistakes have been made, becomes extremely difficult. But (and there’s always a but), not all waterfall-based projects are bad. In certain cases - such as safety-critical, or security-critical applications (in particular with very clear goals), a significant period of formal up-front analysis is almost certainly required.

As the manifesto and Atlassian suggest - it comes down to culture and values. If a customer-focused culture and supporting values create an environment where risks are recognized and a project is able to adapt (irrespective of upfront costs or other pressures) - then projects can be run more flexibly - preferably without being dogmatic about a particular process or methodology.

Coming back to Agile - it’s great that the manifesto has codified the need to be focused on customers, individuals, collaboration, and responding to change. Breaking deliverables and cycles of work into shorter iterative periods gives a project a chance to respond to the needs of customers and change accordingly, whether that’s a change in direction, or even stopping altogether before sunk costs become so great that change is virtually impossible.

That said, the less optimistic interpretation of Agile, is that very often an 'iterative approach' (decorated in a methodology like Scrum ) is applied in lieu of important upfront analysis. It's one thing to be concerned about overly-long upfront analysis in waterfall-style projects, it's another thing to be so caught up in the 'ceremony' of a rapid and iterative approach that initial analysis is abandoned altogether.

Here’s why all of this matters.

On every project I’ve personally been involved with, and throughout the software industry as a whole - two things always occur: 1) realization, and 2) oversight.

Our realizations are often a result of eureka moments - something we did in the early part of the project that changed our understanding of what’s possible. We might have new ideas or even a new goal as result. It would be a shame if we weren’t able to respond to this because our ‘framework’ told us that change was impossible.

Our oversights are also the result of the work we’ve completed and usually lead to a deeper understanding of the problems we’re trying to solve. We simply can’t anticipate or foresee all possible outcomes of our activities, no matter how small or innocuous they may appear initially. Short and iterative cycles of work give us a chance to assess the impact of our oversights and take corrective action when necessary.

And so my definition of Agile is this: It’s a customer-focused iterative process (with an appropriate amount of upfront analysis) designed from the beginning to respond to the two things that always occur on every project - realization, and oversight.

So there you have it. Go forth and be Agile.

Links

In this section I'll maintain and periodically add links to particularly good Agile articles:

1) The Atlassian article referred to above - Is the Agile Manifesto still a thing? 

2) A good article from Forbes  on applying Agile in organizations, and outside its origins in software development.

3) A excellent review of Scrum VS. Kanban . Some great insights here from an experienced developer.