Contact
Contact

When is Agile not Agile? When it's agile.

By Caz Brett, Product Director - Steer73

In 2001, in a chilly ski resort in remote Utah, software delivery changed forever. Throwing out the document-heavy processes of software delivery methods, seventeen representatives from the field came up with a new idea, a new approach: agile. The output of which formed the Agile Manifesto, and four key principles.
Twenty years later, we use agile in passing to express these common approaches to delivering software, we drop the term into conversation with a common understanding that it means fast-paced continuous integration. But here’s the dirty secret – many people who describe themselves as working agile actually don’t work agile. And many more don’t even understand what agile means. Ask yourself, without heading to Google, can you name the four principles of the Agile Manifesto? I’ll imagine most of you can’t. It’s so keenly steeped into what we do, we’ve almost forgotten.
Many people when asked to describe agile, will begin to describe Scrum, or Kanban. I’m just going to stop you there. Scrum is not Agile. I know, I know, hear me out. Scrum is a framework. It encourages the use of a Product Owner, sprint planning, and sprints. There are the somewhat ominously named ScrumMasters. It’s a set of loosely defined activities that can happen to achieve complex software development activities. Scrum is a framework – and you may be surprised to hear that it predates the agile manifesto by 15 years.

Maybe I’m talking semantics here, but whilst Scrum could be agile, it is not the equivalent. Scrum is a framework. Kanban is also a framework. Lean, Extreme Programming, also frameworks.
Agile however, is not a framework. It’s not a prescriptive methodology either. Agile is, for need of a better word, a philosophy. To work agile is to work using the guiding principles set out in the manifesto.

So are you working agile?

If you:
  • Reduce your processes to focus on people
  • Consistently deliver working software without heavy documentation
  • Collaborate with your stakeholders and users
  • Adapt as you build, rather than following a set plan
then you are almost certainly working agile.
In our experience though, whilst we might aim to do all of these things when possible, the truth is that it often isn’t practical. If you are delivering to a deadline, or to budget limitations, it’s difficult to work truly agile.
At Steer73, this looks like fixed price work. We will help you build what you need to within the limitations, but we will need to work closer to Waterfall, meaning fewer feedback loops and limited opportunity to adapt. We can, and do, work to plan because we understand that often this is exactly what your business needs. There is no shame in using agile philosophy but working in a Waterfall way.
BlueInk_Development illustrations_LIGHT_by VIGE.CO-04
In comparison, our long-term clients benefit from working agile as we are able to continuously improve on our products, release improvements and updates regularly, and work collaboratively to deliver industry-leading software. We can be flexible with our approach, working to deadlines when necessary but with the added benefits brought by agile. Sometimes we will lean on frameworks for our work, enjoying elements of Scrum and sometimes Kanban, but at the core of everything is the principles that sit behind agile.

So when is agile actually Agile?

There is no fixed view on this one. My personal take is this: if you’re using the Agile Modelling approach, or Agile Unified Process, then these are named frameworks and deserve a capital A. For the wider sense of working in an agile fashion, then no capital required. Agile is just a way for us to value the things that help us deliver software in the most efficient way.

To read the Agile Manifesto head here: agilemanifesto.org/text

To find out how Steer73 can help with your projects, agile or not, head here: steer73.com/services