Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.
The fifth Principle of the Agile Manifesto reads:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Of all 12 principles, this is the one where I’m least confident my interpretation matches the original signers’ intention. I’ll share what it means to me, but I’m very curious if others agree.
What It’s Not
In my original piece that started this series, I talk about Agile being a revolution, and this principle doesn’t seem so revolutionary at first. What’s controversial about getting good folks together and supporting them?
It’s worth thinking about what the opposite would be, maybe something like this:
Build projects around a repeatable process. Create effective monitoring and feedback mechanisms to ensure the plan is followed.
Honestly, if someone said that to me, I wouldn’t immediately think it sounds horrible. But when you contrast it with this fifth Agile principle, the problems become more apparent.
The pre-Agile world was largely focused on command and control structures, finding processes that worked and then rigidly adhering to them. Of course there have always been teams building great software in supportive environments, but the standard approach focusing on process and tools was, frankly, dehumanizing.
Focusing on the individuals – providing support and trusting them – was not the standard approach.
Who Are Motivated Individuals
Focusing on individuals is clearly core to Agile, but the motivated part is less self-evident. It has at least a couple of meanings to me.
One of my early Agile mentors would often talk about how she just wants to work with people who give a shit.
It may be a bit crass, but it’s the most succinct way I’ve heard it put. (And she had a lovely Australian / mixed-European accent; so it sounded nicer when she said it.) I can’t overstate the difference you feel when you work on a team of people who care – about the work they’re doing, about the systems they’re building, the impact on the users, all of it. You get those people together, with the proper support, and it’s amazing what can be accomplished, what problems they can solve.
Another aspect of this is that it’s so, so important to have people on the team who are motivated to solve this problem.
A team of motivated people can produce a beautiful, functional system, but there’s no guarantee that it will actually solve the problems that the business needs solved. Our designers and developers work closely with business experts, and we think it’s critically important for everyone on the team to understand the value behind what they’re building, why it matters to the business, the strategic goals we’re supporting, etc. We think that shared understanding is essential to the success of projects, but the truth is that it’s also fundamentally limited.
We’ll never understand a business as well as someone who has lived and breathed it the last 20 years. We won’t instinctively understand how the business is evolving rapidly and how features that sounded good a year ago might no longer be relevant.
The best way I know to remedy this is to have an engaged product owner who understands the business landscape and is motivated to see the software succeed – because it solves real problems they have right now.
Support
Support can mean a lot of things. It can mean ensuring we have a team of people with the requisite skills, access to the right information and the right hardware, software, etc.
It also means less tangible things like having adequate time to explore the problem space or providing a culture with the psychological safety to admit mistakes or acknowledge when you don’t have the answer.
Supporting someone is ultimately about building a relationship with them and getting to know them as an individual, what they need, and how they work best. That requires vulnerability and trust. So I love that they explicitly included trust in this principle.
Trust
What’s interesting here is that they’re not saying, “trust them to be experts.” They’re saying, “trust them to get the job done.”
Those are different things. Trusting them to get the job done means trusting them to know when to ask for help, when to raise a flag that there’s a problem they can’t solve. This can be a really delicate balance in my experience.
The exact same question can be supportive or micromanaging, depending on the context.
That context largely depends on trust and your relationship. Imagine I ask someone on my team, “Hey, I noticed you’re still working on that quarterly report logic. Why is that taking so long?”
I’ve worked with them for years and we have a relationship of mutual respect and trust, they know I’m asking to check if they want help, if we need to budget more time or see if we can simplify some piece, etc. I’m not judging. I know they’re good at their job. I’m trying to support them, give them an easy opportunity to seek help. Even amazing developers and designers forget they can ask for help. I certainly forget that all the time.
However, if I ask a new teammate that same question, it could easily come across as me trying to second-guess how they’re working, a criticism. It’s because we don’t have a relationship yet, and in reality, I wouldn’t ask the question like that to them. I’d word the question more carefully to make my intent clearer, which would take more mental effort.
Building trust takes time, but it’s one of the biggest project accelerators nobody talks about. Trust creates empowerment, which is the key to creating effective product teams.
Empowerment Is Scary
I haven’t read everything out there on the Agile principles, but I’ve read a lot. I don’t remember much being written about this principle. It’s vitally important, but as I mentioned at the start, I think it gets less attention because it feels less revolutionary on the surface. Of course we need to build teams of good folks and support them, yadda yadda. Virtually everyone would agree with that, but when you dig into what trust and support actually mean, things get more complicated.
If we’re empowering the expert practitioners, whom are we disempowering?
That ultimately gets to one of the most important ideas underlying the Agile rebellion: Trusting and supporting the expert practitioners implies a shift of power away from the managers and process gatekeepers.
That is a scary notion for business executives, who understandably seek repeatable processes, centralized control, and predictable outcomes. It’s scary to think that the things you seek could be part of the problem; the very tools that help you run your business can jeopardize success in software projects.
That was absolutely a revolutionary idea 20 years ago. It still is.
What do you think? Am I interpreting this the way Beck, Fowler, et al., meant it?
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
