Thinking Agile: Core Beliefs
If you are going to do TPS you must do it all the way. You also need to change the way you think. You need to change how you look at things.
Taiichi Ohno — architect of the Toyota Production System (TPS)
In an earlier post, I argued that Agile = Culture; later, I delved more deeply into theories of culture. aiming to move beyond classification models of culture that group or describe different types of culture to talk about what culture is. In that, I introduced one of the better-known models of culture from Edgar Schein who argued that culture made up of artefacts and behaviours (what we do), espoused values (what we say), and tacit assumptions (what we think). I want to focus on assumptions: the essential beliefs of a culture, the things we think are true. For Schein, these assumptions are tacit: they exist without being articulated or, in many cases, without conscious knowledge. These underlying beliefs are things we hold to be true and they serve to both help us decide how to act, to analyse and interpret actions (our own and others).
These underlying beliefs are the essence of any culture. Agile is described as simple to understand and difficult to master. Through Schein’s model, the reason for this becomes clear: we can implement Agile practices (Shein’s artefacts); we can articulate the principles and values of Agile (espoused values). The difficulty lies in the tacit assumptions: the beliefs that sit under the practices and principles. For Agile to work, we need to understand these underlying beliefs and align them with Agile. That’s very difficult.
In this post, I want to explore the first part of shifting how we think: to understand the core beliefs that underlie Agile.
The Core Beliefs of Agile
The Agile Manifesto and Agile Principles provide a describe a mix of behaviours and espoused values and beliefs for an Agile team. These can be further distilled to find the essential, often tacit beliefs that underpin Agile — sometimes called the Agile Mindset or beliefs. Other, related domains provide similar models — including high-performing teams, DevOps Culture, The Toyota Way, high-reliability organisations, motivation theory, Google’s Project Aristotle, and Deming’s 14 Points. Drawing all this together, there are five essential beliefs: things that are held to be true across all these different domains and need to be true for a successful Agile operation.
- People are Motivated to Perform
- Teams lead to Collaborative and Collective Working
- Focus on Delivering Value
- Attention to Quality and Reliability
- Continuous Improvement and Emergent Solutions
People are Motivated to Perform
Ideas about individuals form the first Agile Belief: people are motivated to perform. One of the major findings from Google’s Project Aristotle is the importance of psychological safety: the team should be able to take risks and admit mistakes without fear or embarrassment or punishment — echoed in the State of DevOps reports, the Toyota Way, and Demming’s 14 principles. Trusting and respecting staff, providing psychological safety, and empowering them to get on with the job is fundamental to Lean and Agile. The importance of the ideas of psychological safety, empowerment, and trust rests on the foundational belief: people in the organisation want to work and want to do well at their job and for their organisation.
This belief is perhaps best encapsulated by Douglas McGregor’s Theory Y — which I briefly introduced in an earlier post. A “Theory Y” manager assumes that individuals consider work a satisfying and fulfilling activity and will work on their own initiative. Staff will seek and accept responsibility for and ownership of their work; they will want to solve work problems, drawing on their creativity and imagination. This means that staff want to be actively involved in decision making about their work.
Teams lead to Collaborative and Collective Work
Perhaps the most obvious Agile Belief is the role of the team. Agile and Lean approaches have the team — specifically, small teams — as the essential unit of organisation. The belief is not actually in the teams themselves, but that collaborative and collective work is key to creativity and problem-solving. Teams are the means to achieving that collaborative environment.
A research programme at Wharton School of Management looked at teams and team performance. One area they investigated was the team size: it was already established that as teams grow, the marginal contribution of each team member diminishes. They found that the optimal size for teams depends on the nature of the tasks and the work: for complex tasks, the optimal size is 5 or 6 people. This size encourages direct communication between all team members and encourages transparency and shared responsibility within the team — which fosters collaborative and collective working.
Six is a small number and many operations need more than 6 people — be it writing complex software, designing and building cars, or running a hospital. So we need to scale from the small team to the larger operation. With Agile and Lean the small team is the primary unit of production, organisation, and responsibility. Larger organisations are created through more teams, not by having larger teams.
Focus on Value
The third essential belief is that the Agile Team exists to deliver value. This is often framed as a focus on the customer and solving the customer’s problems, but it can equally be framed as delivering value for the business — a slightly broader definition where value can be delivered to customers, users, or other stakeholders. This is, superficially, the easiest Agile Belief to defend: most people in most operations want to deliver value. Most managers and executives would be thrilled to see their teams helping customers by solving their problems — until they start doing it. A real focus on value means that everyone in the business is focused on delivering value. With a top-down process, there is a very real risk that value is defined by those at the top, while those below the top have other interests.
One of the first major corporations to be well-known for focusing on customers was Scandanavian Airline Systems (SAS) under Jan Carlzon in the early 1980s. One of Carlzon’s mantras was that the staff did not have to wait for a supervisor’s permission to solve a customer’s problem.
The mantra at SAS sounds a lot like Agile, but for it to be successful it requires the empowerment of staff and flies directly in the face of top-down control or process controls that have been a staple of management since the foundation of modern organisations. A genuine focus on value is a move away from the most widely used model of corporate governance. While many organisations talk about an obsessive focus on value and customers, actually doing it is, unsurprisingly, more difficult.
Attention to Quality and Reliability
In Accelerate — the companion book to the 2018 State of DevOps Report — the authors focus on two major classes of outcome measures: value and quality. Placing quality central to DevOps echoes the obsessive focus in the Toyota Production System with quality, leading to some of the more famous dimensions of the TPS — such as being able to “stop the line” to correct an error. This leads to the fourth foundation belief that underpins Agile and Lean: quality and reliability are essential to success. They are not optional extras, but are core to the success of a Lean operation and must be built into the core practices and values of the operation. Building quality and reliability into the operation from the start and making these the responsibility of everyone is both cheaper and more robust.
The simple explanation, from Deming, for the importance of quality and reliability is that the costs failures are high. The earlier defects and other quality problems are detected the more quickly and cheaply they can be fixed; the cost of delivering poor quality to customers are immeasurable and high. In high-risk environments, the costs of unreliability can be, quite literally, disastrous.
Emergent Solutions: Learning and continuous Improvement
The final belief is that when dealing with complex situations and problems, we are not able to know the ideal solution when we begin. Instead, we should seek to act, learn, and adapt. This is counter to the more traditional, and Taylorist, project management approach where a project or product is analysed and broken down into tasks at the beginning and variance against this breakdown is treated as an aberration to be managed through change control.
The approach advocated by Lean and Agile is built on systems thinking. Among other things, this belief holds that things like software and business operations are dynamic systems — constantly changing over time. Thus up-front analysis quickly becomes obsolete and is a source of waste.
When working with a system, techniques such as Demming’s plan-do-study-adapt (PDSA) cycles, the Lean Start-up’s build-measure-learn, and Chris Argyris’ learning organisations are far more powerful than trying to fully analyse the system at the start of the project.
Rather than trying to find the perfect answer — be it a product or organisational structure — at the start — the emphasis is on learning: getting information and adapting the answer.
What next?
In this post, I’ve attempted to capture the core beliefs that are most important for an Agile operation. You don’t need exactly these beliefs, but an operation attempting to implement Agile will need to confront these ways of thinking: if there are major points of divergence, then Agile is unlikely to succeed. That’s not too suggest every business has to think exactly the same way or operate with the same belief framework. But it does suggest that without these beliefs, any implementation of Agile would require more adaptation and is less likely to realise the benefits of Agile.
On the other hand, if you and your operation are comfortable with something like this way of thinking, what can we do with these beliefs? There are three basic applications that I want to briefly cover: analysis, interpreting other’s actions, and directing actions. These can be applied to both yourself and to the organisation.
Analysis
At its simplest, analysis is asking, “ Are my beliefs consistent with Agile Thinking?” Or, “Does my organisation have a shared set of beliefs that are consistent with Agile Thinking?” For example, do you really believe that (most) people come to work each day (or most days) intending to do a good job? Or do you think that you need to keep an eye on them to make sure? If the latter, then empowering a self-managing team is going to be difficult. Identifying and analysing beliefs is difficult: Schein called them tacit assumptions; things that are subconscious and not readily articulated. They are commonly missed with tools like surveys and are very rarely expressed in formal mission and value statements. I’ll tackle some approaches for eliciting beliefs in a future post.
Speaking for myself, I broadly subscribe to these beliefs, but I’m not perfect: I can always improve! The key here is not for me to demand perfection, but to know my direction of travel.
Interpretation
The second application is to interpret actions: do the actions I am seeing align with Agile Thinking? Does my behaviour reinforce the belief that quality is critical and essential to our business? Or do I sometimes compromise on quality? For the operation, do our policies align with the idea of placing value at the centre of our business — or are we more focused on following rules? The more we can draw a consistent pattern between actions and thinking, the stronger the beliefs will become, which, in turn, will make Agile more effective and shape the Agile transformation.
Action
Finally, these beliefs can help guide action: to help us decide what to do. One of the curious things about beliefs is they both guide action and are shaped by the same actions: in a very real sense, beliefs can become self-fulfilling prophecies. By acting in accordance with these beliefs, we can help to create and reinforce them within the operation.
As a brief digression: one of the mechanisms through which actions change beliefs is cognitive dissonance. We are motivated to have consistency between our beliefs, values, and actions. If we consistently behave in certain ways, our beliefs can start to align with our actions. The process is complex — and we can resolve the dissonance in other ways (e.g. I’m doing it because I have to, not because I really believe it) — but it is a powerful mechanism to use as part of transformation.
In this post, I’ve outlined a set of beliefs that are essential for Agile Thinking. The core practices of the various Agile frameworks and the values that are espoused in the different Agile approaches work if certain underlying things are true. Empowering a team makes sense if the individuals in the team are intrinsically motivated to do a good job and teams foster collaboration. If we want a successful Agile Transformation and want to realise the benefits of Agile, then we need to confront these beliefs and make sure they’re really true in our operation.
