The Heart, Mind, and Tactics of Agile

At the Scrum Gathering in Atlanta this week, my friend Petri Heiramo (@pheiramo) and I were discussing the different agile frameworks, how they were similar and how they were different, and which parts of those frameworks were most important to success. The conversation included lots of sketches on napkins, revisions, and iterations. Eventually we worked out together what we think is a pretty good way of thinking about what Agile is, how the different agile frameworks are similar, how they are different, and how to decide which parts to try in which situations. This blog post clarifies my thoughts based on those notes. We’ll look at Agile in three ways, what we call the Heart of Agile, the Mind of Agile, and the Tactics of Agile.

The Heart of Agile

At the heart of agile are the values and principles of the Agile Manifesto. The first Agile value is first for a reason: we value Individuals and Interactions over Processes and Tools. Individuals and Interactions, especially individuals interacting in teams, are the true heart of agility. When we combine people & teams with the other values, working software, customer collaboration, and responding to change, we get a sense for the culture that exists in agile organizations – Agile cultures focus great teams on collaborating with eachother and customers to deliver working software, and they do it with fast feedback loops (responding to change).



The Mind of Agile

The mind of agile refers to the empirical control frameworks commonly utilized in agile cultures. These frameworks place simple constraints on self-organizing systems. Two of the most common frameworks are Scrum, which is an iteration based framework, and Kanban, which is a flow based framework. These two frameworks have a lot in common. Their core difference is where the constraint is placed. In an iteration based framework, the primary constraint is the timebox – the self organizing system responds to this constraint, with the desired outcome of providing frequent opportunities to inspect and adapt. In a flow based framework like kanban, the timebox constraint is replaced with limited Work In Progress (WIP). The desired outcome of limiting WIP is increased flow and visibility of the system. When we boil these two systems down to their basic components, we see something like this illustration:


In the iteration based control framework on top, the key elements are a prioritized list of work items, the timeboxed iteration, working software at the end of each sprint, a cross-functional, self-organizing team, and the product and system feedback loops.

In the flow based control framework below, most portions of the system remain the same, but the main constraint shifts from the iteration to limited WIP. Cross-functional, self-organizing teams are not explicitly described in the literature of flow-based systems. However, in an agile flow-based system the team will still be a key aspect.

Notice that in the iteration-based system, we have not specified a Product Owner or a Scrum Master. These roles are specific to scrum, which is only one instance of an iteration based control framework. Scrum uses these roles as a means of successfully achieving the other characteristics of the system. The Product Owner is responsible for creating a high-quality prioritized list and effective product feedback loops. The Scrum Master is responsible for ensuring high quality system feedback loops are in place and are driving continuous improvement.

These control frameworks are the brains of agile – the science of empirical process control and self-reflective systems.

Uniting Heart and Mind

If you’ll forgive a quick sports analogy, i think it helps illustrate the importance of having both the heart and mind united. I’m a big basketball fan, and my favorite player, Steve Nash, is defying the common understanding of what an elite athlete can do as they age.  Nash is 38 years old, a veritable senior citizen in professional basketball terms, but he just completed a season with similar statistics to his two MVP seasons when he was in his basketball prime of 32-33 years old. Steve attributes his longevity to improved science in nutrition and fitness.

Of course, just knowing the science isn’t enough. Steve Nash is acknowledged by other players as a real “gym rat”, which in the circles of professional athletes is high praise, meaning he is extremely disciplined, his heart is really in it. The same goes for his diet – players often come to Phoenix based on their record of rehabilitating older players’ bodies (basketball fans will note the resurgence of players such as Grant Hill, Shaquille O’Neal, and Michael Redd). Most of the credit for this success is given to the training staff, but players often cite the example of Steve Nash as motivating them to eat healthy and take care of their bodies.

I, on the other hand, am no Steve Nash. In so, so many ways :-). Though I’m a few months younger than he is, and though I have access to the same science regarding nutrition and exercise, my results in this area are only marginally short of depressing – sometimes I’m pretty good at nutrition and exercise, most times, less so. Having the knowledge is not very useful without applying it. Application comes when your heart is really in it. When you establish habits about how you act, a positive system of reinforcement can start to cause us to see ourselves as “the type of person that eats well and exercises”. It starts to become who we are, not just what we do. When we have the same thing happen in teams or organizations, we call it their  culture.

Having the heart without the knowledge is a little better than the reverse. Athletes were performing well long before the current nutrition and exercise science was available. No athlete today, however, would be competitive ignoring the science. It is why records are continually broken. Having heart is key, and alone can product good results. When we have a united heart and mind we see GREAT results.

The Tactics of Agile

There are a myriad of agile tactics: Daily scrums meetings, Test Driven Development, Continuous Integration, User Stories, Sprint Retrospectives, Backlog Refinement, Scrum Masters, Story Maps, and Pair Programming, are just some of the examples of the many agile tactics out there. These tactics evolve over time, we use the ones that work best in our situation, try new ones to solve specific problems, and inspect and adapt. However, just using these tactics is not the same as “being agile”. The tactics are the least important aspect of agile. Lots of teams start with the tactics, without looking to where they spring from – the agile values, principles, and frameworks. That’s ok, sometimes practicing the tactics teaches us the value of the frameworks, which starts to teach us more about the values.

What do you think – are you stuck in pure tactics without getting the real heart of agile? If so, go back to the core (the cour, or heart) of Agile: Customers, Teams, Collaboration, and Fast Feedback. Look to improve the heart, and the mind and tactics will often follow.

2 Responses to The Heart, Mind, and Tactics of Agile

  1. Chandan says:

    Well written, and nice read to start my morning!

    I’ve been part of many scrum teams while working on various projects. When i look back and try to see in the light of your article, it appears that the organizations often use “tactics” so that their “mind” remain focussed and, as is the case, “heart” takes backseat. There is common misunderstanding that “Being Agile is using the tactics” and thats why tactics start getting unnecessary focus and importance.

    Now it appears to me that they always miss the theme, i.e. “go back to the core”.

  2. Cedric says:

    I think this hits the general problem on the head. The problem or misconception that having the tactics or tools in place is all you need get things done. Not just limited to the use of Agile methodologies but in any industry, really. Becoming true to your purpose is the best way to build a culture of creativity, agility, or productivity where using the tools will lead to higher quality products. Having tools to practice agility is one thing but having people committed to the goal and providing the right tools, agility can be realized (a product manager’s/dev manager’s dream).