Stop trying to make agile development too lean

People often use the terms agile and lean interchangeably, as if they are the same thing. They are not. Others assume that if you are doing one then you are doing the other. This is partly true, although they are quite different concepts that come from different sources. While applying lean principles to agile development is well intentioned, pushing that too hard will reduce the adaptiveness we expect by adopting agile practices in the first place.

Firstly, let me say there are many overlaps between lean and agile values and principles. For example: building in quality, keeping things simple, promoting collaboration, delivering fast, and so forth. They are definitely complementary concepts, but they are not identical (hence the apples and orange image). If we are mindful in how we apply them, we can leverage the differences to strengthen what we are doing. Otherwise we risk undermining their strengths.

In this post, I want to highlight differences in three areas: organisation culture, breadth of focus, and attitude to waste.

Organisation culture

Firstly, in what organisation culture are we looking to apply lean or agile principles and practices?

Organisation culture reflects our shared values and behaviours, and is pretty complex. The Schneider culture model is a handy 2×2 grid that helps reduce the complexities of organisation culture to two dimensions and four categories:

• The horizontal x-axis represents whether the organisation is focused more on people or on outcomes.
• The vertical y-axis represents whether the organisation is focused more on the problems of today or on the opportunities of tomorrow.

Schneider labelled the four quadrants that result: control, competence, collaboration, and cultivation. This is epitomised by the taglines of each: “we succeed by keeping control“, “we succeed by being the best we can be“, “we succeed by working together“, and “we succeed by growing our people to fulfil their potential“. In this context, lean approaches are centered in the right-hand control quadrant; while agile approaches are spread across the left-hand collaboration and cultivation quadrants.

From a cultural perspective, you can see that if we push too hard for control, we draw focus away from collaboration … and vice versa. However, knowing what culture we are working within can help us design organisational interfaces, so that if the nature of our work is exploratory (i.e., agile) but we are working in a control-based industry (e.g., finance), then we expose sufficient control style metrics and levers to the organisation while protecting the delivery teams from too much direct control like micro-management.

Breadth of focus

What is our breadth of focus? Are we thinking and acting in a big-picture broad-focused manner or in a detailed tight-focused manner?

Applying lean principles to how we think about our work naturally draws us to systems thinking, holistically identifying end-to-end value streams across the whole organisation, and how any change affects the overall system. Applying agile principles, on the other hand, naturally draws us to progressively breaking our work down into small enough elements that we can discreetly build and deploy incrementally in short blocks of time.

From a focus perspective, you can see that it is would be hard to maintain both at the same time. If we are focused on the small scale, we struggle to see the big picture, to “see the wood for the trees“.

However, it is possible to achieve this by separating the concerns, with some people focused on the system and providing guidance to those working at the detailed level. This is why scaled frameworks often employ agile practices (like Scrum and XP) in delivery teams, and lean practices at higher levels of abstraction.

Attitude to waste

At a high level, agile practices seek to manage work through limiting batch sizes while lean practices seek to manage work through limiting work-in-progress.

Put simply, agile practices evolved out of the challenges of large-batch plan-driven software development. They are therefore predicated on producing small batches of work that we ship quickly, building out the whole product incrementally. In adopting this approach we acknowledge and expect a degree of waste. Because we are seeking feedback, there may be some ideas we build and then later throw away if the customer does not like them (edit: arguably not waste, as we’ve learned something). Because we ship to strict deadlines,  we make take some shortcuts in development and then later refactor to improve quality. Because we define work at an abstract level and confirm it through conversation while we are working on it, our sizing (estimates) may be out by a factor of three to five, meaning we are unable to complete the work or have to ship less than we planned.

Lean practices, on the other hand, evolved out of the challenges of large-scale manufacturing. They are therefore predicated on handling high volumes of work and minimising the amount of variability. As opposed to agile practices, which (to paraphrase) are focused on low volumes of work and an acceptable level of variability. This variability gives us contingency; that is, if we allow for variability, then we are are better catering for the unknown.  

However, we can apply a lean attitude to waste while still operating in an agile way. For example:

• While working within the time constraints of sprints, it is good practice for the delivery team to limit work-in-progress by swarming on the higher priority stories, only moving on to the lower priority ones when the first are done.
• We should visualise our work, being transparent about how it is flowing through our teams, and where we have bottlenecks or impediments blocking us.

What happens when you make agile too lean

While the intent is good, it would be a mistake to apply lean principles to agile practices too rigidly, as it reduces our flexibility.

If we attempt to operate agile practices within a strictly controlled environment, we end up having management insisting (for example) that delivery team velocity is the same every sprint (within +/- n points), that we have zero defects out of every deployment, that we deliver every feature we committed to at the start of the quarter. This exerts so much control that delivery teams start to feel like they have no autonomy, that they are just being driven hard.

Unfortunately, misguided implementations of enterprise agile often end up looking like this. I have worked in environments like this, and ended up feeling like the best I could do was to protect the delivery teams from the worst outcomes of this. It is not fun for anybody. Don’t do it.

Being pragmatic

We can, however, get the best of both worlds. Be pragmatic in how we apply lean principles to agile practices:

• Serve our stakeholders in a way that suits their ‘cultural’ needs, if they are control-minded let them view what we are doing in a way that suits that … but don’t undermine how we work.
• Separate concerns so that our delivery teams can focus on delivering, while we can have others focusing on how to manage constraints and choices between portfolios.
• Apply just enough controls so that we avoid waste while we still have enough variability to “maintain a constant pace indefinitely“.