The five areas of Agile

In a previous post I claimed that any set of principles (or methodology for that matter) for good software development should cover these five areas:

• collaboration
• software engineering
• work management
• product
• reflect & experiment

I mentioned these five again in my post “What is a scrum master?”, but that’s all I’ve said about them. That changes with this post. I will provide a brief description for each of the five areas. I’ll share some ideas how a list of the five areas of Agile might be useful. And I’ll reflect on the question: Are they the five areas of good software development or of Agile software development?

The five areas

collaboration: What does working together look like? How do people communicate? How do they relate to each other? What kinds of power are present and how are they used?

software engineering: What does good software engineering look like? So basically, technical excellence. This is a huge area with topics like coding practices, architecture, CI/CD, testing, monitoring, etc.

work management: How do you remain (sufficiently) in control of the work? How do you keep track of it? How do you decide who will work on what? What does “done” mean?

product: How do you know the thing you’re building will be of value to people? How do you identify and elaborate their needs? How do you find the right people? How can you discover interesting next opportunities?

reflect & experiment: How do you get better at what you do? How do you reflect and evaluate? How do you design, run and evaluate experiments to get better at what you do?

Agile software development or just software development?

Looking up that old post from 2021 I was surprised to see I bring up these areas as the five areas of good software development. On the other hand, the title of the post is “An approach to teaching Agile 20 years after the Agile Manifesto”. So I guess I was equating good software development with Agile software development.

Because if I had had to come up with five areas of good waterfall software development, I don’t think I would have come up with the same list. I’d probably keep “software engineering” and “product”, even though what they would look like would be different. “Collaboration” would change into something that implies more handovers and documentation. “Work management” would become “project management”. And “reflect & experiment” would become “governance and steering”?

So in a way the change would not be overly dramatic. Software development is still software development. But I can’t deny that the words I chose for these five areas have a distinct Agile flavor to them.

Three ideas how this list might be useful

So great that we can now divide Agile into five areas, but how is that useful? Sure, as I mentioned above, we can use it to categorise principles. Or skills. But that’s still descriptive. It doesn’t change what we do.

Is this methodology complete?

One thing the five areas lets us do, is evaluate a software development methodology for completeness. In my 2023 post “What is a scrum master?” I wrote:

Scrum definitely covers work management and reflect & experiment. Arguably it covers collaboration (as in: soft skills) to some degree. It does not cover software engineering, because it’s not specific to software. And it does not cover product. The Scrum Guide (2020) does say “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” but provides no guidance on how exactly to do this.

Which is also the reason that originally Scrum advocated for combining it with Extreme Programming.¹

So if you ask someone how they do software development and they reply “We’re Agile and we do Scrum,” you know that’s not the complete story. Significant parts are missing. What that means exactly will depend on the organization. In most cases though, it will mean that Agile has been reduced to teams delivering pieces of work in two week-sprints, while doing all the Scrum Events. So a hollow shell of what Agile could be.

Who in my team covers which areas?

An good question to ask is: Who in my team covers which areas? Who pays attention to them? Speaks up when they require more attention? Gives a compliment to someone who performed good work in an area?

An additional question to ask is: To what degree does each area fall into our circle of control, our circle of influence and/or our circle of concern? Some areas might fall mostly in your circle of control, while others may fall mostly in your circle of concern. This tells you in which areas your team has autonomy and in which areas decisions are being made for you.

Where can we improve?

Last but not least, you can use these five areas as a tool to see where your team can improve. Especially if you do it as a follow-up on the question of the previous question. Where are you falling short? And where can you turn up the good?

In this sense these five areas could be a starting point for an Agile maturity model. Where each area has like 5 to 12 practices and you score your team on each of them. I’m not a big fan of such maturity models. I’d rather have a team decide for themselves what goes into each of the five areas and let that be the starting point of the conversation.

What do you think of these five areas? Do they make sense? Would you pick others? More? Fewer? Can you think of some more ways in which this model might be useful?