If you've worked on a digital project over the past decade, you're probably familiar with the term 'Agile'. What you may be less familiar with, is what it actually means in practice. There is much confusion surrounding Agile and the concept has taken a bit of a beating in recent years. This is largely because it's been hijacked as a series of (often disconnected) processes, rather than a holistic mindset.
Okay, so what do you mean by an 'Agile mindset'?
Literally, taken holus-bolus from the Agile Manifesto, it means:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan.
This does not mean that processes, tools, documentation, contracts and plans are not important – they absolutely are and this is one of the pitfalls many people fall immediately into when considering agile. It’s just that the things on the left – the people and their interactions, working code, collaboration with the customer, and being open to change – are more important.
A brief history lesson
Agile software development is not new. In fact if you consider lean manufacturing, which has similarities in thinking, you can take it all the way back to Henry Ford in 1913. Even more relevant was the Toyota Production System, which took Ford’s innovation and really made it customer focused by reducing the time taken to deliver something of value to the customer.
Waterfall is newer than lean manufacturing. It was first described in 1970 but really became a 'thing' in 1985 when the US Department of Defence stated that 'the contractor shall implement a software development cycle that includes the following six phases: Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing'.
New-ish tech players such as Google and Spotify have certainly adopted Agile thinking, and are big advocates of processes such as Scrum (see the often referred to Spotify Engineering Culture video).
When something new comes along and popularity grows, there is a tendency for people to try to 'get on board' and attract some of the reflected glow associated with the latest bright shiny thing. I’ve heard statements like “We have a daily stand-up and do sprints, therefore we’re Agile”. The 'ceremonies' often associated with Agile such as stand-ups, sprints, retros, and backlog grooming mean nothing if not approached with Agile thinking.
Well then, what is the process?
The answer is: it depends!
Some of the more common implementations of Agile thinking include Scrum, Kanban and Extreme Programming:
- Scrum: Work is broken into actions that can be completed within short, time-limited iterations, called 'sprints'. Progress is then tracked and re-planned in 15-minute stand-up meetings, called daily scrums. Best suited to larger teams of fully committed resources with a high level of client involvement, e.g. where there is a Product Owner.
- Kanban: This approach aims to manage work by balancing the demands with available capacity, and improving the handling of bottlenecks. Work items are visualised to give participants a view of progress via a Kanban board. Best suited for limited capacity teams.
- Extreme Programming: Like Scrum, this approach focuses on frequent 'releases' in short development cycles, and may also involve programming in pairs or doing deep code reviews, and avoiding programming of features until they are actually needed.
The common threads
The common attributes you’ll find in a methodology rooted in Agile thinking are:
- A focus on customer satisfaction and mutual trust
- Flexibility around changing requirements
- Frequent and iterative delivery of working software
- Daily communication and collaboration
- An emphasis on face to face contact
Following these guiding lights from the Agile software development principles, you could even get crazy and come up with your own process!
The view from the trenches
Anyhoo, enough gabbing from me, how about hearing from some of the people who are actually in the trenches implementing all of this?
Matt Stobo, Digital Producer, Luminary:
"In a waterfall model, the project rarely has the opportunity to evolve or manage change. If it does, it is usually an expensive process in terms of both time and budget. Agile is built around change management. The biggest difference is in decision making and ownership. Working closely with the client throughout the entire process affords great ownership over the project and the final deliverable, both for the client and the agency team. Ever had an issue with stakeholder or change management? Try Agile."
Adrienne Steier-Clark, Marketing Manager, Allnex Composites ANZ:
"It’s very collaborative, it’s a team effort. Instead of thinking about the project as a whole, it has been broken down into segments. You’re constantly working on different parts of the site and you’re constantly receiving results that your internal teams can engage with. That’s probably the beauty of this type of Agile building process. "
Sarah Dam, Front End Developer, Luminary:
“Agile has definitely brought out the best in me as a developer. Sprints and tasks give a real sense of progress, both as a developer and for the client. If a team member is missing for a day or so you don't come to a grinding halt because you always have a prioritised list of tasks to go on with.”
Anthony Mair, Senior Digital Operations Manager, NGS Super:
“For our team at NGS Super the engagement and support from Luminary has been exceptional. Our team has adopted new Agile ways of working thanks to the assistance of Luminary, with continual delivery becoming part of the culture at NGS Super.”
Still here? Great!
If you’re interested in understanding more about how Agile works at Luminary, please check out this page on our website – Agile-focused delivery.
Want to tap into the expertise of an agency that’s been in operation since 1999?Get in touch
Want more? Here are some other blog posts you might be interested in.