Agile values
I'm currently helping a client implement agile ways of working to deliver a digital transformation. That's turning out to be a very time-consuming exercise, so this article is being published today rather than last Friday, which would have aligned with my regular schedule. I hope to return to that regular cadence at the end of this week.
As part of that client work, I'll be running a set of training sessions. Once I have, I plan to publish that material here, in whatever format I present it. For now, though, I will use this article as an excuse to think through some of the content.
What is agile?
When working with clients, many will have some answer to this question. There's no value in judging who's right and wrong, but the important thing is that most of those answers will differ, creating confusion in the team. Technical teams are more likely to have done something they call agile, but that often just means they have more things to unlearn before they can get started.
In addition, in most organisations, some individuals will have undergone an agile transformation that produced minimal or no results and will have already dismissed it as another fad.
Therefore, I often avoid using the term 'agile' early on; instead, I use a more descriptive term that's harder to argue with, like 'incremental value delivery' or 'customer-focused delivery'.
Anyway, I will talk about agile for the rest of this article, but that's worth considering. Below is The Agile Manifesto, taken from agilealliance.org:
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, which I won't reproduce here, flow from these four values. The practices that most people focus on, such as daily stand-ups or team retros, are ways to manifest these values and principles in day-to-day work.
Most of this article will focus on the items on the left, so I want to emphasise that final statement: agile does not say that the items on the right-hand side have no value, just that those on the left are more valuable. It is, therefore, not saying that there should be no documentation, just that working software is more important.
A lot of the language around agile, particularly Scrum (the most popular implementation), is inherently software-focused. For example, team members are referred to as Developers. But Developers can just be people creating a thing; it doesn't necessarily have to be software. I've done agile in a consulting environment where the output was analysis and recommendations. It's worth remembering that as you go through this article.
Starting with the values
The temptation, of course, is to start with the practices. That's because they're pretty easy to implement; I can schedule a daily stand-up with the team, a sprint planning session, and a retro in under 10 minutes. Then the team very much looks like they're doing agile. In fact, they'll probably even see some benefits, but they won't be the huge changes that Agile promises. That's because going through the motions without really understanding and buying into the 'why' won't lead to those huge results.
While starting with the values can feel overly theoretical, getting the team to understand and buy into those values first is what gives those practices their true power. So, that's the framework I'll use for the rest of this article.
Individuals and interactions over processes and tools
What this means
The intent here is to get all the relevant people talking and interacting daily. 'Relevant people', of course, include the core members of the agile team but should also include people representing the business or the customers.
Rather than defining processes for gathering requirements and creating and sending out templates (for example), Agile proposes getting all the right people in the room to discuss, brainstorm, and agree on a solution as we go along. The more closely all the right people work together, the more they'll start to speak the same language and understand each other's perspectives, and the better the final result will be for the customer.
How not to overdo it
Again, the agile manifesto values the left more than the right. So, this is not to say there should be no processes and tools. Daily stand-ups, demos, and retros can all be considered processes, and sprint boards and burndown charts are standard Agile tools. But those tools support the individuals and interactions rather than taking priority over (or worse, replacing) them.
Working software over comprehensive documentation
What this means
Deliver working software to the end user as early and as often as possible. Putting some working software in front of a customer, getting their feedback, and then iterating on what has been delivered is both more effective and faster than trying to gather and clearly define all requirements upfront so that you can be sure you build exactly the right thing.
There are two problems with trying to gather and define all requirements upfront:
- Users don't know their requirements: this is not a judgment; it's just tough to define what you want a system to do in the abstract. When we ask users to do this, the result is often either an unnecessarily long list of requirements added 'just in case' rather than a focus on what's actually needed or vague and incomplete requirements statements.
- Requirements change anyway: even if it were possible to define user requirements perfectly upfront, they'll have changed by the time they are fully delivered. All that upfront work turns into wasted effort, and the end user ends up with what they wanted six months ago, not what they want now.
Heading into the first few sprints, a new Agile team will experience anxiety. They will think they have a less clear view of what's going to be delivered than they were used to. The reality, though, is that all they had before was a false sense of security, and in fact, being forced to actually build the system forces clarity far more rapidly than any documentation would have been able to.
How not to overdo it
This does not mean you never write anything down. In fact, the amount of planning and documentation a team completes as part of a sprint (mainly in sprint planning) is at least comparable to the amount of documentation that would be delivered using any other delivery method.
The difference is that only the documentation needed to define and deliver the specific user stories chosen for this sprint is created, and hopefully, only a matter of weeks before it's put in front of a customer, rather than attempting to document everything that will be delivered in the months ahead.
Customer collaboration over contract negotiation
What this means
Often, projects end up with a very formal and sometimes very confrontational approach to working with customers. Requirements are defined upfront and written into a contract, and everyone signs up for that contract. Changes go through a change control process, which typically sets everyone up to see changes as a bad thing to be avoided at all costs.
Agile aims to collaborate and work closely with the customer to understand and deliver what they want, which is likely not what they said they wanted last month. A truly agile team sees this change as an opportunity to deliver more value to the customer, not a threat to be avoided or resisted.
How not to overdo it
This does not mean catering to every individual stakeholder's every whim or reacting unthinkingly to what a customer says they need. This is where a skilled Product Owner is valuable.
When stakeholders disagree, it's up to the agile team, and in particular the Product Owner, to reconcile the situation. This may involve proposing a compromise solution, arranging for all stakeholders to discuss and debate, or something else. Reacting immediately to one piece of feedback might get the team caught in an endless loop of minor tweaks based on whoever spoke last.
Secondly, customers don't always know exactly what they want, and a good Product Owner will help them articulate that more clearly. If a customer says, "I don't like it," there's not much the team can do with that, but the Product Owner can help the customer move from that to "I find this part of the webpage confusing because I didn't realise I had to hover over the box to see the instructions" which is something the team can do something about.
Responding to change over following a plan
What this means
Agile teams must learn to embrace change where other planning and delivery methodologies typically resist change. This is because the agile team is focused on delivering value above all else. If there's an opportunity to deliver more value because of changing information, the team should embrace it rather than push back on it.
Arguably, the best indication that a team truly embraces agile values rather than simply adopting some of the practices is its ability to embrace and respond to change as a positive thing.
How not to overdo it
Not following a plan does not mean reacting to every income request in real-time. In fact, agile teams following Scrum tend to be very strict about not disrupting an ongoing sprint except in very extreme circumstances.
By default, new work goes on the backlog. The difference is that the backlog is reviewed at the end of the current sprint, which is usually only a couple of weeks away. It might be the very next thing the team works on after this sprint.
Conclusion
This is a very quick overview of the Agile Values. Over the coming days, I'm going to create some agile training materials, starting here, to upskill a team I'm working with.
The key is that understanding the values gives meaning to the agile practices that people more commonly begin with. Without these values, those practices can feel hollow, and your team won't be able to deliver the true value of agile.