OKRs – the latest wave of enthusiasm within the Agile transformational world. This idea was born out of big tech companies and through some decent results and a wave of marketing, has now become the de-facto standard for defining an organisation’s direction with a view to getting people aligned in what they do.
The premise is simple, the concept laudable and the logic sound. However, the benefits are too often stymied when the implementation remains an academic exercise and underlying organisational patterns and behaviours do not change.
Firstly, a super brief explanation of what OKRs are (and aren’t).
OKR stands for Objective and Key Results
The Objective is a goal, something meaningful and ambitious. Critically this is to be an OUTCOME, something that is the consequence of your actions – not the action itself. Pushing eight products to market isn’t an outcome. Having people say yours is the best product, or your product being the market leader, or increasing customer conversion, are outcomes. Those are things you want to happen and can influence, but you can’t force to occur.
Then there are the Key results, these are like milestones on your journey there, things you think should be occurring to inform you that you are making headway into the objective. If market leadership was the objective, then being accepted to speak at four conferences, hiring two hundred new staff and taking a key client from a competitor could be Key Results. OKRs last for months not years and you should have just a few.
The organisation defines a handful of OKRs at the exec level to align purpose and hence priorities through the company with the intention of finishing more, starting less and generating maximum value for the available effort.
OKRs are not KPIs. KPIs are the measures of things that are important, typically always important, whereas an OKR is transitory, it is what is most important right now. The KPIs usually measure output and day to day operations. Maintaining them forms part of the delivery culture, the Definition of Done and as such can be wrapped up inside performance management. They often will have an acceptable threshold, performance is at “X”, capacity is at “Y”, sales conversion is at “Z” etc. Now should one of those KPIs drop below the threshold, then it might be a future Objective to invest to address the issue.
Once the Exec has their OKRs it is common to cascade these down through the organisation. Each team looks at the OKR from the level above and asks – “if that is what is desired, then given our context and sphere of influence, what should we aim to achieve that would help that?” this should also be expressed as an OKR; again with outcomes rather than outputs.
Now within the company we all have OKRs, we all know what needs to happen and everyone prioritises their deliverables accordingly and everything is awesome. Right? Well not always, and it comes down to two big issues.
DATA
We are now in the world of data with focused efforts on its exploitation, and for good reason. We have better capabilities now than ever before to hold, manipulate and intelligently process information for our gain. This is all super exciting and there is now a whole industry to support descriptive, predictive and prescriptive analytics that just wasn’t there ten years ago. However, there is one part of the data lifecycle that is often overlooked and underfunded – that is the capture of the right data in the first place. There is so much data available from our delivery management systems, our logistics systems and our sales systems that we often fail to ask, “Is this the right data?”
What we measure matters, because all too often, we don’t measure what matters.
Now we go back to the OKR, what truly is the measure of success of the outcome you are trying to achieve? Customer satisfaction? Employee Morale, Application Usability? These are common, typically hard to measure and consequently often not measured. Information comes at a cost; you have to invest to get it. The biggest failing I have seen of OKRs is that the information needed to judge success is not being monitored and as a result they are meaningless. Without measuring what actually matters, people fall back on what is measured, which as a consequence starts to matter. So what data do we have? What are we measuring? We are back to outputs. Features delivered, tests run, system performance, generally planned activities done. We have slipped from measuring the problem to measuring the solutions – whilst remaining in the dark as to whether the solutions are the right ones.
OKRs should not be put in place without conscious efforts to capture the data required to measure success. This is often means setting up surveys, regular polling of a pool of known users and external market research.
INCENTIVES
The exec board are probably highly connected to their objectives, those should relate to company performance on which they are judged. The incentive issue arises in the cascading of the OKRs to levels below them who are less clearly tied to the top line objectives.
What often occurs is that each level of the organisation redefines purpose in their unscrutinised OKRs to be the things that they are already doing – and doing because that is how they are measured / gain their bonus. The result is a veneer. An academic exercise to create an impressive sounding soundbite that has no consequence and is soon forgotten.
The OKRs at one level should be approved of and monitored by the level above who meet regularly to assess the outcome metrics of the teams beneath them. This will ensure that systemic focus remains supportive of the top line objective. If it is possible for a team to just adopt the higher level OKR as it stands, then they should do so, this will result in the strongest alignment between team delivery and organisational purpose. When a Key result is achieved then there needs to be significant celebration of success – in a manner that puts the delivery of the output that achieved it in the shade. Celebrate what you achieve over what you do.
If you want OKRs to actually change the way your business works then creating them at the top line is not sufficient, the following additional steps will need to take place, and these require effort.
Measure the problem not the solution. Ensure that you have active meaningful metrics on the outcomes you are trying to achieve – often these will not be able to be extracted from SAP or Jira.
Ensure that the cascading OKRs are agreed down the company and regularly assessed to ensure that progress is being made against purpose.
Celebrate outcome achievement more than output delivery
Enterprise Agility is not about backlogs and scrums. Enterprise Agility is not about processes or practices. Thought leaders and conference speakers will talk in reverent tones about Mindsets, Culture and Values, which are all important aspects but are easier to pontificate on than actually do anything about.
Enterprise Agility is really about being better, and that “Agility” word really means an empirical approach in the face of a VUCA environment – and when it comes to corporate operations they are almost the definition of Volatile, Uncertain, Complex and Ambiguous environments. Really what we are talking about here is ENTERPRISE IMPROVEMENT – and that is something readily understandable and desirable to all levels of a company.
Improvement is a very different concept to a description of an idealised state. Many organisations will sell the utopian state of an organisation. A place where throngs of passionate employees collaborate to deliver high revenue driving products or services, supported by cutting age technology, that are loved by their customers. There are plenty of frameworks that will lay out exactly how this will function, how the teams are structured, how the work flows, how the engineering standards are specified and more. This is all wonderful and makes for great sales materials, but it is also an aspirational fiction. Organisations don’t need help to understand what the vision should be, or what a “best in class” delivery function looks like – they likely already know. What they really want and where they need help, is much more mundane. “How can I improve, what path should I take?”
To answer this critical question there needs to be a switch to focus on WHERE WE ARE and the IMMEDIATE STEPS to improvement, rather than on defining an unrealistic unachievable future state. One thing I have observed from the most powerful and successful companies in the world is that they all have a ruthless and effective attitude towards self improvement.
To quote someone of pedigree:
“The important thing is not your process. The important thing is the process for improving your process” Henrik Kniberg
Given that this improvement is where we should invest, the approach that is to be taken is much more akin to a coaching enterprise Kanban than a more expected consulting “fait accompli” style.
If this resonates and you are in the crosshairs of needing that transformation to materialise, then here are some critical first steps to take:
Self Assess
Measure the current state and be public about these measures – giving you a lever to align efforts and to justify the celebration of success. The atmosphere in the company will open up giving options and ideas for improvement with collective ownership, avoiding the otherwise inevitable resistance that comes with top down imposition of change.
Having organisation level metrics will ensure that the changes that are made are holistic, avoiding localised optimisation which feels progressive at the time, but drives siloes and systemic dysfunction
No Sacred Cows
Be hard on the current situation. “What got you here, won’t get you there…” The processes, policies and behaviours that currently exist were all created for rational reasons, but it is often the case that those reasons no longer apply. It used to be illegal for taxis not to carry hay so as to ensure the welfare of the horses, but the horses vanished long before the law did. Undesirable consequences come when people become responsible for the execution of process, rather than the benefits that those processes deliver. People in these situations often look to preserve those processes long after their benefits have vanished because they provide purpose and career security. A move to betterment will challenge the underlying assumptions of existing processes and practices to ensure that the benefits justify the overhead. If the people involved become invested in the benefits, those antiquated processes and practices will soon be discarded.
Conscious Ignorance
Ignorance is such a powerful word, loaded with judgement. Yet there is so much that is unknown and so much that be said to be unknowable up front. We should not be ashamed about this. I am ignorant on eighteenth century Mexican history, there is no shame in that, I can’t know everything. To make out that I do, or to expect others to, is deeply unhelpful and prevents us from learning. To learn we first have to accept a degree of conscious ignorance and then a sense of curiosity.
More subtle is to accept that I could be wrong, to appreciate that while I have knowledge or understanding, it could be flawed or incomplete – without this we are unwilling to accommodate any opinions that do not align with ours.
To embrace continuous improvement we must accept that our world is complex and networked, that the changes that are made will have imprecise desired impact but also unpredictable consequences elsewhere. For example when jumping into water of unknown depth, the wise approach is not to jump from a great height. When the change is made, make it small enough to be able to manage the unknowns that are going to arise.
The challenge is not how to be right, but how to cope with being wrong – because we are wrong…
Change is the new normal.
The natural laws of entropy will erode the efficacy of any fixed approach, human or mechanical. We need to be changing just to stay still, let alone get ahead, so change needs to be seen as the new normal. Once change is commonplace then it is feared less and seen more as an opportunity. It also places the current state as transitory, which means that if there is something deficit about the status quo, then firstly we should change it, and secondly it is easier to put up with in the knowledge it won’t last long.
Accept the debt
Like when buying a house, when we saddle ourselves with debt to get onto the housing ladder, some changes have a degree of short term pain for long term gain. It is nearly unavoidable to make this proverbial omelette without breaking a few eggs. The pain is natural, resistance will be common due to the uncertainty it brings, and that resistance or even just the uncertainty can result in an immediate negative impact before the desired benefits kick in. This is to be expected but increases the importance of really monitoring the consequences of our actions, for should those benefits not materialise, then the change should be reconsidered. The risks taken here will of course be proportional to the scale of the change, so once again it pays to take lots of smaller changes over a single large step.
If your organisation is looking to transform, then following these five concepts will contribute to you starting down that path immediately rather than wasting time talking about a perfect world that is getting no closer.
The Agile Manifesto has been around a while now, although looking at many of the projects labelled Agile you’d be tempted to think nobody has read it. However, even when read, there are plenty of antipatterns in the industry stemming from misapplication of the Manifesto, resulting in rather cavalier behaviours that trend towards an undesirable anarchic state.
The Manifesto contains statements that prioritize focus on one side of four contrasting values, however the Manifesto does not state that the “other side” of the scale is not necessary or intrinsically bad; just that we focus on one side OVER the other. The Manifesto concludes “While there is value in the X…” Too often that has been misinterpreted as “Agile doesn’t include X”, giving rise to the Myth that Agile equals no process, Agile is the Wild West of Delivery….
Agile Manifesto value #1: Individuals and interactions over processes and tools
Just how much process and tooling is suitable?
Like an onion, the outer layer of processes and tooling are the most visible, and hence can be the easiest to adopt, like wearing a costume. That typically leads to a focus on processes and tools over individuals and interactions and is in my experience the single most common failing in attempts of Agile adoption. However – assuming you have avoided this pitfall, what processes and tools are sensible beyond those embedded in the software development system?
Processes
Scrum, and even Kanban, come with their own processes, do we need them? The original concept in Scrum, three roles, four events and three artefacts is a sensible starting point.
Scrum is a framework, and therefore, by definition, is incomplete; so customising it to meet your needs is expected, even necessary. I’d argue that Scrum in a software context without underlying Extreme Programming practices is likely to be a lot less successful than the other way round, but also many teams in any context will also have extra meetings, scheduled backlog refinement being a good example, or their own way to run retrospectives, or organise sprint planning. Many very common Agile concepts are not actually part of Scrum, User Stories, Planning Poker, Kanban Boards, etc., all of these are useful to some teams some of the time, it’s up to the team to decide if it’s right for them.
These concepts are not to be shot down in flames with a cry of “Processes are Evil”. This is due to the fact that in the majority of cases these customisations are ways of working that the team has intentionally adopted to simplify their activities, they might have even made them up. There is a significant difference between an externally defined process forced upon a team and an internally customised one, adopted from within. Rules (and by extension processes) enable action without full understanding, and consequently stifle innovation. Teams should be encouraged to regularly challenge their processes to ensure that they still support activities rather than restrict them. If you are going to have a process, then make sure the team owns it, and therefore is free to change it.
Processes are often the consequence of a lack of relationship. As the personal relationships between people become weaker, then processes are often brought in to compensate. Relationships can be strained either through failing trust or most commonly just due to scale. The growth pain organisations feel is partly a result of the shift from relationship and trust based operations, to one of process based. With good relationships within your team and the people around them, the need for processes is reduced. To establish where processes are necessary, approach the question in reverse and ask where and why the relationships are poor and how to improve them, then when they remain weak could a process help? Could it be that there already is a process and that is inhibiting relationships. One should always look to trust the person before trusting the process.
Unless the whole organisation is Agile minded and relatively small, you are going to need to apply processes at the interfaces of poor relationships. That could be some structured status report into a nameless, faceless (at least from the perspective of a lowly team developer) steering committee, or maybe an agreed set of steps to request the support of an inflexible deployment team.
A consequence of the association between relationships and processes is that those team members that are not fully embedded in teams usually have more processes around their work than those in teams. So Policy Czars might have review sessions, User experience might need their own schedule of work and SLAs to deliver against etc. Again, these aren’t intrinsically bad, but need to be agreed as a compensation for the lack of relationship rather than as an opportunity to reinforce it.
Processes as Common standards
When there are multiple teams working together there will always be some people that work across those teams, either operating above them or with multiples teams at once. These people tend to be fairly senior or specialized and their desire to be able to compare activity across the various teams will be a drive towards standardisation of process and practice. This is entirely reasonable and understandable but should not be taken to extremes.
Any output or practice from a team that is expected to interface with another team should be considered for mutual standardisation between those teams. This ensures that when they pass things from one to another, then there is clear understanding and fewer errors, it also enables the work from those two groups to be more easily aggregated. This is common sense and the errors on the space programme from teams working in metric units, versus those on imperial units is a great example of the risks of not doing so. However, we only want to standardise processes that have this cross-team impact, that contribute towards systemic alignment. There is a temptation to over standardize which is counter productive because it results in a loss of team control, and loss of control is a reduction in empowerment, autonomy and consequently engagement and ultimately performance.
For example, the Definition of Done for a delivery system is something that should be standardised, same for the format that requirements are written in and the syntax of a progress report, as all of these concern interfaces between teams. More team centric artefacts like Team Health Checks, Product Backlog refinement approach, and estimation approach are examples of things that could remain with the team because these are used internally to help themselves.
Tooling
So do we need one of those shiny Agile tracking tools, like JIRA, Version One, Rally or one of the others? Instead of assuming you do, try assuming you don’t and then establish why you do. If a tool is truly needed, specifically what elements of the tool you really need, rather than adopting it blindly wholesale. Distributed teams are usually one of the main drivers of tool use but these tools then risk becoming one of the biggest challenges to team interactions. Most teams, especially in our enforced distributed working era, will need a work tracking tool, but within that tool, stay focused on what you actually need, and try to limit it to that.
This is not to suggest that one should regard all tools with suspicion, with a degree of puritanical arrogance that things are somehow better, purer, without the crutch of tools. The point is to be objective. It is fairly well agreed that for effective Agile software delivery you are going to need some manner of continuous deployment. For example, it is common practice to have a tool to support code reviews and quality checks and many of these continuous deployment activities can now all be integrated into a single suite. These types of tools can be really helpful where the only guidelines are really that tooling should be brought in deliberately due to a defined need, rather than an assumed starting tool kit.
In summary
All teams operating with Agile principles and values are likely to have processes, and an environment without any tools is likely to be quite inefficient. It is a complete Myth that Agile = No process
Ensure that your processes don’t obstruct or disincentivise human relationships
Processes are usually needed to provide a basic framework to show work and to harmonise group time
Own your processes, externally applied processes can be damaging to engagement
Consider all the relationships inside and outside the team. Wherever there are issues – either due to a lack of building trust or maintaining good communications, then consider adding a process
Processes compensate for lack of relationship, only adopt to fill the gap and resist going further as you may reinforce the lack of relationship
Process and Tooling will likely need to be standardised by the teams that use them for interfaces and common standards that affect their collective delivery on the same product or service
The Agile movement was born from the poor consequences of techniques from the industrial revolution being inappropriately applied to complex adaptive systems. Simply put; when faced with an uncertain world, an approach that optimises for feedback and learning has proven to be more successful than one based on upfront knowledge. As a result Agile is all the rage these days and the focus within meetups, conferences, and propositions of top tier consulting firms is no longer whether companies should be Agile, it is how to achieve it.
I’d like to think that the debates between bottom up versus top down for Agile Transformations are largely over, clearly the answer is a mixture of both. But what does this actually mean in practice, and how can we hope to get ahead and learn from others?
In this piece I walk though that while BusinessAgility occurs at the bottom of an organisation, it needs to start at the top and is sustained only though the relentless support of its leadership.
Bottom up transformations create bubbles within the organisation which are extremely difficult to grow and very fragile – you are forever fighting the organisational culture. Top down transformations are either insubstantial or so slow as to fizzle out. Those that are pushed hard run the risk of upsetting the very people they were designed to support.
I advocate that the best approach for transformation is to encourage the organisation to instigate a rapid cycle of purpose and escalation, and I propose the following approach to achieve it.
Start at the top
Align on Direction
Establish Metrics
Pass to the teams to define solutions
Address constraints
Improve to shorten cycle time
This brings about a virtuous cycle of small changes towards a common ideal, raising organisational constraints that leadership continuously resolve.
The challenges of a bottom up approach
This is how most team facing Agile coaches have experienced the world. Assigned to one or more teams, they have worked to instil the correct values and culture in teams to assist them in becoming more self-sufficient and focused. The Agile coach brings a mirror to the team, enabling the team to introspect and improve for the better.
This usually brings great results for the team, the challenge is how to sustain these ways of working now that the team is functioning differently to the rest of the organisation.
The team probably has the following differences:
Their demands on the time of the business stakeholders is higher
Their ability, and likely willingness, to provide long term estimates and date commitments is lower
The team will want to focus their efforts on a pipeline of their own creation in pursuit of a goal rather than taking orders to deliver tasks
The team will want to retain a stable structure and working relationships
These differences build a bubble within the organisation. A section of the company that not just follows slightly different processes and governance, but has a different value set and culture.
As far as the rest of the organisation is concerned, this is something alien; and once identified the host organisation behaves akin to a living system and the antibodies come out to remove the “infection”. For the bubble to persist it requires a senior leader to be able to protect those around them from pressure to revert to the status quo; and this goes one of two ways:
Bottom up result one – the Bubble wins
The leader pushes on and instigates new bubbles with fellow like-minded employees and then moves up, widening their bubble until more of the organisation is inside these bubbles than outside. Now the status quo are these new ways of working and the pressure switches to be on everyone else to fall in line with the new majority. This can happen in small organisations, where the distance from top to bottom in the organisation is relatively small, and moving up to influence higher is possible quickly. In my experience this is a rare occurrence.
Bottom up result two – Stifle and pop
Sadly this is the more common situation. The leader grows the bubble as much as possible but the greater the size, the greater the pressure and eventually the bubble stabilises. The bubble remains under repeated attack and the areas on the edge start to be forced to compromise their new operations. The frustrated leader finds their options limited and to personally progress either moves sideways or leaves it all together. At this point, without the support of their advocate, the bubble bursts. New leadership comes in and in a very short space of time, the previous ways of working are restored.
This is commonly the scenario associated with the introduction of a consultancy that focuses on team delivery and team level ways of working. The Consultancy is able to create and protect a bubble, usually within IT, but can’t get over the organisational silos into the business portfolio management and finance. Success is declared in the bubble they have created and they then leave the organisation whereupon the immune system invades and reverts much of the operations back to how they were.
Craig Larman of LeSS fame sums this up beautifully in his first law of organisational behaviour:
“Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.”
In other words, those people that have built their careers on the existing ways of working will work to preserve the current situation. These people are the antibodies of the organisation rooting out the Agile infection.
The challenges of a Top down approach
The top down approach unsurprisingly removes most of the issues with the bottom up approach but introduces a collection of new ones. Here you clearly have the buy-in of the senior leaders and is usually found where either you have a new senior leader or the existing leadership has had a push (poor results, recent experiences or relationships with consultancy partners). From first impressions this should be more successful, you have the people who have the greatest influence pushing for something, so in theory everyone below should just fall into line and the world becomes a better place…
What commonly happens is that the senior leaders agree on ways of working that they have heard or seen work elsewhere, and look to emulate those within their own organisation. On first impression, this seems really sensible, and people are really working for the best intentions, without subtext or political manoeuvring. However in implementation this approach runs into three common issues.
Top down result one: Agile becomes the goal
The understanding of the Agile values and principles are not truly appreciated and the more practical, tangible processes and tools are what Agile is identified with. These processes and tools are typically things that are used by people at the coal face, and importantly are used in places other than “here” (where the leaders are sitting). In other words this starts to be less about an organisation BEING Agile, and more about specific departments DOING Agile. Whether you are being Agile or not is hard to measure, that is all about opportunity, speed to adapt, workforce engagement etc, all hugely critical but hard to run reports on. Execution of Scrum practices and implementation of aligned tooling though, that is much easier to monitor and track. Slowly the purpose of the transformation slips, from feedback driven customer centricity, to just being able to demonstrate Agile associated practices. The Agile transformation starts to become a project, it becomes the goal rather than a means to an end.
“All of our teams are now using Scrum, every work item in IT is now in Jira. We are Agile, Hurrah!”,
But of course you aren’t. Success is declared relatively quickly, which should be suspicious in itself, because really, nothing has actually changed very much.
Top Down result two: Imposing someone else’s solution
“A friend of mine has a great new electric tin-opener, I saw them use it, was really impressed, so I am going to buy one.” This situation seems fairly reasonable and we have all done something similar at some point in the past. However this only works because the tins being opened are standardised. My friend’s tins are the same design as mine and therefore I will be able to use the device as well as they can. The association between problem and solution is predictable and repeatable. In complexity theory terms this is a mechanical deterministic system, with a good answer that can be repeated anywhere, any time and by anybody.
The issue here is that the ways of working in complex organisations can’t be just lifted and dumped to deliver the same results.
As Dan North put it: Behaviours = (Practices x Context)
The point here is that context is king, and yours will be different from theirs. You can’t take a solution from one complex adaptive system and attempt to replicate it. The ways of working and even organisational structure that exists in one organisation has been optimised from base values and principles to create something unique. If you are looking to emulate their success then it is that emergent continual improvement and their base values and principles that need to be copied, not their end result. You need to find what will work for you, not take the answer to someone else’s problem.
Typically the people on the delivery end of operations can point out the short comings in the suggested ways of working, as to why something might not work well here. The challenge is that the leadership are not looking to encourage values and principles, but more insist on predetermined practices. This is actually deeply anti Agile. These are no longer self-organised teams, but victims of an enterprise wide imposition, now commonly referred to as the Agile Industrial Complex. These enforced new ways of working upset the people doing the work, who are much closer to the issues. Their suggestions are dismissed in favour of this single set of operating processes often collated into an off the shelf standardised playbook of sorts. Ultimately this is likely to lead to a rejection of the new ways of working, reverting back to previous models with the added tag of, “Agile doesn’t work here!”
Top Down result three: Boiling the ocean
There are situations where the leadership is on board and have an understanding that we are looking for a mindset change, something deep and significant that affects the organisation holistically including the leaders themselves. They have made the case that you can’t lift and shift from somewhere else and so what is needed is something carefully crafted, that considers the subtle nuances of their current operations, market and people. In making the case that this is to be holistic… you’ve widened the scope of ambition. The reality of the consequences of the transformation starts to bite. This is going to affect processes, governance and funding, expressions of purpose, organisational design, performance management, technical practices, culture, tooling. Everything is in scope, everything is going to change.
This is now a huge undertaking and a company that is used to traditional waterfall ways of working will see this as the largest project ever attempted, which naturally needs extensive analysis to establish what will work. Before long for the complex nature of the challenge becomes evident, the multifaceted interdependencies between all the constituent elements become problematic. This is the most complex of complex projects; ultimately you end up trying to design an entire organisation from the ground up, starting with organisational structure, which instigates a round of upskilling and recruitment to bridge the gaps between the current and desired states.
This is enormous, and like any complex project will confound the most ardent of project managers whose tools and techniques are designed for deterministic predictable mechanical environments. Ultimately you end up instigating your company’s most critical waterfall project to implement Agile, which is as ludicrous as it sounds. The interdependencies of all the moving parts yields slow theoretical conclusions which are in turn fed into decisions on organisational design which due to their importance will be slow to make. The end result is something that is so large and so slow that it is highly likely to be abandoned.
The Holistic Transformation
What is needed is something that takes the best of both worlds, something that enables that Bottom up “bubble” to grow and be protected, but also something that enables changes to begin so that momentum, rather than inertia, builds.
A holistic transformation is where the Bottom Up and Top Down approaches are mutually supportive bringing a virtual circle of continuous improvement.
To help to understand this path, consider a much simpler situation than your current one, consider just one team, a one team company, just seven people in a room, and they want to improve things. Chances are they will all get together, discuss their challenges, and describe what better will feel like, look like. Then come up with some suggestions, pick one and see how that works out, and then repeat. Pretty simple really.
The challenge organisations have is fundamentally scaling this. The objective is to be able to apply the principles and practices of Kanban at an organisational level. Starting where you are, look to make continuous evolutionary improvements across the board, constantly learning from feedback to find the next issue to resolve. The optimum ideal is to build an adaptive learning organisation.
In my personal experience the best approach is to start at the top, then quickly loop down to try something and pass the feedback up to the top again. And I describe this journey in the following steps:
Start at the top
Align on Direction
Establish Metrics
Pass to the teams to define solutions
Address Constraints
Improve to shorten cycle time
Start at the top
Ideally you want to start at the very top of the organisation, the Exec board. Where you start will determine the size of the bubble of Agility that you create. If you start solely with the IT director, expanding later to make a genuinely Agile organisation, encompassing Product, finance and HR will be very difficult. Starting is the hardest step, starting with all the necessary people and respective departments aligned is extremely difficult as the status quo is highly likely to see these people being incentivised to compete against each other, protecting their siloed departments, their seats of power.
Align on Direction
Before you can help an organisation to realise an Agile transformation, the leaders need to be clear about exactly what this really means. This needs to be clear from a conceptual values based perspective but critically also from a blunt practical perspective. The hidden powerful question “what is in it for me” needs to be answered.
It is important that Agile is not the goal, ensure we are always focusing on “What are we trying to improve”. When a leader states they want the company to be more Agile, ask “Why?”. What is the problem you are trying to solve, and then add to that, “And how are you measuring the problem so we know if what we are doing, is helping?” You can’t really start until you have these pieces in place. You are looking for both autonomy and alignment, unless you have a clear guiding vision from the top, then the activities of the teams underneath will go in all directions and not deliver the desired results. A common problem though is when the senior exec team doesn’t operate as a team. If they are not aligned themselves, how can you expect the rest of the organisation to fall in line? If you suspect that this scenario faces you, then it needs to be addressed immediately. For guidance; Patrick Lenconi’s five dysfunctions of a team deals directly with this topic.
Establish metrics
The measures of “Betterment” expressed as Metrics to the organisation are a corner stone of setting a vision everyone aligns against. It gives a point of unity between all employees in all departments. This is step one in reducing internal rivalry and increasing cooperation between siloes to delivery customer value. These metrics exist at a company level, but when applied throughout the organisation should manifest themselves at every level, at the portfolio, at the team and ultimately to the individual. The question to all employees: “Are YOU living these values?”
To get agreement on what better feels like, start with values, behaviours and culture. It is all too easy to fall into the trap of thinking through solution lenses; just do this or change that. The role of the leaders is to give purpose and inspiration, let the teams or teams of teams solve the problems – they are much closer to the situation. Helping the exec level team to reach this point and acting like a single collective intelligence united in purpose and resolve is a difficult challenge and is why introducing an enterprise level Agile coach is usually a good option. Someone skilled in both group facilitation and personal professional coaching.
Pass to the teams to define solutions
Once you have this guiding direction then the focus starts to switch to the teams, the Top Down intent is passed to the teams below for their Bottom Up solutions.
The challenge posed is this: “Given this is where we are, and those are the values, behaviours, principles that we are looking for, how can we change our activities, our processes and practices?”
The important point here is that the solutions come from the teams, they are empowered to improve their own circumstances, don’t fall into the mistake of trying to solve the problems at the top, that is to impose and disempower.
And just as some enterprise level Agile coaches are a good catalyst for the exec, so experienced team Agile coaches can really help make the difference for teams in figuring out what are some sensible options.
Some teams may want to consider Scrum, others may want to just start with improving their deployment pipeline, or putting some more rigor around prototyping and testing product ideas before delivery. Many of these ideas will be within the control of the team. The easiest adjustments to make will change the way team members work between themselves, not impacting anyone else, and these are probably where they will start – following the path of least resistance.
Escalate constraints
Ideally within just a few weeks those teams should start to notice that their instance of the company’s metrics have ticked up, probably not a lot, but it is a start. Even the longest hikes are still taken one step at a time.
These small improvements are fed back up to senior leaders, more focus from a team, better user testing, incorporating more sustainability in the work, less work in progress. These first pieces of feedback are crucial in keeping the momentum; providing the leaders with the reassurance that they are onto a good thing and in turn, their clear and widespread response to this information emboldens the teams to greater efforts.
The low hanging fruit are soon picked however, and the path to greatness is rarely the easy one. Teams will start to identify constraints to their self improvement that lie outside of their team. Reporting requirements from a central PMO, conflicting demands from multiple departments, team members split between multiple teams. This is the point where the bottom up really meets the top down. These issues can’t be resolved by the team so they are escalated up where systemic solutions are sought. Experiments are discussed with teams and instigated from the exec level to address these issues. The fact that the teams have requested something to be done and are involved in the solutions will give a much higher level of engagement and positivity than would otherwise be the case had management just implemented these changes without consultation.
Improve to shorten cycle time
If you can achieve this, you now have a situation where the entire organisation is proactively moving in the same direction. The first changes will likely be around development practices and processes. Before long attention will turn to the elephant in the room that is the interface between engineering and product and about how we define value; this increases pressure on integrating Product management and design thinking. Ultimately these changes will trigger discussions about organisational design, governance and then financing and performance management.
In summary
Stepping back you will see a cycle of small changes and escalations from the bottom driving a clear purpose and systemic changes from the top, round and round and round again, better and more assured with each cycle. As with all improvement cycles the smaller the batch size the faster the feedback and the easier it is too keep things going, don’t attempt to change too much at once, but what you do change, do it quickly.
If you are serious about enabling business agility, then it isn’t where you are going that is the challenge, it is the path that you take. That journey is long hard and full of unknowns, and the most reliable approach to take in such situations is to instigate a cycle of continuous improvement where both the top and the bottom of the organisation work in a reinforcing harmony towards a clear and common goal.
Comments are welcomed – even criticism. It is only through feedback that we learn.
I was recently invited to contribute a talk to the Agile week hosted by Sainsbury’s. This was a wonderful initiative to share ideas and enthusiasm around their Agile journey supported by internal events and discussions and a few external speakers of high quality and industry renown, of which I was flattered to be in their number.
In the modern world our lives are increasingly busy, short term and digitally driven. We are bombarded by information and multiple demands for attention, however within this maelstrom of data, the things we still seem to value the most are the opposite. We value time, peace, small close human interaction with family and friends. We yearn for nature. We value the soothing sound of gentle waves on sand, the laughter of children or those heart warming yummy noises your friends make on sharing the meal you made for them. This is to conclude that, as humans, we aspire to simplicity.
I shared my thoughts on this with the group from Sainsburys, the beginnings of something I hope to put in more concrete structured terms eventually, whereas right now, although I can hold it for a moment, like rainwater in cupped hands, it drains away.
Broadly the premise is simply this: That hundreds of years ago people largely worked at a learned skill, likely familial, within small communities had a representative set of skills and collectively they were more than the sum of their parts. Typically there was a degree of craft and pride in the delivery of their work, be it farming, carving, furniture making or bread baking. The world was small.
Throughout history there is an ever present theme of the strong exploiting the weak. Landowners exerting as little effort as possible by coercing others to work on their behalf, reaching an extreme with slavery and plantations. It seems there has long been this battle between what is morally right and what is most profitable, where profitable is considered from the perspective of the very few who “Own” the enterprise. The industrial revolution is another excellent example, and is pertinent as it is the tail end of this period that created most of the operational and structural norms that govern businesses today. The Industrial revolution gave birth to the very concept of management.
At the heart of what was happening was the separation between thinking and doing. Thinking was the role of management and the doing was broken down into many pieces so that each operator only had to do something very small, but thousands of times a day to hone that single skill, looking for maximum efficiency. Basically, we turned thousands of people into machines, endlessly repeating a single task, a deeply dehumanising experience.
Fast forward to today, now those smoke belching workhouses have been replaced by efficient assembly lines, with varying degrees of automation from robots and computers. Increasingly employment has shifted toward more creative problem solving domains, more “thinking” work, less of the old school “Doing” work; however some of the silos adopted in that era remain. The principle that all work can be broken down, understood, sized and scheduled to be delivered with certainty for a fixed delivery date, still exists as the norm in many institutions. This may just about still hold true for the few remaining mechanical tasks, where there is little variability in the work, but isn’t, and has never been, true for creative knowledge work.
My entreatment to the audience was not to see our Agile labelled ways of working as something new, a natural evolution of professional progress, but rather a return to a simpler approach, much more aligned to how we naturally would operate in a group of people in a self sustaining community.
The most successful ways of working are optimised for the worker not for the product, and as such we should optimise for the opportunities to express our fundamental humanity. Work that naturally aligns to our human traits such as figuring out problems or creating processes rather than having to follow those foisted upon us will deliver greater results simply because those involved are more emotionally invested in them.
So I ask you, as I asked them, what is the most natural way to address the need you have? Not what does this framework say, or what does that so called expert say…? First, just what is the simplest most logical and ethical thing to do? Try that and then reflect on what transpires, maybe that is sufficient, maybe you’ll need to iterate a few times, but ultimately I believe that this simpler approach will bring better results.
Comments are welcomed – even criticism. It is only through feedback that we learn.
In the light of the Cornonavirus situation organisations need to reconsider WHAT they are doing, not just HOW they are doing it. Just moving people to work from home is to play behind the curve, it assumes that the market that you derive your value from is unchanged – and that just isn’t true any more.
These are strange times, for many of us who are working in the professional services sector, there is a global move to working from home and there are many techniques and tools that are available to us such as Skype, Zoom, Google Hangouts etc. However I want to challenge whether just focusing on those working practices is actually the best course of action.
We know that in complex, human based environments, feedback and learning are essential for progress and the best approach for that is collaborative working that delivers frequently to your customer base. Switching to remote working is going to hinder this, whatever tools you use it will never be quite as good as it could have been face to face. Simply telling staff to work from home is a mitigation strategy that attempts to negate the impact of the change. This is attempting to catch up with a plan, rather than really adapting to the change.
The reason for making this distinction is because I fear many have missed what the change really is. It is easy to see is as: I was working with colleagues interactively in the office, and now I am working in an isolated environment trying to do the same job.
However this isn’t really the change. If you were the only one to be now working from home, then fine, get a crash course in remote working tools to try and do the same job almost as well, but you aren’t. In fact it isn’t just your team that is impacted; it is your company, your competitors and more than that, your customers too. This change is also not for a week, or a month, and it is highly likely that in some areas, things will never completely go back to how they were. This change is HUGE.
The reality is that the norms of human interactions have been turned upside down in a matter of a few weeks. Things that we valued before, like catching up with old friends, have been pushed aside and new things, that we didn’t value much at all, now seem to be essential, like bizarrely, toilet roll. The current approach appears to be: “To change the ways of working while maintaining the same output”. Regardless of how we do it, I would challenge whether the same output is actually what we should be aiming for?
We should remember that it isn’t the fastest or smartest that survive, it is those most adaptive to their environment. There is little benefit in effectively working from home to deliver a new app for cinema listings when nobody is going to the cinema any more.
When confronted with a substantially new scenario we naturally go through a three step process:
1 Assess the situation
2 Evaluate options
3 Implement and learn
Assess the situation
Start by taking a step back, challenge all the assumptions and accept the world has changed. Establish what the new situation is and how this has changed especially from the customer’s perspective. What are their needs NOW? Focus needs to switch to what will deliver value now rather than how to maintain working on what previously was going to deliver value.
I suggest the following actions:
Immediately review portfolios of work and stand down any deliverables that are unlikely to receive the immediate impacts they were predicted to have.
The product development lifecycle to be restarted in as many places as possible. Instigate small discoveries followed by ideation phases to really understand the impact of the changing world on their customers. Typically the ratio of this backlog building product exploration work to technical delivery is proportional to the level of understanding of the market, and as that is changing rapidly, the need for investment in this area has just gone through the roof.
Assess the changes in the use of the products / services that are currently being offered and consider removing or reducing services that have seen a drop-off in use so as to repurpose efforts elsewhere
Evaluate options
Organisations need to go back to their fundamental purpose and look to understand how best they can fulfil that need in the current climate, their options are going to be linked to how impacted that purpose has been. A key question will be that can you fulfil your purpose when your customers are staying at home. Could you, like a restaurant who is in the business of feeding people, instead of expecting people to come to you, go to them? Can you do the equivalent of rigging up a truck with a barista coffee machine and drive along suburban roads like an old fashioned ice-cream van? In a new world where people aren’t encouraged to come to you, waiting for customers to arrive is a dangerous path to take. If you don’t offer you products and services online, but could, then there is no better time to start this than now.
When there truly are no options other than to wait it out and look to mitigate loss, then this may be the perfect time to switch to internal programmes of work rather than maintaining a very high service level to relatively few customers. Cutting staff is a distressing decision to have to make to reduce costs to survive, and I trust that those companies looking to do this have no other choice.
I suggest the following actions:
Look to offer previously face to face services either door to door or over digital channels. It may require the former while the digital channel becomes workable.
Consider the new data that has become important to us, can you access that, can you leverage that? For example if an organisation is delivering financial data to markets, then those markets are probably very interested in new dimensions on companies where data isn’t currently offered, because until recently it wasn’t relevant.
Move transactions and offerings that would previously be in person to online, serviced by the same people that used to do this in person
Ramp up internal work proportional to external customer facing work. Maybe this is the time to upgrade the servers, refactor that codebase, develop the internal training programmes package, or even just refurbish the office (switch bank cashiers to painters – we’ve all done a bit of DIY in our time)
Implement and learn
How organisations deliver against these changing needs given the new constraints placed upon them needs to be considered, and, as mentioned, this is where companies are focusing on remote working tools for example. However the changes needed are larger than this. Organisations that relied on footfall are going to need to reconnect with their customer base. Organisations that rely on teams delivering work are going to have to change how those teams are structured and controlled.
I suggest the following actions:
The typical Amazon “Two pizza team” used to gauge team size is based off an assumption of human interaction that is no longer true. The emotional and bureaucratic cost when everyone is working remotely, rises considerably. Consequently organisations look to reduce their team sizes. I would suggest that teams in the region of four to five are likely to be able to work remotely much more effectively than larger groups.
A centralised organisation that looks to control the actions of its people will struggle due to the reduced effectiveness of communications, the pressure needs to be on how to delegate more. Empower teams that have the necessary information to make the decisions that they need to, and have leadership switch from making decisions, to ensuring decisions are being made.
Arrange regular online or telephone based interaction purely for the purpose of interaction. We are social creatures and our mental health deteriorates when isolated. During a normal working day a large quantity of time is spent just talking to each other, laughing and smiling. These simple human interactions put us in a suitable frame of mind for doing the real work.
In summary, during these uncertain times we all need to be on the front foot about how best to adapt our business strategies and working approaches. To just focus on how to execute the same work as before, but from home, is akin to battening down the hatches in a storm. This is no simple storm, there has never been a storm like this before; what is needed is the ability to learn to thrive in a world of high winds.
When seeking to support an organisation on the journey towards business agility, a more value centric, feedback driven approach, it is all too easy to overlook the reasons behind the resistance shown from some of the people affected. It is often not appreciated that they are a product of the system they have been in, they have been literally taught to be this way. The urge to want to brush them away needs to be resisted, as these people are just as important as those driving the change. If an organisation is looking to change, then it should not be leaving anyone behind. Their only failing is to be upholding the values the organisation gave them, that, until yesterday, were universally appreciated.
It isn’t hard to imagine the situation: you have been brought in to deliver an Agile transformation for an organisation; this is the opportunity you have been looking for and you are feeling positive. The request has come from the top this time, so even the cultural and organisational design issues should be on the table…..
You are working hard with both delivery teams and senior leadership but sometimes it feels like there are forces working against you. Don’t they see that this is a once in a lifetime opportunity to make things better? It seems like there are people who just don’t want to change, don’t want to see delivery being faster, more value centric; people who clearly don’t have the best interests of the organisation at heart and as such, probably should be weeded out. This is to say nothing of the swathes of people who clearly don’t have the suitable skills for working in a fast-paced cross-functional team environment. They are going to need to either adopt a steep learning curve or look for alternative employment where the expectations are lower.
Does this seem vaguely familiar? It is an easy trap to fall into, driven by conviction, a notion of moral righteousness about these ways of workings. We have seen the improvements elsewhere, not just to delivery but more importantly to people. To witness a lacklustre disengaged workforce metaphorically wake up from a foggy malaise and realise their full potential, is a genuinely uplifting experience; and it is what motivates us to continue our efforts. What is awry here is that the transformation isn’t all about US, this isn’t OUR moral crusade. We are enablers, a support function. Ultimately we are trying to make their world better, but not for us, for THEM.
Years ago there was a clear separation between the thinkers and the doers within a company, a small highly skilled group directing the activities of a large workforce of low skilled, and usually replaceable people. In this Taylorist view of the world, people really were a commodity, a resource. As the nature of work morphed into the creative or knowledge domain, then the people delivering the value have became essential to it. Now the purpose of the organisation is typically intrinsic to the people delivering it. The employees are no longer a means to an end, they are not a fungible commodity to be used and exploited. People are not resources. The employees, the people, ARE the organisation.
In this context, when looking to improve an organisation we are really looking to improve it for the employees. If the view on that improvement is that some employees need to be “Weeded out”, or “Lack sufficient skills to remain” then what is being said is that for the best interests of the people, some people need to be removed.
Take a step back from that and repeat it:
For the best interests of the people, some people need to be removed.
If we scale this premise up, to a societal level, then there are examples in history, some which relate to the most abhorrent acts that have ever occurred.
This isn’t to say that in groups there is no need to protect the masses against the destructive acts of the few, this is why we have performance reviews, gross misconduct policies and in a wider societal context, law enforcement and prisons. However, cultural norms are relatively static; the moral codes that govern day-to-day acceptable behaviour change very very slowly. Something which was socially acceptable today will not become repugnant tomorrow, or even next week or month. Within the context of Business Agility there is an attempt to move much much faster.
Systems of people do change, but they change slowly. You may have an opinion on the system, wish to change it and through your actions, usually supported by others, manage to instigate one; but this change will be gradual. People change at the rate that they choose to, not at the rate that others tell them too. The deeper the ideology, the deeper the emotional connection to the principle in question and the slower the change. Just because something is morally “Right” does not mean that people will adopt a new value set overnight, especially not if the RIGHT thing to do, is NOT the EASIEST thing to do. To look to “Weed out” people who do not change to a new value set within weeks or even a few months, is to misunderstand the fundamentals of how we, as humans, accept and adapt to change, and by association could be considered unethical.
To go full circle, when we encounter someone who is resisting or countering moves towards an Agile transformation, instead of looking for ways to go over or through the individual, we should look to understand what is driving their beliefs and actions. It is highly likely that their behaviours are linked to the system that they are in, and have been in for quite some time. Some of the people that will struggle the most are those that have the most invested in the current system, they are the greatest advocates for what WAS valued.
The system they are in has defined their role, their contributions, what is valued and helpful, and what is not. This system has processes within it that may have been in place for years. It is possible that the process has a longer tenure in the organisation than the employees that execute upon it. This person’s career may have been shaped and optimised against the execution of this process and likely their future trajectory planned against it. In this situation, a suggestion to remove the process is catastrophic to that person. You are removing their current purpose, challenging their prior value and removing their opportunities for growth and progression. The skills that they have spent years learning and honing are now redundant, those years of intellectual investment have been potentially wasted. This person deserves empathy not scorn and dismissal. Consider this another way, at some point in the future, it will be our world that is changing, how quickly will we be able to adapt, and how would we wish to be treated?
The capabilities, beliefs and behaviours of people who seem to resist change are a consequence of their participation within the system for years, and to suggest that they will be able to change these as fast as an organisation can change its processes and structures is naïve. The challenge of change towards business agility is ultimately one of culture, and each person within that organisation is a fractal manifestation of that culture. Now you can change processes and policies overnight but it won’t change the culture immediately. This is akin to putting on boots and a Stetson, it might make you look like a cowboy, but it doesn’t mean you are one.
Therefore if the organisation, through the permeation of its culture, has shaped the individual to be what they are today, then it has the moral obligation to help its employees through any change it attempts. For an organisation to “Weed out” people who are not supportive is to punish people for being what the organisation has created them to be.
There will always reach a point when persistent behaviour associated to a prior values will no longer be acceptable. This occurs once the whole organisational culture can be said to have changed, not just the visible elements of it, but the principles and values beneath them. Patience will always run out eventually, but it needs to have been demonstratively shown.
The most extreme situations of resistance I have encountered have been understandably associated to organisational design changes to remove the walls between the traditional siloes of business and technology. People who have status, power and a career path associated to a managerial position within one of these pillars are enormously threatened. A possible path in these situations is to switch the perception of importance and respect to be associated to the ability to influence a decision and to provide support, rather than direct control or line management headcount. For this to work however, it needs to be a widespread cultural value. The individual in question will not self-actualise through these values if their peers around them do not follow suit. This is a great example of why a full shift to business agility needs to involve the whole organisation, not just cherry picked departments, to ensure that the whole management team experiences the same discomfort and adjustments rather than it becoming a game of winners and losers.
The decent approach is to invest in these people and provide them with support and coaching. Someone will need to understand their personal context, opportunities and losses with what is being suggested. Those losses need to be accepted and compensated for. Each affected employee needs to have the opportunity to find purpose and understand the value that they can contribute. Their learning and career path within the organisation will need to be recreated and agreed by both parties. It is the responsibility of the organisation to make the clear case for the change and how the employee fits within the new world. If they fail to understand the drivers behind the change so as to still not support it, then it is as much a failing of the organisation as it is the employee. It is fair to say that none of this will be easy or swift, but then successful systemic change rarely is.
Ultimately this is a question of empathy and responsibility towards the people that organisations have created. If we are in the situation of striving to enable an Agile transformation, what would it take for use to be able to see people as a product of their system and treat them accordingly?
Comments are welcomed – even criticism. It is only through feedback that we learn.
Enterprise wide Business Agility is the latest hot topic in the Agile space, from conferences to meetups. The challenge is how Agile can impact business strategy in the boardroom, to enable the entire organisation to become more adaptive, rather than be constrained to process optimisation in software delivery teams. Terms like OKRs and Impact maps, Outcomes and Outputs, are now the focus of attention. This is a significant step in helping us to rightfully consider Agile more as something you are, the values held; and less in terms of what you do, the practices and tooling used. To many though, these are alien terms and appear as competing ideas, resulting in inertia and a continuity of the annual cycle of feature laden projects delivering to fictitious business cases.
To clarify; all of these topics are various approaches to address the same issue, they all exist to attempt to address the following critical question:
“What is our purpose, and how can we ensure that everything we are doing is aligned to it?”
Or as Simon Sinek puts it, “START WITH WHY”. Once you approach Agile in the context of WHY, then you can start to be Agile with your implementation of Agile, avoiding a swathe of common errors from dogmatic imposition of methodologies.
A problem with a lot of “Agile Delivery” is that while the approach taken in the teams is healthily supported by Scrum or similar, it is based on implicit assumptions that often do not hold true. Scrum assumes you are building the right thing in that it doesn’t really talk about how the backlog is created, only that it exists, but what if you’re not building the right thing, what if you are just building “Something”?
Enterprise delivery, or for those in large organisations with multiple teams, departments and managers, will know it: NORMAL delivery, suffers terribly from dependencies and conflicts. Millions are spent on delivering new capabilities or features and millions more managing the conflicts between them, without really ever being sure that their efforts are delivering the intended results that triggered them in the first place. Whole departments slowly slip into the “Build Trap” as Melissa Perri refers to it, becoming feature farms, secure in their high utilisation delivering a never-ending stream of potentially pointless changes to their products.
How should we operate?
At BCG I am privileged to work with people who are passionate about helping organisations and initiatives within them, understand WHY they exist, and from that ensuring that the efforts they put in are directly associated to that. VALUE DRIVEN DELIVERY we call it. Unless an organisation can express the PURPOSE it serves, it is near impossible for it to have strong value driven delivery underneath.
There is a cascading nature to the expression of purpose within an organisation and how that should connect to the activities and ways of working that affect the majority of a workforce on a daily basis.
What is needed to be achieved is the PURPOSE
How progress against the purpose is measured is its METRIC
Combining PURPOSE and METRIC gives an OBJECTIVE
Objectives need a PRIORITY
Progress is made against the objective through achieving KEY RESULTS / OUTCOMES
Employees focus on OUTCOMES through aligned MEASURES / REWARDS
Those Results/ Outcomes are delivered through a series of OUTPUTS
Outputs are connected to Outcomes on OUTCOME BASED ROADMAPS
And finally this hierarchy evolves over time through a cycle of INSPECT AND ADAPT
While this feels logical, when we really unpack the ways of working in many organisations we find a very different situation. Often the purpose is known to senior leadership, but the activities within teams are often poorly connected to it. The metrics the teams are being governed by relate to the delivery of the outputs, rather than to the Objective and there is too little, if any, Inspection or Adaption. Lots of activity, not so much VALUE.
How to shift from Outputs to Purpose?
One route to this is through the adoption of OKRs, Objectives and Key Results, at an organisational level. Created in Intel and popularised by John Doerr as he transitioned them into Google, they are a simple way to express the concept to senior leaders that improvements come from focusing on the why, not the what. OKRs are Purpose driven to bridge the gap between strategy & delivery and are proactive, in that they drive decision making in feature capabilities capacity management.
Note these are not KPIs which are always grounded and achievable, OKRs are more ambitious. KPIs are lagging indicators that are helpful to measure progress and assess the effectiveness of existing operations, but they do not assure the reasons behind those activities or processes. OKRs and KPIs should work together, they serve different purposes.
An organisation should only have a few OKRs and have everyone use them to understand how their efforts contribute. There should not be a cascade of OKRs per level or department unless the organisation is extremely large. Cascading OKRs risks reintroducing the original issue of a disconnect between the activities of the teams and the higher level strategic purpose.
An example of an OKR:
An alternative is to employ IMPACT MAPS, as introduced by Gojko Adzic which have a strong correlation to OKRs. Impact Mapping is a little more structured and really helps an organisation to understand how their sense of purpose translates into what they need to do.
Once again Start with, WHY?
Impact Maps start with the Goal, which is broadly synonymous with the previously described Objective. Then there is a helpful division by Actor or “Who”. Who might contribute to the realisation of the Objective? This is useful in large organisations as it enables a division of efforts between those focusing on a goal targeting one group of users, while another division focuses on a different group. Then, for each Actor, Adzic breaks it down into tangible things we want to see happen which are similar to the Key Results, and lastly what Outputs will enable those Impacts to occur (important to note you rarely need to deliver all possible Outputs to achieve the Impact.
In Adzic’s own words, “My understanding of OKR is that the KR part would map nicely to impacts on the map”. OKRs and Impact Maps are similar expressions of the same concept.
Within an organisation there are typically multiple Outputs being worked on, associated to multiple Goals. As long as no individual in the organisation is asked to contribute to more than one of them, then everything should run smoothly, however that is rarely the case. The Objectives, and the desired Key Results underneath them, need to be expressed as a clear set of priorities which are communicated to all employees. This will ensure it is clear which should prevail when there is ever a conflict for a person’s time. Those priorities will need to be reevaluated and recommunicated on a regular cadence by the senior leaders. OKRs are succinct so the communication effort should be relatively low. Where this does not happen we find teams competing with each other or at worst working against each other in pursuit of different goals. Shared capabilities will become stretched and expectations not met as people attempt to please multiple masters at the same time.
How to manage work by purpose?
It is one thing to create OKRs but it is easy to have this as simply an academic exercise that is quickly forgotten. Turning this into something that actually changes the ways of working in the organisation is where the benefit lies. This is where OUTCOME BASED ROADMAPS come in (sometimes referred to as Goal based Roadmaps). Outcomes here are synonymous with Impacts on Impact Maps and Key Results within OKRs.
Traditional Roadmaps represent the planned delivery of a pipeline of features which leaves departments wide open to losing sight of the bigger picture and redefineing success to be software deployed or a process signed off. They also often assume a determinate system, where it is known from the outset what is to be done and how long it will take, which is highly unlikely.
Outcome Based Roadmaps are effective because they both accept the vagaries of delivering into complex adaptive systems and connect what is being worked (Outputs) to to a higher purpose that ultimately defines success or failure (outcome / Key Result). There is decreasing confidence of delivery in terms of scheduling of the outputs. The next Output is likely to have an agreed delivery date within a few weeks range, while the Outputs six months down the line have a much wider date range to reflect the high degree of uncertainty that comes from projecting far into the foggy future of highly complex organisations and markets. A big distinction to more traditional ways of operating is that although teams are still working to deliver an Output (or learning about subsequent Outputs), their measures of success and reward are now taken against the Outcome. This approach helps to maintain a focus on the “Big Picture”, the reason why all the work is being done.
This uses the analogy of Ice, Water, Steam. Things we are about to do are cold and solid, compared to things nine months from now that might cynically be described as “Hot air”. To keep the Roadmap relevant it needs to be refreshed on a regular basis, it cannot be done at the start of the year and left; we understand that the act of planning is more important than the plans it produces.
In Summary
Employees in many organisations are wasting huge amount of time, money and effort delivering changes to products and services without sufficient awareness of why they are doing what they are doing. To address this organisations need to have a comprehensive answer to the question, “What is our purpose, and how can we ensure that everything we are doing is aligned to it?” To answer this organisations will need to adopt Value Driven Delivery and ensure they understand and follow these nine steps:
Agree on Purpose
Define the Metrics progress will be measured by
Express the purpose with its Metric as an Objective
Share the Prioritised objectives
Establish Key results / Outcomes that support the Purpose
Measure and reward people on the Outcomes
Outcomes are realised though the delivery of Outputs
Create Roadmaps that map Outputs to the Outcomes
Inspect and Adapt
Credit to Dragan Jojic and Glenn Bowering for their contributions and support.
Comments are welcomed – even criticism. It is only through feedback that we learn.
Psychological safety can be considered to be the collective lack of fear of expression; we should look to emulate the aspirations of our society when considering the best working environments for our teams.
As the heat builds, heralding the start of summer, I have given thought to the Pride celebrations that are common in June. In the past weeks there have been two of the greatest in New York and London; and in an idle hour of sunkissed self-reflection I pondered why I found these explosions of colour and expression so uplifting. It isn’t the visual spectacle or the expression of differentiation that I find enriching, more what the staging of the event says about our society, and how it stands against the forces that seek to divide and label us. My joy at Pride doesn’t come from the pageantry of the participants, but rather the inclusiveness of the wider society that accepts and celebrates it.
It is freedom that is celebrated. Initially this freedom was legal freedom, and slowly it evolved to be freedom of thought and now approaches freedom from judgement. We are reaching a normalisation, a situation where my eight year old sees our married gay friends no differently to any other couples he knows.
At the same time, yet on an entirely separate mental track, I have been involved in facilitating discussions on psychological safety with colleagues at BCG. These sessions began with an exploration of the concept – a definition. The ability to speak up with a contrary opinion was suggested, this then progressed to a sense of collective trust and then ultimately to an agreement on an environment free from fear, and explicitly the fear of judgement. This is not the absence of judgement; quite the opposite, it is an acknowledgement of objective criticism that appreciates, and actively seeks feedback.
I explain psychological safety as when someone, even if they do not have the full context, feels comfortable in raising a concern. Their concern being heard and discussed with no loss of face with the person who raised it feeling exactly the same regardless of whether they were shown to be right or wrong.
If trust is something that exists between two people, then psychological safety is the group equivalent. It is a characteristic of a collective rather than of an individual. You can’t take someone from a safe team, drop them into a group of strangers and expect them to behave as they did before. Psychological safety fills the gap between people; like mortar between bricks, it binds them together and enables them to build great things when individually, even as a large group, they are weak and easily fragmented.
The parallels between extravagantly colourful dancers in the streets of London and senior executives discussing team dynamics in a conference centre, are as stark as they are unexpected. They are both exploring a very deep emotional question, “what do we want from our environment?” Those executives were considering this from the compartmentalised perspective of a team working with a client; but this is a wider topic that belongs more to philosophy than business: What are the traits of a society we would desire to be part of?
In response I assert that freedom from oppression is one of the foundations of a world we would choose to inhabit. At the heart of oppression is the consequence of judgement. The more severe the judgement, the more restrictive the society becomes. It is no surprise that LGBT rights is a common yardstick for a society. When criticism of a regime is personally catastrophic then public protest ceases almost completely, but criticism only ceases openly. Those opinions still exist, seething under the surface like a buried blanket of malcontent. Within what most would consider to be a progressive society, we need to be tolerant to everything other than others’ intolerance. We aspire to universal psychological safety.
Stepping back from the immensity of sexual equality, these principles are replicated in teams, like microcosms of the world around them. The brilliant TED talk here from Amy Edmondson makes the case in simple terms with real world consequences. It is unfortunate that the situations that have the most severe consequences of failure look to mitigate them through penalties which repress the actions most likely to prevent them, repressing that lone perspective that that isn’t the wire to cut, or that isn’t the right incision to make, or that civilian isn’t a terrorist. The consequence of repression of opinion in unsafe environments is hugely damaging because it robs us of the only weapon we have to combat the volatile, uncertain, complex and ambiguous world to which we are now struggling to adapt. It robs us of feedback, it steals the opportunity to learn and therefore improve. Being wrong isn’t a failure of learning, it is the very essence of it. The only real failure is the failure to learn, and without a conscious effort to engender and sustain a psychologically safe environment you are risking everything to protect the sensibilities of others. This isn’t just theory, the much lauded work environments of Google and Spotify explicitly call out psychological safety as critical to their success. Effective delivery is found between people: it isn’t the efforts of the individuals that bring moments of brilliance but in the marrying of minds and ideas between them and psychological safety enables those minds to connect.
It is important to address a common misconception, a false association with niceness that enables some to dismiss the concept as an abdication of responsibility for delivery. The author Allison Vesterfelt addresses this elegantly when she compares niceness to the much more powerful concept of kindness.
Niceness stays quiet. Kindness speaks up. Niceness is toxic. Kindness is healing. Niceness lies to keep the peace. Kindness knows the only way to make peace is to tell the truth. Niceness holds back. Kindness moves forward with humility gentleness, and grace.
Psychological safety enables kindness, niceness is the antithesis.
Unfortunately psychological safety is not something that you can purchase or achieve though participation at an expensive training session. Like happiness, it is a lagging trait. Like a seed, you can’t make it grow through sheer force of effort, you need to create the right environment, and step back. It will grow slowly and steadily but like a seedling, it is most vulnerable when just a young tender shoot. Teams are most at risk when they initially open up to each other, a misjudged word then will cause more damage than had the team not started to open up in the first place..
It is easier to bring about psychological safety as a member of the group rather than as the courageous activist, “Be the change you want to see in the world” and hold back from countering alternative opinions. It starts with vulnerability and stepping back from the trappings of power and authority. A desire to retain and enforce hierarchy is one of the most insidious enemies of a safe environment. Leaders need to step back from the trappings of power and authority to prove to teams that they genuinely welcome free expression. They must allow themselves to be vulnerable to having their suggestion countered or even dismissed, and when that happens they absolutely must react positively. In the long run it is better to be loved than feared. Rewards and recognition are at the centre of changing behaviours and culture. Those that speak up deserve kind words and respectful listening. Ultimately if a team can agree it is everyone’s personal responsibility to make everyone else look good, or even better than themselves; then psychological safety will flourish.
I am fortunate to have worked in teams where I could speak up, and I am proud to be able to say I have had my suggestions countered, been hurt by the criticism and managed to let go, prioritising the team dynamic over my own fragile ego. I have felt the infectious enthusiasm that comes from a safe team, it was a wondrous sensation that enabled fantastic delivery.
However I am prouder still to live in a society that celebrates my liberty to paint a rainbow on my face and not only does not judge me for doing so, but does not even assume that I am LGBT. I wish everything could be this psychologically safe.
Comments are welcomed – even criticism. It is only through feedback that we learn.
Today’s business world is deeply complex. Complex as distinct to complicated. The distinction between these two is absolutely critical and is at the heart of the biggest challenge the consulting industry has ever faced.
Simply put; complex problems are those where the consequence of cause and effect is understandable but not precisely predictable, whereas complicated problems are entirely logical, and by extension fully predictable, which makes for a much more prescriptive approach to solutions and estimates.
There is nothing more inherently complex than the relationships between people, which, when combined with the premise that the best delivery comes from high performing teams, brings a slow realisation that the ultimate goal is how to enable and sustain these amazing teams. Complicated problems, in contrast, do not last long, for the reason that once solved, they remain solved. The solution, by definition, can be repeated, and importantly for our modern digital age, anything repeatable is automatable. The rise of the machines has enabled our society to focus on the complex problems that remain, like a sunken settlement revealed by the draining of a lake. This change is occurring rapidly, certainly more rapidly than our business culture and management models have been able to adapt to. As a consequence we still approach these complex problems with the same mindset; question: answer; Problem: solution; Clear cause: precise effect.
Companies turn to external consultants for their expertise, for their ability to help solve problems but ultimately to obtain a solution. There is a huge expectation to have an answer, or better still the answer. Here is the consultant’s dilemma, the ultimate in complex challenges:
How to give a successful complicated response to a complex problem?
Prescriptive answers to complex problems will inevitably fail, and the greater the timeline and scale, the poorer the result; but the alternative is a commercial minefield. How can you sell an idea that you haven’t had yet? How do you sell an operating model that can’t be defined other than through an emergent collaborative experience? It is a difficult response to give, instead of answering the question, suggesting that the question is wrong. They are being asked “What do I need to do?”, whereas it needs to be turned round until it becomes, “How do I learn what to do?”
The concept of Agile transformation has progressed a lot over the past few years, it has done so not through moments of genius, but the same way that we progress with all complex problems, through emergent discovery with as many learnings as successes. However it is important to acknowledge there have been successes. Some fairly enormous enterprises have really seen substantial shifts to a more Agile approach to business including such seemly unlikely candidates as banks and airlines. So what is the solution, what is the magical silver bullet? It is tempting to analyse what was done, collate findings, examine the end state and advocate those ways of working and commoditise it as being “the solution”.
Unfortunately it doesn’t work quite like that. The moral buried in each tale of success is that each is unique. If something worked it’s because it was carefully created and continually adapted to match the combination of culture, people and market conditions of that organisation and those conditions will never be repeated. It is the journey, not the destination that was successful.
The challenge all B2B service companies have, is how to build trust. If the offering is expertise to help an organisation address their problems then that organisation is going to want some assurance that the partner’s skills and experience will be beneficial. Having some manner of playbook is the shortest, fastest and has been the most successful means of doing this. It reduces the client’s perception of risk because they believe they know what they are buying, but it exposes them to a risk of a pre-defined solution because playbooks tend towards artefacts and standardised process, they are designed to enable repetition, they are designed for complicated problems. They are yesterday’s solution for yesterday’s problem.
There are many playbooks, models or frameworks incorporating process, practice and method out there, all suggesting that their version is different and a little better than the others. They advocate that their approach will deliver the utopian business agility desired by business leaders everywhere.
There is merit in these models, at least some of them, or to be pedantic, some of some of them. The phrase, “All models are wrong, some are useful” was coined from statistical models but applies equally well in this context. The weakest models are those that lead organisations to believe that they can achieve business agility with no reference to organisational design and its supporting constructs of HR, finance and culture; but even those that are process heavy and customer light, can help in certain contexts as a good first step out of confusion. Any model that prescribes a formula of process and practice to achieve success will ultimately fail because it can’t adapt to the responses of those affected by it. The big distinction to look for in Agile models is between those that prescribe an approach to learning and change, versus those that look to implement process and practice.
The best models are those that look to frame conversations rather than offer clear answers. What is needed is something that highlights the need to hold discussions on a plethora of topics; dialogues, not lectures. Some of those conversations will be short as the participants learn that things are in a good place, others will be long and difficult as they mutually discover there are significant differences between where they are and where they would like to be. Just discussing where they would like to be is hugely important. What is needed is a companion for a journey, not a guidebook for a destination. Models that give direction and purpose are much more likely to be effective than those that articulate a detailed solution.
To navigate out of this awkward dichotomy between undeliverable solutions and unsellable learning, the approach the strategy consultancies are now taking is to bring years of experience in navigating difficult journeys into a communicable format that their clients can buy into. What they have is an initial proposal of something that can be tried together and learnt from, where the learning is more important than the actual output. It is the learnings that help both parties better understand each other and where their journey will lead. Experienced consultants have taken many journeys, each has ended in a different place and each has had unique challenges but there will have been many pitfalls that were avoided with the aid of those experienced guides.
While Agile transformations are occurring in a very wide range of industries, every problem is a “people problem” and the ability to recognise those human challenges early is important for success. Experience is more valuable than theoretical knowledge here, it is the speed to learn that is important, the speed to recognise situations encountered elsewhere and adapt. This breadth of exposure to human challenges is behind why most Agile Transformations are supported by external staff, either expert independent contractors or consultancies.
There is one more element that is absolutely critical, and without which things flounder and the rich harvests from fertile ground slowly wither. It is not enough to seek learning, it must be enabled. Organisations are amazingly resilient in their culture, and will automatically protect themselves against changes that threaten the status quo. There are processes and rules which exist to perpetuate the observance of the processes and rules. For any substantive change to occur it requires those that are seen to own the status quo, to be actively involved in the change. This provides a safe space for everyone else to learn and importantly act upon those learnings to make the organisation a better place. It is the role of senior leadership to facilitate all other employees to learn, change and adapt; through their participation all others will feel sufficiently liberated to act. Once leaders are seen to value experimentation over compliance then the vast learning potential of the organisation can be tapped. It is this last piece of the puzzle where the strategy consultancies really have the edge over many others of equal talent in the market place. They have the relationships, and consequently trust, from senior leaders necessary to make clear the need for their involvement. They have the opportunity and the experience of supporting, coaching these leaders in making those journeys.
In summary; whilst the challenge of addressing complex problems to those that expect complicated solutions remains, strategy consultancies are uniquely positioned in being able to address the underlying issue. Success in this domain requires three things:
Comprehensive technical knowledge of Agile values, principles, associated progressive leadership techniques, and the many Agile models; what has worked elsewhere and the strengths and weaknesses each
Extensive experience in learning and adapting to address the human challenges that occur when trying to instil unfamiliar concepts and principles on culture, leadership and value centric delivery
Deep relationships with the leadership of organisations with the ability to express the changes and investments that are needed from them, not just their teams, to ensure understanding that Agile is about business values not IT processes
There are few players that can claim strong capabilities in all three areas. The challenge will always remain for the Strategy consultancies in balancing the complicated demands against the complex reality but their learning centric approach has the capability to deliver faster and with better results than anything else. The question that remains for these companies looking to embark on their journeys is, who do they want as their guide?
Comments are welcomed – even criticism. It is only through feedback that we learn.
philagiledesign 