Not long after computers were invented, it became apparent that making them do things that were useful was going to require a structured approach.

One of the first reactions to this need was the creation of Waterfall - a serial technique that processes things like design and testing one after the other. It seemed like a good idea at the time, and indeed, it was better than nothing. But the idea of taking a long time to deliver something you thought was awesome at the start, to customers who may well have forgotten you exist, is obviously deeply flawed.

In 2001, a group of developers got together and - quite famously - described something that's now known as the Agile Manifesto. Since that time, people who make software have come to refer to methods like Scrum (which actually predates the manifesto) as Agile development practices. The core of them all is this idea that development is a collaborative thing that should be about delivering high value stuff to people as quickly as possible.

While that core is still super valid, another underlying aspect of Agility - summed up by the words “inspect and adapt” - is often criminally under-utilised by teams that think they're currently working in an Agile way. Teams that are performing Scrum, for example, would be forgiven for thinking they're operating optimally because their story-points and velocity are stable. In reality, those concepts are increasingly dated and infinitely gameable. How many teams, for example, are sacrificing refactoring and integration tests in an effort to maintain a stable trajectory or get the right number of stories across the line?

True agility comes from analysing what you're doing and finding ways to improve it. More and more, it's becoming obvious that things we thought were important only a few years ago - like estimating, story-points, velocity and even the sprint - aren't always even necessary. Instead, Agile practitioners are finding success by concentrating on delivering value frequently (as in, deploying to production 10+ times a day) and decreasing the length of time between ideation and delivery (cycle time) so that feedback comes in faster.

But how do you do that?  One approach is that proposed by the Modern Agile community. In part, recognising that Agile is now about much more than software delivery, Modern Agile is a revisiting of the original Agile Manifesto that focuses on DevOps mechanics like continuous delivery and a focus on people. It also suggests that safety and experimentation (which are often closely associated) are more than just a footnote, elevating them to first-class members of the four-principle concept:

Image courtesy of modernagile.org, licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

That doesn't mean you can'tuse Scrum to deliver in full adherence to the Modern Agile mandate. In fact, some - like Stephanie Ockerman - think that Scrum is the ideal way to deliver on Modern Agile's promise. What it does challenge you to do, however, is to stop doing Agile and start being Agile. What I mean by that is simple; outside of the principles outlined above, everything is on the table.

So what do those four, nicely graphic designed segments actually mean?  Created by Joshua Kerievsky, the CEO of the Agile-focused company Industrial Logic, the public domain concept - much like the Agile Manifesto before it - establishes four simple principles around which teams should self-organise in order that they are able to achieve greater success.

1. Make people awesome.

This simple sentence actually encompasses more than you might think, including everyone from team members to customers and more. The core idea is that, by focusing on making people awesome, you make people happy, better at their jobs and help them deliver more value (be that in product or feedback to the creators of said product.)

2. Deliver value continuously.

Whether it be via DevOps practices or simply engaging with your customer more frequently, the idea here is to make sure that you get things into your customer's hands as soon as possible. Got some feature you think they want that will take two months to create? Make some ultra-tiny variant that delivers some of the potential benefit much faster and you might be surprised to find out that what you've built is enough, or that going hands-on with it is all that it takes for your customer to realise their ambition actually lies elsewhere. If you are building code, this also means doing things like automated deployment into production and crafting tests for your work that checks you're doing things the way you should be right from your first line of code.

3. Make safety a prerequisite.

This doesn't just mean ensuring people are wearing hard hats if you're working underneath pine trees, it's also about people feeling like they have the support of their peers and that the people they're working with will be there when they're needed. It's about making it clear that participation is valued and that ideas will be listened to. It's crafting an environment in which everyone has a voice and teams are made up of equals - no matter the experience or skill that each individual brings to the table.

4. Experiment - learn rapidly.

When people feel safe, they're more likely to experiment. Experimentation lets people push the boundaries and find new solutions to problems they might not even have - which is a wonderful reason to encourage it. Encouragement, by the way, doesn't mean just saying things. Make sure your team members have the time and resources available to experiment - and then make sure to either celebrate success or learn from failure (remembering, of course, it's safe to fail!)

All that said, however, don't get too hung up on the details. Compare your approach to the above and challenge yourself to identify aspects of what you're doing that you've previously considered to be off the table - then ask yourself why. Ultimately, if you're focused on delivering value to your customers as quickly as possible, taking time to inspect and adapt your process in ways that improve it, you're Agile. If you're going to planning meetings, having stand-ups and reporting on velocity - and the above seems strange to you - you probably aren't.

Keen to learn more? Joshua Kerievsky is running a 1-day Modern Agile workshop in Wellington on 28 November, and delivering a keynote speech on Modern Agile at AgileNZ on 29-30 November. For a deeper-dive into delivering value continuously, attend Joshua's 2-day Continuous Deployment workshop in Auckland on 1-2 Dec.