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?
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.
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.
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
Pass to the teams to define solutions
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
Pass to the teams to define solutions
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.
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.
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.
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
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.
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.
I am regularly asked for help from people with a distress call along the lines of, ” I am a Scrum Master now, apparently, what do I need to do?” This is roughly my response:
There are some teams that have chosen to adopt Scrum, and I wish them the best, although they probably won’t need my well-wishes. Merely the fact that they have CHOSEN to try scrum exposes all manner of values and behaviours. To start they clearly have a degree of empowerment over their ways of working, and they also likely have a sense of commitment and passion about what they do, enough to try something to improve their situation. If they have chosen Scrum, it is likely that they have considered their context and their situation and believe that either it is a good fit, or that they can make some internal changes to enable it to be a good fit. Either way they will either look to recruit a Scrum Master or one of the team will look to adopt the role with a view to, if it works, make it a permanent full time function.
There are some teams in an even better situation, they are formed as Scrum teams in a context that is suitable, often referred to as “Agile by birth” and will often be supported by dedicated Scrum Masters – I had the good fortune to work in a team like this – the most rewarding experience of my career.
In my experience though, this is not the norm, due to their size many, many software delivery professionals find themselves inside large corporations where the freedom of working practices are more than slightly constrained. Often there is a degree of close interaction between teams that rewards aligned working practices within a value stream (for adaptive organisations – or skill based departments for others). Now in this context the choice to use Scrum hasn’t really been taken by the team, it has been suggested, encouraged, expected, requested or mandated depending on the culture of control within the organisation.
This brings interesting and typically unconsidered challenges, especially for the unfortunate scrum master who has been unwittingly appointed. In the type of organisation that has imposed Agile there is likely to be the expectation that the Scrum Master will impose the practices of Scrum. Typically this is in service of a wider Agile transformation imposition, and we are now looking at command and control from the top, through the departmental level and down to each and every team member. Attempting to achieve Agile values through rigidity is unlikely to be successful. People choose to do things, people choose to change or adopt new things and whilst they may do this in light of new information, it remains THEIR decision. You can’t forcibly change someone, attempting to forcibly impose working practices is deeply destructive, the team need to choose to adopt them. Here is the heart of the challenge of the expected / imposed scrum, because the team didn’t actually CHOOSE Scrum, it becomes very hard to hold people to its practices.
My suggestion in this situation is simply, not to. I think it is reasonable to have someone explain what Scrum is, and how it is different to their current operation, but then shift the focus of this coerced Scrum Master from working within Scrum guidelines to working within “Team Agreed Practices”. The role of the Scrum Master then becomes an enabler of continuous improvement rather than some Agile process police.
The role of a Scrum Master that was appointed, not aspired to, in a team that has Scrum requested of it, rather than chosen by it, is this:
To be the voice of conscience, to hold the team to account against how the team has chosen to operate; and to facilitate the regular discussions of how the team should operate.
When we start to talk about how things SHOULD be, then you’ll trigger questions like:
Why are we doing stuff?
What is going on?
How can we be better?
With a little support the teams will start to increase transparency, value delivery starts to become more important. The team will reflect on what they are doing and look to change, to inspect and adapt. The team will slowly build up to something pretty close to Scrum, and if they don’t it will ultimately be because they have found something better than Scrum given their unique context.
Remember that Agile is not the goal, Agile and all the practices and terminology that come with it are just other people’s ideas that helped them be better. Try to enable your scrum masters to be “betterment people”, rather than “enforcers of a process I didn’t choose”. This approach will encourage your people to be proactive about improvement, rather than instruments of repressive control.
Comments are welcomed – even criticism. It is only through feedback that we learn.
Retrospectives: one of the first terms you’ll encounter in the weird and wonderful world of Agile delivery; but what are they and why are they important? Didn’t we cope well enough before without them?
So first a little definition, the term really entered our lexicon through the widespread adoption of the Scrum framework, in the scrum guide it is defined as follows:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
I am increasingly finding that Agile-y terminology is a barrier to understanding and adoption. Unfamiliar terms can make us feel inferior or foolish, and new “In Vogue” practices can feel threatening because we may feel judged for not being part of the “In Crowd” which in turn can result in people rejecting these ideas as a matter of principle to avoid loss of face. Whilst this definition is technically correct, Retrospectives are far too useful to be constrained within the Scrum framework, and can be beneficial to people not in Scrum teams and not doing things in Sprints, or even in Software delivery….
Retrospectives are really just an agreed time to focus on improving. Taking a step back from being down in demands of delivery to consider how things are being done; look up for a while. This could be alone, reflecting on how you are responding to your situation; something that is significantly undervalued, but typically, retrospectives are a group activity, an opportunity for a group to reflect on how they interact.
To start it is helpful to discuss what a Retrospective is not, to clear up common misconceptions you’ll encounter. It is not to decide how to deliver a specific output, that would be a planning or design session. It is not to review something we’ve done, that would be a review. It is not about WHAT are we doing; it is very much focused on the HOW are we doing things.
It is important to appreciate why we need them now, when we didn’t really need them before, and really this is a recent solution to a recent problem. Historically organisations had strong hierarchies that existed to “command and control” large workforces; to ensure everyone did as they were instructed. As the work became harder to define and understand, we moved away from structured formulaic industries and towards an adaptive creative economy. We’ve seen the fundamental principles of scientific management collapse as we’ve delegated the decision making to where the information lies – which is rarely at the top. However, if those operating practices have been delegated to teams, then they need some opportunity to define and refine those practices. Put simply, we didn’t need retrospectives before because we told people what to do.
Any group of people that are engaged together, with collective ownership and responsibilities to deliver something, that requires a degree of creative thought will benefit from Retrospectives.
I still regularly encounter teams of people working together that resist having anything akin to a retrospective. If you are free to choose how you work and the work is in any way creative then I am going to stick my neck out and say there is no good reason not to have one. The two most common defences I hear are:
“We are too busy”
“We don’t need to change”
I will rephrase the first as “we are running so fast we have no time to reflect”, which clearly is an unsustainable business model.
The second is also rather short sighted, we don’t need to change means we don’t need to improve. Either improvement, hence performance, doesn’t matter, or maybe, just maybe your delivery unit or team and the interactions you have with your wider context is perfect. Perfect… Maaaaaaybe.
Usually though, these defences are excuses for something much more troubling. I don’t want a Retrospective because I don’t want the team to think for themselves, because I want to retain control. If you are in this situation then you need to engage at a level higher and talk about principles.
When it comes to retrospectives there are three things I recommend:
Have it on a cadence as frequent as pragmatic
Try to make the attendance as consistent as possible
Try to make the retrospective as different as possible each time within the two previous constraints
A regular cadence (the regular interval they are scheduled for) will ensure that they actually occur, Like the difference between saying you’ll go for a run, and actually going for one… Retrospectives are playing the long game, immediate return is unlikely – but in the long term beneficial. It also helps to keep the conversations balanced and not drift into crisis management. You really want to be talking about the way we do things under normal circumstances, on boring Tuesday afternoons in March, rather than be overly influenced by extreme isolated incidents. The frequency will dictate the topics you are needing to cover and needs some balance; infrequent retrospectives can be overwhelming because of the amount of content that comes up, too frequent and the administrative overhead starts to creep up.
Consistency is important, you want everyone’s opinion but also the ways of workings you are trying to optimise will be related to the relationships within your delivery. If you keep changing those relationships then you keep changing the target you are trying to hit and you’ll forever fall short.
My third recommendation is where I see the biggest opportunity to improve with most of the teams I encounter. They have tried something, and it worked, so they have repeated it. There is merit to this normally, we practice and refine until we perfect. Retrospectives are curiously different and the expression, “if you always do what you’ve always done, you’ll always get what you’ve always got” is more appropriate. The principle is that by approaching the challenges the team faces in new and interesting ways each time, then the results and the suggestions you are going to get are likely to be different. Many retrospective techniques pull on expressing issues through different mediums, imagery or metaphor, this is to try to stimulate different neural pathways which will enable new viewpoints. There are many great retrospective techniques that you can use, and for me the best one, is the next one. I have a few that I fall back on when asked at short notice, but for a team I have worked with a lot, I typically try to do something different each time.
I am often asked to work with a new team and I only ask for one thing to be present before I accept, that the team is willing to run Retrospectives. If that is declined then I would strongly suspect that my involvement with the team will not delivery the results that are expected.
So, if you are a team, and you are not running retrospectives, why not? What are you afraid of?
Comments are welcomed – even criticism. It is only through feedback that we learn.