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.
So what exactly is Agile?
tl;dr -> 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 manifesto is short and easy to read. Please do so now.
The Atlassian article above also does an excellent job of looking back on the manifesto, considering its 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 strict and formal up-front analysis phase may be exactly what’s 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.
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 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.
In this section I'll maintain and periodically add links to particularly good Agile articles:
1) A good article from Forbes on applying Agile in organizations, and outside its origins in software development.
2) A excellent review of Scrum VS. Kanban. Some great insights here from an experienced developer.