Four skills to embody the four Agile values

If you’re familiar with the Agile Manifesto, you’re familiar with its four values:

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

Recently this made me wonder: how do you apply these values? How do you live them? What skills do you need to embody them? In this post I won’t be sharing any definitive or complete answers, but as a starting point I have identified four skills needed to embody the four Agile values.

What do Scrum and XP say about this?

As a first step, I decided to look at how Scrum and XP1 approach this problem - even though they have their own different sets of values2.

The Scrum Guide says in its section about Scrum Values:

“Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.”

Followed by two paragraphs describing what that would look like. It never gets specific, though, with the explanation of “commitment” for example being “The Scrum Team commits to achieving its goals and to supporting each other.”

“Extreme Programming Explained (2nd ed.)” has the following to say in chapter 3 about its values and practices3:

“Values are the large-scale criteria we use to judge what we see, think, and do.”

“Practices are evidence of values. Values are expressed at such a high level that I could do just about anything in the name of a value.”

“Just as values bring purpose to practices, practices bring accountability to values. [Because others can clearly see if you are following a practice or not.]”

Unfortunately, neither Scrum or XP provided me with what I was looking for. Both of them recognize for example courage as a value, but provide no guidance on how to be courageous4. And that’s the thing I’m curious about, although with respect to the values of the Agile Manifesto. What skills do I need to value individuals and interactions over processes and tools? How should my mind work? How can I practice the skill(s) that will allow me to bring that value to life?

This left me to my own devices. After some thought I came up with the following four skills to support embodying the four Agile values:

  • Choosing to perform interpretive labor
  • Detaching
  • Daring greatly
  • Flowing with the go

Choosing to perform interpretive labor

In “The Utopia of Rules” David Graeber writes5:

“Most of us are capable of getting a superficial sense of what others are thinking or feeling just by observing their tone of voice, or body language - it’s usually not hard to get a sense of people’s immediate intentions and motives, but going beyond the superficial often takes a great deal of work. Much of the everyday business of social life, in fact, consists in trying to decipher others’ motives and perceptions. Let us call this “interpretive labor”. One might say, those relying on the fear of force are not obliged to engage in a lot of interpretative labor, and thus, generally speaking, they do not.” (p66-67)

That last sentence reminds of the distinction between “Power Over” and “Power With” by Just Associates6 in “Making Change Happen: Power“. Power Over is based on coercion, force, and things worse than that. Power With is about “finding common ground among different interests in order to build collective strength.” Power Over does not require you to perform interpretive labor; Power With does.

In software development we see Power Over in the processes and tools. More so when they are mandated from above, but also still when they were chosen by the team. A process or a tool on its own cannot perform interpretive labor. That requires a human being who chooses to perform that labor, who chooses to interact with other human beings to try to understand them and where they are. So to embody the value of individuals and interactions over processes and tools we need the skill to choose to perform interpretive labor even when we have the option not to.

Detaching

The first chapter of Jocko Willink‘s book “Leadership Strategy and Tactics” covers the topic of detaching:

“[…] - by detaching physically, even if only be a few inches, and, more important, detaching mentally from the problem at hand - I was able to see infinitely more than anyone else in my platoon. And since I was able to see everything, I was able to make a good decision, […]” (p 17)

“The question is, pragmatically, how do you do it?
Step one is to be aware. Pay attention to yourself and what is happening around you. Make it a goal to avoid being fully absorbed in the minute details of any situation. Don’t let it happen. If you are staying aware, checking yourself, you will be likelier to avoid getting tunnel vision.” (p 18)

In “Extreme Ownership” (by Jocko Willink and Leif Babin) this takes the form of the instruction: “Relax, look around, make a call.” (p 161)

Detaching seems to me a crucial skill to be able to apply the value of working software over comprehensive documentation. Taking a step back, seeing the bigger picture, and making the call where to focus efforts next7.

Daring greatly

Brené Brown opens her book “Daring Greatly” by telling us what she means by “daring greatly”:

“When we spend our lives waiting until we’re perfect or bulletproof before we walk into the arena8, we ultimately sacrifice relationships and opportunities that may not be recoverable, we squander our precious time, and we turn our backs on our gifts, those unique contributions that only we can make.

Perfect and bulletproof are deductive, but they don’t exist in the human experience. We must walk into the arena, whatever it may be - a new relationship, an important meeting, our creative process, or a difficult family conversation - with courage and the willingness to engage. Rather than sitting on the sidelines and hurling judgment and advice, we must dare to show up and let ourselves be seen. This is vulnerability. This is daring greatly.” (p 2)

This skill of daring greatly is a great match with the value of customer collaboration over contract negotiation. Contract negotiation is an attempt to be bulletproof, while true collaboration requires vulnerability. We must be willing to allow the customer to have a peek behind the curtain.

Flowing with the go

In the 1995 documentary “Choke”, one of the greats of Brazilian Jiu-Jitsu, Rickson Gracie says:

“You don’t know exactly where you’re going, until the movement happen, because you cannot anticipate what’s gonna happen. You must allow yourself to be in a zero point, in a neutral point and be relax [sic] and connected with the variations. So you pretty much flow with the go.” (1:00 - 1:22)

What this means is that when you’re grappling, you can’t make things happen directly. You’re not in full control, because your opponent has their own plans. They too are trying to win. So going straight for a submission (a joint lock or a choke) is very rarely a good approach. Instead, you flow with your opponent, adapt to what they are doing, exploiting openings to continuously improve your position, i.e. move to a position where you have more/better options9 and your opponent has fewer/worse ones. As you are doing that, opportunities for submissions will present themselves for you to take. As the Brazilian Jiu-Jitsu saying goes: “Position before submission.”

Then Rickson Gracie continues:

“This is a point beyond the knowledge. It is years of [sic] years of playing around, giving you this kind of sensibility.” (1:24 - 1:32)

I include that quote, because what he’s saying here is that “flow with the go” is a skill. It’s something you can learn through practice. And I’m curious if Rickson Gracie (or anyone for that matter) has developed a way of teaching it actively10, instead of solely relying on years and years of playing around.

I think we need a similar skill in software development for responding to change over following a plan.

  1. Although those are the two most well-known Agile methodologies, they are not the only ones. I looked up some of the others, but none seem to list a set of values. DSDM has eight principles. The Crystal family has three properties. Adaptive Software Development does not seem to have any overarching principles or values. It might actually be an interesting research project to look into the distinction between values, principles, and properties across these methodologies.
    (While looking all of this up, I found an this article by Dirk Riehle: “A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other”) ↩

  2. Although Scrum and XP predate the Agile Manifesto, the Scrum Guide only introduced the Scrum Values in Version 5, published July 2016. The first edition (1999) of “Extreme Programming Explained” recognized four values: communication, simplicity, feedback, and courage. The second edition (2004) added the value of respect. ↩

  3. The XP values are communication, simplicity, feedback, courage, and respect. Next to values and practices, XP also identifies 14 principles, which bridge the gap between values and practices. ↩

  4. I suspect a similar problem is at play with “agile mindset”. The agile mindset is a thought process, a set of attitudes, or a culture that you implement with the incentive to accept or adopt the cultural norms. The problem seems to me a Cartesian separation of thinking and doing, where ‘correct’ thinking will lead to correct action. While thinking is also an action, involving intellectual, emotional, ethical, and other skills. ↩

  5. On page 70, he also writes: “Nothing I am saying here is particularly new to anyone familiar with Feminist Standpoint Theory or Critical Race Studies.” And on page 103: “[…], I was actually unaware that most of these ideas has already been developed within feminist standpoint theory. That theory itself has been so marginalized I was only vaguely aware of it.” ↩

  6. The social activist angle of Agile has been labeled as “Team-Scale Anarcho-Syndicalism” by Brian Marick in his talk “Artisanal Retro-Futurism Team-Scale Anarcho-Syndicalism“. In a blog post on the same topic, he writes: “Anarcho-syndicalism’s concentration on the self-organization and solidarity of the people whose hands and minds make the product is reminiscent of Agile at its best.” and “We are also taken by anarcho-syndicalism’s emphasis on direct action.” ↩

  7. Perhaps I’ve interpreted this value a little too broadly. On the other hand, I’m also reminded of what Alistair Cockburn wrote in “Agile Software Development” about The Cooperative Game Principle: “Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game. The next game may be to alter or replace the system or to create a neighbouring system.” (p 31)
    Writing documentation is an important part of setting up for the next game. Detaching is an important skill to decide when to focus on which of the two goals of software development. ↩

  8. A reference to Theodore Roosevelt’s speech “Citizenship in a Republic“, popularly known as “The Man in the Arena”, from which she quotes on the previous page. ↩

  9. I wrote something similar for the last paragraph of my post “Thinking about quality: so what to do?“:
    “All these aspects I’ve summarized for myself as: managing a network of tensions. You are a node in a network of tensions and you take small steps to influence those tensions towards configurations that align with your hopes, dreams, and intentions, with your horizon. And that game, that art, those skills, are what I think of when I say “Do something small, and do something today.” ↩

  10. I might need to do a follow-up post about skill development based on this post and “An approach to teaching Agile 20 years after the Agile Manifesto“, in which I said:
    “Software development is not an easy problem to solve, let alone teaching the skills that enable you to solve it. But I do believe this approach [noticing - options - principles] has a good chance of helping people to acquire that skill set and to deal confidently and comfortably with whatever situation, team, and organization they find themselves in.” ↩