Are you really ‘Agile’?

What does it mean to be ‘agile’ as an agency? After all, many teams pride themselves on being nimble. It’s essential that you bring an energetic and flexible approach to every project.

Creating quality work, quickly: that’s a handy skill in a fast-paced environment. But do these traits make you ‘agile’? The answer, oddly enough, is both yes and no.

Let’s find out why.

As a business, it’s worth striving for agility. A fleeting glance at the dictionary offers some insight into why the term has become more prominent in conversation over time, and a bit of an agency buzzword.

Removed from its context as a project management methodology, agile is an adjective that alludes to easy, graceful and precise movement.

In the context of this article agile is an idea, a practice – rather than a simple adjective. The irony is that it’s an idea/practice that’s not always adopted with the ease, grace or precision suggested by its name.

In reality, the term is frequently misapplied thanks to confusion around what it means in various contexts.

So, let’s look into agile: what’s involved in the methodologies, where the practices come from, and whether they could benefit your business or project.

For the record, there are many different agile methodologies and each all have their own intricacies (e.g. Kanban, scrum). I won’t be covering all of them in this post. Rather, I’ll be referring to agile methodologies in general throughout to provide you with a baseline understanding of some early concepts. Given the methodologies are all based on the same fundamentals, they can be used somewhat interchangeably (as where we say “agile” or “scrum” in this article).

Agile: where it all began.

In order to understand agile, it helps to know it’s origins.

In 2001, 17 people met at a ski resort in Utah. They were searching for an effective alternative to the established and well-trodden process of document-driven software development.

At the end of an intensive two day workshop, one of the participants commented that it was a privilege to work alongside a group of people who hold a set of compatible values.

The values in question were based on trust and respect for every member of a project. They were based on promoting organisational models that emphasized the significance of teams. They were based on collaborating to build the types of communities in which the founders liked to work.

The ultimate output of this meeting was a text that expands upon and articulates these values. Named the Manifesto for Agile Software Development, it was signed by all of the participants under pale moonlight in a sacred temple (not really, although that would have been cool). I’m guessing it was signed at the ski resort. And that was that.

The Agile Manifesto.

The Agile Manifesto offers a set of four values and 12 principles.

The four values are:

‘We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.’

The 12 principles behind the Agile Manifesto:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Now, a few key points to keep in mind.

Agile talks specifically about software development.

These principles are designed to apply to web development, app development, or similar disciplines.

Pretty straightforward, especially when you consider that the first line of the Manifesto is: “we are uncovering better ways of developing software…”

They’re not ‘rules’. They’re values.

Agile is not about concrete guidelines.  Agile is a series of guiding principles that will help a project to develop in a certain way. It’s not about abandoning one project management methodology in favour of another. That’s why we’re very careful to say that it’s not about forsaking the ‘right’ element of each value for the ‘left’. It’s more about focusing on a particular blend of flexibility, adaptability, people, prototyping and collaboration. It’s about prioritisation.

It boils down to the distinction between values and rules. They’re defined as:

• Value: A person’s principles or standards of behaviour – one’s judgement of what is important (in life, for example).
• Rule: A set of explicit or understood regulations or principles governing conduct within a particular activity or sphere.

The differentiator is that ‘rules’ are dictatorial; they’re mandated; ironclad. Rules are usually tight-knit and they govern what has to happen.

Usually, if rules aren’t followed, there’s some implied punishment or consequence. In short, they’re fully prescriptive.

On the flip-side, values are principles of prioritisation. There’s generally no consequence for deviating from a value. In short, a value will offer a framework for appreciation.

It’s not a matter of ‘if we do the left part of the value, then we can abandon the right’.

In the value: Responding to change over following a plan – ‘responding to change’ is the left, while ‘following a plan’ is the right.

Those elements on the right are the established way of operating. The well-trodden production path. Those elements on the left are more aligned with the agile methodologies.

‘Left over right’ alludes to the idea that agile methodologies appreciate the elements on the left over the items on the right, because traditional production wisdom typically appraises them the opposite way.

That’s not to say that left and right are mutually exclusive. Or even oppositional. In fact, we still very much need them both.

Imagine a see-saw. Both parties play an essential role in making it work. You’re not going to have much fun going solo on a see-saw.

The parties don’t necessarily need to be evenly balanced. There just needs to be some counter weight.

In the same way, an agile approach appreciates the necessity of the elements on the right: they’re involved in making the project work. It’s just, those aspects on the left are of a higher priority.

A see-saw-for-one is going nowhere, in much the same way that a project without any clear plan, contract negotiation or process may struggle to get off the ground.

Examples.

Agile values offer a framework that helps guide your approach to certain decisions that may impact upon the project you’re running.

The values can play out in a number of ways, and affect projects to varying degrees.

Here are some examples of each value in action.

Individuals and interactions over processes and tools.

Value people and personal contact over rigid processes. Prioritise shared responsibility among team-members over tools. For example, commit to short, frequent meetings around a work-in-progress board, with all team members present.

The scrum methodology, as an example, is based on the idea of self-organising teams. By involving team members regularly and discussing problems as they arise, we establish an environment for the people involved to take ownership of the development of a project.

This is especially true when teams can access the Product Owner immediately.

You can ask questions and receive answers, quickly.  The result is frequent and meaningful conversations rather than biblical swathes of over-documentation – a chat rather than an extensive chain of emails.

Talk things out frequently with your colleagues. Take ownership together.

Of course, we still need processes and tools. Whether it’s a physical job board, a tsunami of sticky notes, or a web-based task management platform, you need visibility over who’s doing what and when. It’s about achieving the optimum balance for the team to prosper: that’s how the right-left value see-saw system works.

Working software over comprehensive documentation.

Minimum viable products, or MVPs, are used to trial functionality early on in the production process.

MVPs are agile, regardless of whether they’re operating in software production or on the parquet courts of the NBA. Take a look at any name in this list and you’ll see that pretty quickly.

Attempts at wordplay and my personal basketball fandom aside, the MVP is a key hallmark of any agile methodology.

This value alludes to working with minimum viable products, or low-fidelity software replicas that mimic the functionality of a particular feature or module. This empowers a team to iterate, adapt and change products based on real feedback, born from real use-case scenarios. We can see how effective or valuable the product is by using it. It also allows us to test ideas that might produce a high degree of scepticism.

If a significant amount of effort goes into documenting requirements before each line of code is written, mistakes can slip through until the later stages of development. This is usually when problems are much more… problematic.

You may be performing due diligence by extensively planning each incremental stage of the project, or you could be putting a lot of effort into preparing an awful piece of software.

If you don’t build or test anything until the planning document is filed away in pristine condition, then you’ll never know which path you’re taking. Until it’s too late.

With working software, you can work out the kinks early on.

Customer collaboration over contract negotiation.

Having access to customers, clients or product owners on a daily basis allows scrum teams to access the information they need, faster.

It enables the quick and uncomplicated resolution of issues because you have frequent access to the person who holds the ultimate vision for the product: their insights, ideas or intentions for the final piece.

On the other hand, contract negotiations often delay the start of a project for an unnecessary and unduly length of time. In a fast-paced or time sensitive industry, this can cost you money and cause anguish.

With that said, contracts are often put in place for the protection of each stakeholder (and not to mention, to potentially save on Dineros down the track). So they clearly have a role to play too.

Remember, these values are written as ‘over’s, not ‘instead of’s. Contract negotiation is still a valuable part of the process, it is just prioritised differently within the agile methodologies.

Responding to change over following a plan.

Planning is great. I’m a firm believer in having at least some form of direction, and a loose understanding of how you’re going to arrive at a destination.

For example, I know I’m going home after work every day. I know how I’ll get there. But, I may not take the same route every time. Peak hour traffic on Punt Road makes sure of that (if you live in Melbourne, I’m sure you’ll agree).

In a scrum context, the “where you’re heading” is the vision of the product (held by the Product Owner). The “how you’re going to get there” is your product backlog.

Having said that, to continue with the driving analogy, you have to be flexible enough in your approach to make allowances for things that may be 5km down the road. Sometimes, we encounter things we didn’t – or couldn’t – see when we set out. That’s the reality of moving forward and making progress.

That’s why this value exists. It’s about recognising those instances and responding accordingly, or realising that it may be best to change course based on the information that’s available once you’re experiencing a particular, unexpected situation.

So, with those values in mind, are you agile?

Now you can reflect on whether agile methodologies are really something that appeal to your organisation. Or whether, in reality, the goal is to undertake a traditional waterfall approach with a quicker, cheaper, or less intensive process.

It sounds like a harsh point to make, and one that is potentially pretty invasive from a cultural perspective.

But that’s kind of the point. Adopting agile methodologies is a truly invasive process, from a cultural perspective. It involves wholesale systemic change with extensive, ongoing buy-in from a range of different parties.

Understanding the origins of the values and how they can play out in a workplace is a critical first step on an agile path.

But what comes next?

Do you start searching for the right client? Perhaps someone who’ll be receptive to a new approach and value system? Do you wait for a project that screams ‘agile’? Or, do you start to up-skill your developers, designers and sales people, in order to equip them with skills and strategies for running agile projects?

The answer, oddly enough, is all three. At the same time. Each one is essential and each one requires exploration in a dedicated post, which I intend to deliver over the coming months.

But first thing’s first.

This article has touched on understanding, values and balance: a basic understanding of agile, the values that contribute to the methodologies, and the balancing act that can be involved in achieving them. And that’s an oddly fitting blueprint for where you should start in your implementation of agile – with understanding, values and balance.

Start to cultivate a shared understanding of agile values, between your colleagues, client, team or any other additional stakeholders. Tinker with a balance of traditional process and agile methodologies.

The ultimate goal is achieving alignment between organisational values, team-member philosophy, client needs and project scope. When you find that perfect blend of shared goals and philosophies, then an agile approach will almost justify itself.

Like any balancing act (or the see-saw that I mentioned earlier) there may be slight ups and downs. But there’ll be clear and pleasing benefits too.