Technical agility vs. business agility

In this post, I discuss agility in more general terms than thinking about any specific framework. My aim is to highlight the overarching purpose of agility for businesses as a whole as opposed to concentrating at the team level as I have seen so often.

I see a clear and strong relationship between agility at the team level — what I call technical agility — and within the wider organisation — what I see as business agility. Although agile encompasses both elements, I believe it is beneficial to talk about both as aspects separately because in my mind they speak to different audiences.

The aspect business agility is more relevant to the challenges of senior leaders and businesses as a whole, it will often make more sense to them than the intricacies of Scrum ceremonies, burndown charts, story points and Cumulative Flow Diagrams. However, both are really two sides of the same coin. To truly reap all of the benefits agility can achieve both aspects need to work in tandem — as it has always been understood by the most successful proponents of agility.

Setting the scene

Agile techniques have now been around for quite a while, the Agile Manifesto was created in January 2001, Extreme Programming (XP) in 1996, Scrum was mentioned first in 1986 (though the presentation by Jeff Sutherland and Ken Schwaber at OOPSLA’95 is more famous) and Lean manufacturing which provides the fundamental learnings on Flow was initially developed by Taiichi Ohno at Toyota between 1948 and 1975 (this includes the foundations of Kanban).

In 2012 it was proposed that agile was already mainstream or not — for me a clear sign that agile was entering the Early Majority at the time.

Since then agile frameworks like Scrum and Kanban have been revolutionising how software is delivered and many organisations now make use of both, as well as adopting practices originally from XP and Lean.

However, there are still many that struggle with the adoption or do not reap the expected benefits.

This might be partly because laggards (no technology adoption lifecycle)are now getting on the train too. On the other hand, maybe the reasons for going agile are sometimes not the right ones and the expectations are not always set right, especially for senior stakeholders, e.g. Jeff Sutherland claims agile lets you do Twice the Work in Half the Time — a very catchy phrase that people remember. However, there is criticism for that statement in the community and even if it’s achievable I am still not sure if simply doing more is setting the right goal.

Technical agility

From the perspective of teams agile techniques often just make sense but in my experience in particular the promises of empowerment and self-organisation provide a powerful pull. Personally, when I started my journey, the reduction of requirements documentation, the focus on communication in the team and the general removal of wasteful activities, e.g. around project reporting and status meetings, were appealing.

Knowledge workers (coined by Peter Drucker) have an attitude that still not everyone has grasped: we want to produce something useful that real people love, ideally something beautiful, innovative and ground-breaking. We don’t like to wait, be restricted by siloed structures or red tape that doesn’t make sense. Agile promises the removal of those wastes and teams usually embrace it. They might need help to start trusting the organisation so they dare to act empowered: servant leaders are required. Hence, for teams, there is a clear intrinsic motivation that is often rather simple to explain. That’s why despite the education, support and practice needed I don’t think introducing agility to teams is particularly hard (becoming good at it, is).

Interestingly, when I look at what is achieved by teams adopting agile well, I mostly see strong gains in efficiency, motivation and reliability. Teams achieve the goals they committed to, healthy burn-downs are testament to the team understanding the scope, estimating well and being in control of the delivery process with regards to scope change. Cycle time and WIP are low, the arrival rate is more or less equal to the departure rate and so on.

When I look at what is achieved by teams adopting agile well, I mostly see strong gains in efficiency, motivation and reliability.

What this really means is that the team has become a well-oiled delivery engine, this is what I call technical agility. It’s great to achieve but actually short of what I see as the ultimate goal and is addressed when combining it with what I call business agility.

Getting out most of agility means combining the efficiency of delivery with producing business value.

Business agility

Talking about agility with senior leaders is intriguing, their perspective is very different from that of team members. Of course, they like the positive effects on delivery and team health. The difference in perspective and need becomes apparent when — for example — teams begin arguing about project reports and metrics. Agile teams often don’t want to report in the old ways, i.e. progress tracked against a long-term roadmap, and instead offer to report using velocity and burndown charts. However, senior stakeholders are often puzzled and reject this way of reporting.

And, if I may say, rightly so: velocity is a metric that helps the team in sprint planning but is rather volatile. It is affected when the context changes, e.g. a modification in the team, the business domain or different technologies are used. It is also prone to gaming when teams are pushed to deliver more story points per iteration. Burndown charts highlight problems like over- and under-estimation, scope change, impediments etc. These are mostly problems that should be tackled at the team level.

Another example for a communication mismatch becomes evident when inviting senior leaders to Sprint ceremonies in the spirit of Go and see for yourself (Genchi Genbutsu): The level of detail of some of those ceremonies does not fit senior leader’s needs.

That’s the crux with team-level metrics and ceremonies: they are very useful at the team level but do not answer the questions of senior leaders.

This is why explaining agile frameworks and vocabulary to senior leaders is not sufficient. It needs to become clear for leaders what an agile business is, what opportunities agility represents for them and how it affects their decision making process.

The value-seeking organisation

Interestingly, when searching for business agility I mainly find articles that highlight flexibility or reacting to change. But how do we know we do need to react and what exactly we should be doing? Being able to react fast doesn’t mean we know what to do with the ability. This is exactly at the core of the problem when aiming purely for technical agility: we can deliver efficiently, fast and at high levels of quality, but

How do we know what to deliver?

From a business perspective what we are really interested in is value — real end-user value for which we naturally need to understand our users, their needs (not their wants) and those of potential users and markets. Apart from researching, we also need to change our perspective on producing software products, every single feature we want to build is contained in the (implicit) hypothesis that the feature is providing a certain value to users. We need to realise that we are assuming a feature provides value, an assumption that needs to be tested. Testability is key to learning about our users and our assumptions.

We need to realise that we are assuming a feature provides value, an assumption that needs to be tested.

Hypothesis testing

When we accept that we can be wrong in our assumptions it becomes clear that we need to validate our assumptions — as soon as possible.

When riding my bicycle along a new route I frequently check Google Maps to see if I am going in the right direction. Sometimes, I get it wrong and need to go back and take that other exit from the roundabout (as happened today — see my little detour around Belgravia on the map). No problem when I know after 100m, shame if the Thames appears instead of the National History Museum and I have to go way back (did not happen).

My little cycling detour around Belgravia

In software that check is done by delivering a small feature or set of features — quickly — to real users and monitor their use (or not use) with telemetrics. We can for example use techniques like surveys and user interviews for deeper understanding depending on circumstances. Such monitoring should essentially test our hypothesis which makes it imperative that we define how to test our hypothesis right when we decide to actually build a feature or product (never with hindsight). Sometimes, we go in the wrong direction and need to course correct or pivot. This process is nicely illustrated in the Build-Measure-Learn feedback cycle below.

If decision-makers adopt this stance and formulate a testable hypothesis for feature sets and products versions, they have the best chance to maximise value for users. The technical agility will enable this by going through the Build and Measure steps fast and efficiently. Teams can also advise what specific features can be built particularly fast, suggest alternatives that are easier to test and more.

The technical agility will enable this by going through the Build and Measure steps fast and efficiently.

If Product Owners and teams know the underlying hypothesis that has to be tested they can answer the real questions leaders should have — what business value does this piece of work provide?

Is that not just agile?

Experienced agilists might now say that true agility comprises both, technical and business agility and from my point of view they are right. Looking around we can find that Product Owners are supposed to optimise for value, Sprints in Scrum are supposed to be short, Kanban naturally aims at short cycle times, the much-stated empiricism on which Scrum is supposedly based is all about evidencing experiences and the Build - Measure - Learn cycle is prominent in the Lean Startup movement. For a while now Scrum.org has promoted Evidence Based Management (some good background in Harvard Business Review) giving more focus on business value (evidencing that the focus of Scrum, Kanban and others has not been on business value that strongly and instead concentrated more on team-centric improvements). These are clearly the ingredients for what I was describing so far.

What makes the business value angle challenging (i.e. interesting and rewarding) is that we need to work with senior managers, executives and others that have different needs and due to that a different perspective than teams and middle management. Looking at business value and by that, the alignment of the delivery organisation with the wider organisational strategy brings the two seemingly different worlds together. Senior leaders can then understand how organisational agility helps them to better achieve their goals.

This approach can also help with reporting and improvement goals at the delivery level by aligning typical efficiency metrics, like throughput, to value metrics like ROI, time to market or customer satisfaction. This will probably be a whole new blog post in itself — hopefully coming soon.