Intro to Agile

Agile can mean a lot of different things to a lot of different people. My parents think of agility in terms of the speed and ease with which a gymnast completes a routine! They loved watching the recent Olympics. A friend of mine in IT thinks that Agile involves Post-it™ notes and spending the morning standing around. For me, Agile has a very specific meaning. So specific that I even capitalise it as a proper noun! In this post, I’m hoping to cover the absolute basics of Agile within the space of not just project work, but day to day operations as well.

What Agile is and is not

As mentioned in the introduction, Agile can mean a lot of different things to a lot of different people. For the sake of clarity and to ensure we’re all on the same page, the form of Agile we’ll be discussing today was popularised in the 2001 Agile Manifesto for Software Development. It is a set of values and principles that focus on delivering value and promoting communication. It is not a framework; it is not prescriptive. Instead, it provides an ideal.

We’ll delve a bit more deeply into these values later on, but for the meantime I’d like you to consider the analogy that Andrew Littlefield used in a blog post available here. He suggested that Agile could be thought of as a diet, such as vegetarianism. It’s an overarching set of values that guides certain practices. In short, Agile should be considered as a set of guiding principles and values and not a framework, it does not provide a series of steps to follow.

Agile values

There are 12 principles that distill down into four key values. These values are written in such a way that the items on the left (highlighted in bold) are valued more that the items on the right:

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

It’s important to point out at this stage that we’re not choosing one over the other. Both aspects of each statement have value, it’s just that we consider the items in bold to be more valuable.

For example, the value around individuals and interactions, we can definitely say there is value in a robust set of processes and having access to the right tools, however, if push comes to shove, the items on the left will deliver more value. I can think of many times when getting the right people in the room to discuss an issue was vastly more valuable than mindlessly sticking to processes or trying to buy a boxed tool that’ll magically solve the problem. Having the right people interacting with each other will always be more valuable than tools and processes.

The same could be said for the second value. Documentation is undoubtedly important. I’ve known teams make the common mistake of saying, “We’re Agile, we don’t do documentation.” This isn’t true of Agile; some documentation has significant value. At the end of the day, however, there is significantly more value in working software. Think of the Microsoft suite of products. When was the last time you read a user manual for Word, Outlook, or Excel? I’m assuming never. These products are designed and developed in a way that people simply know how to use them. Generating an extensive user manual would be a significant investment of resources, where perhaps a simple FAQ or a basic tutorial with screenshots would suffice.

Customer collaboration over contract negotiation can be a tough one to explain, particularly when you work as a consultant. Clients often want exact outputs defined to ensure they’re minimising risk and getting value for money. But what happens if the solution that was contracted turns out not to be the right one? If you signed a contract to deliver ‘A’, but halfway through development you find that ‘B’ is actually what you needed, wouldn’t that be a risk? Would that be value for money? Aginic approaches projects with a one team mentality. We try to break down the client/vendor roles and focus on succeeding together as a single entity. As such, we tend to have contracts that focus on time and effort, instead of specific outputs. This way, we can focus on a common goal that, within the range of time/effort that has been committed, can be adjusted and flexed to ensure we are delivering value. So, contracts are important and it’s good to know what the boundaries are, but customer collaboration and working together is vastly more important.

The last value is probably the easiest one to conceptualise. Often, when we make plans, we know the least. We have a hypothesis on what we think the problem is, we have an assumption on what the solution is, but until the ‘rubber meets the road’ we don’t actually know. Therefore a plan has value, it is a great starting point, but once we start work and/if things start to change, sticking to that plan becomes less and less valuable. Adapting to change, however, will always be the better option.

I don’t think there’s much benefit to learning these values off by heart. They’re easy enough to find online. I do think there is a lot of value to try and apply personal experience to each of these values and see which ones are more important to you.

But what about sticky notes and stand-ups?

So we’ve covered the values and principles of Agile, and the fact that it’s not a framework. I’d like to briefly touch on the most popular frameworks used within this space, Scrum. To continue Andrew’s analogy from earlier, if we equate Agile to vegetarianism, then Scrum is a recipe for chickpea tacos. By following the steps of the recipe, the output will inherently be inline with the values. If we follow the steps laid out in the Scrum framework, our processes will be inherently Agile. That said, if we change the recipe, or make additions here and there, we start increasing the risk that we’re not being Agile.

I won’t go into the basics of Scrum in this article, if it is something you’re interested in learning more about, I’d strongly recommend you read the current Scrum Guide. At Aginic, we advocate the application of any framework, Scrum or otherwise, in its most basic form. Try it for a couple of cycles and then make adjustments if needed. A common mistake we see is when organisations try to preempt issues that may occur, or perceive themselves to be more complicated that the framework permits. As a result, they make adjustments to the recipes before even trying it and more often than not, end up breaking the process.

Summary

Agile as a philosophy has been around a long time. More recently, it has been popularised through the Agile Manifesto and various frameworks such as Scrum. Although Scrum and Agile are often used interchangeably, it’s important to know the difference:

Agile: Set of values and principles – Similar to the concept of vegetarianism

Scrum: A framework with steps to follow – Like a recipe for chickpea tacos

You can be Agile without using Scrum, but you can’t use Scrum without being Agile.