Jay Taylor's notes
back to listing indexIn praise of SWARMing
[web search]In praise of SWARMing
Most of my work these days is helping organisations figure out how to be more effective, in terms of how quickly they can identify and respond to the needs of their external and internal customers, and how well their response meets those needs. This tends to be easy enough in the small; the challenges appear as we try to scale these techniques to the hundreds, thousands or tens of thousands of people.
It is into this space that a new generation of software methods have emerged. SAFe, LeSS, DAD and others claim to help enterprises “scale agile,” whatever that means. A generous interpretation is that people who have a track record helping organisations on this journey have managed to codify their knowledge into a set of blueprints, guidelines, frameworks and methods so you don’t have to. Another take is that execs in organisations above a certain size like to buy a packaged solution to a perceived problem, and people with experience in selling to this market know exactly how to dress something up to look sufficiently appealing.
The most successful transformations I have experienced—the ones where you walk into the office and there is a tangible difference in the energy and interactions between people, where the commercial and management stakeholders are as excited and invested as the technology stakeholders, where everyone agrees on the metrics that matter and those metrics are trending in the right direction, where the people involved are proud to be part of the change, and where those outside are eager to get involved—those transformations succeed because a small cabal of dedicated individuals take the time and effort bringing people on the journey with them; they create and nurture a groundswell of enthusiasm; they engage, challenge, educate and support the middle and senior managers whose world is being turned on its head; they gain the executive sponsorship and investment to carry the whole thing forwards; they use external help because they know they can’t do it all themselves. And they do all this without recourse to canned methods or certification Ponzi schemes.
I think this approach deserves calling out so I am offering a new acronym, SWARMing: Scaling Without A Religious Methodology. My argument isn’t that packaged scaling methods are unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation. They can be anything from a useful starting point to an expensive distraction, but one thing they are not is a solution.
No silver bullet
The hard truth is that most lean or agile transformation initiatives will fail, because they challenge the very fundamentals of the organisation: how the money works, how governance works, how management works, how accountability works. These transformation programmes tend to happen in 3 to 5 year cycles. With each change cycle a senior manager adopts the latest iteration of words and rituals without taking on the hard work of engaging with the organisation’s underlying structures, behaviours, values and beliefs, and three to five years later the latent constructs have prevailed. The only tangible results are a large transfer of cash to the external consultants, a rash of certificates with a recurring revenue model, and a metaphorical shrug of the corporate shoulders. The inevitable hand-wringing that ensues and the need to do something precipitates the next change cycle, and the wheels turn once again.
Transformation is not a transactional activity that starts and ends and has a budget, and it should not be treated as one. It is never finished, in the same way evolution or adaptation is never finished. The goal is rather to break free from the thinking that led to the incumbent system by introducing a new paradigm, and then to use this to achieve a new steady state where the organisation is responding quickly and effectively to external and internal feedback, behaving like a genuine learning organisation. The challenge is to encourage, precipitate, and then support that paradigm shift. The principles underlying the new model are straightforward to describe, but they involve a root-and-branch rethink of the fundamental structures of the organisation.
I see a number of factors necessary for genuine, measurable, lasting transformation. Where I’ve seen transformation attempts fail, one or more of these has been conspicuously absent. Before I discuss these I want to explore some of the differences between the old world and the new, and look at what makes these packaged scaling frameworks so appealing.
The shape of waterfall
A paradigm is the set of assumptions or beliefs we hold to be true. Over time we institutionalise these into corporate policy, organisational structures and even into law, as I have discussed elsewhere.
I want to highlight some of the differences between the old and new paradigms to show the ground we have to cover. In each section I first describe the traditional paradigm and then the corresponding assumptions in the new world. As you read each paragraph, whether or not you agree with the statements, remind yourself that these organisations are acting as though they are true.
Cost efficiency: utilisation vs flow
In a traditional firm the organisation is seen as a number of separate departments, each of which is either a cost centre, like IT or HR, or a profit centre like Sales. The difference is that a cost centre doesn’t contribute directly to revenue. Costs are allocated to each cost centre, and cost efficiencies come from reducing the operating costs in the cost centres and maximising the revenue from the profit centres. Common strategies for reducing costs, especially towards the end of the financial year, are limiting travel, reducing variable headcount by laying off contractors and other temporary staff, shifting work to cheaper countries or locations (“moving the work to the people”), repurposing legacy hardware and equipment, and forcing teams to use standard components to minimise “cost per use”. Common strategies for maximising revenue are offering commissions on sales, setting aggressive quarterly targets, and offering incentives and rewards for achieving specific goals. Gains come from maximising resource utilisation, i.e. keeping people busy.
In an agile organisation—in the broader sense of business agility—the organisation is seen as an interconnected system where all departments are value-generating, either directly contributing to the final product or indirectly enabling the organisation to work more effectively. Value chains map the creation of value through the organisation, ending with meeting a specific customer need. Costs and revenues are allocated holistically across the whole value chain, and cost efficiencies come from optimising the flow of value. Common strategies for reducing costs are identifying and eliminating non-value adding activities, limiting the amount of work in process to reduce hidden inventory of work, and assembling multi-disciplinary teams to reduce handoffs and other delays (“moving the people to the work”). Common strategies for maximising revenue are working iteratively and incrementally in small batches to realise value sooner and improve Risk-adjusted Return on Capital, frequent testing of product ideas with customers to identify which work not to do, and enabling teams to choose the most effective tools to reduce their time to market. Gains come from optimising flow efficiency, i.e. keeping work moving.
Managing work: project vs product management
In a traditional firm scope is defined in detail and locked down before the work starts, usually as the result of a project or programme initiation exercise, in the form of a Business Requirements Document as part of a Business Case, which will also contain a cost and resource breakdown and revenue projections. This is presented to a funding board and the programme budget is allocated and signed off. Success is defined as delivering the agreed scope within the cost and time constraints. Variance in scope is frowned upon, as is replanning, which can have severe knock-on effects elsewhere in the organisation.
In an agile organisation scope is defined dynamically within a product area, usually in terms of moving a business metric in a desired direction, for instance reducing customer churn or increasing profit per customer visit. Funding is allocated as an ongoing run rate for the product area, and revenue is tracked as a near-term trailing indicator. Success is defined as the ongoing achievement of the business metric goals, or learning through evidence that this is the wrong strategy. Variance in scope is both expected and encouraged, and regular replanning based on market and operational feedback is normal.
Portfolio planning and governance: up-front vs ongoing
In a traditional firm the annual plan is sacrosanct. People up and down the organisation invest considerable time and effort in the annual budgeting and planning cycle. Each department predicts what it will spend and what it hopes to achieve, and a central body determines each department’s budget. These budgets cascade into the programmes and projects within each department and a centralised PMO or similar function monitors and polices progress. Replanning has a high cost and effort and is discouraged, so there are repercussions for deviating from the plan once it is underway. Projects and programmes are assessed as Red, Amber or Green (“RAG” status) according to their level of deviation from plan, and the project and programme managers are held to account accordingly.
In an agile organisation financial planning happens more frequently, typically using a rolling one year plan reviewed quarterly. Many firms are adopting OKRs as a mechanism for this. The PMO supports global system optimisation: Green means things are good; Amber means a project or programme needs help with a decision that has implications beyond its boundary; Red means the lack of such a decision is putting the outcome materially at risk. “RAG” status in this context is about how well the project or programme is being supported by the wider organisation.
The appeal of frameworks
There are other contrasts I could draw but the above should serve to illustrate the cultural and organisational chasm we face and highlight the work ahead of us. Sociologist Ron Westrum goes into more detail about different organisational cultures but these are some of the more common differences I have encountered.
Packaged frameworks are appealing because you can easily find this overwhelming. You want this Business Agility magic you keep hearing about but you don’t want to, or are unable to, challenge the corporate funding and governance processes, and whatever you do has to fit within strict departmental cost controls. So you start by sending a handful of project managers for Scrum Master certification, and maybe some business analysts for Product Owner training, then you try Scrum for a bit. Later you might try Scrum-of-Scrums, SAFe, LeSS, or similar with the best of intentions. If you can just to prove it works in a contained pilot environment, the rest of the organisation will surely wake up and beat a path to your door!
The problem is that this kind of transformation requires a fundamental shift in how people think and how they operate. This in turn requires acknowledging that the way they are running things is based on assumptions and constraints that are no longer relevant to the modern business environment; that they are still in business in spite of, rather than because of, these inherited management and governance systems. No one likes to acknowledge that, even to themselves. Their subconscious minds vehemently resist this paradigm shift, which makes them easy prey for a vendor selling a product that promises said transformation while conveniently fitting their existing paradigm.
The vendors and consultants can do this regardless of whether it will deliver the results, safe in the knowledge they and their methods won’t be held accountable if it doesn’t, because the one thing everyone can agree on is that transformation is hard and at least we tried. Many proponents of these methods have a religiosity about them. Their method works; if you don’t believe this you are misguided, misinformed, or just antagonistic (I’ve been accused of all three); and if it doesn’t work then you are applying it incorrectly.
Scaling Without A Religious Methodology
There are a handful of ingredients without which you are unlikely to achieve lasting change. They are by no means a formula for success. Rather, you should consider the absence of one or more of these a danger sign, a significant risk to be managed and mitigated.
1. Time
Transformation takes time, patience and tenacity. Shifting a large enterprise of thousands or tens of thousands of people will take a number of years. The technology adoption lifecycle applies here, with its pioneers, early adopters, early and late majority, and laggards. You should focus your efforts on the pioneers and let their successes draw in the early adopters, and so on. Too many transformation efforts try to reach everyone at once—”We are going agile from Monday!”—and the social demographics show that this just doesn’t work. You should expect no more than 5% of your organisation to be pioneers of this kind of change, so work on identifying and recruiting them, and giving them the environment and tools they need to succeed.
2. Investment
Just as this transformation won’t happen overnight, it also won’t happen on its own. You will need to assemble a dedicated team, which means ring-fencing and funding them, and delegating or managing their responsibilities. In the greater scheme of things this is a tiny investment—you can get a long way with a handful of people—and I am continually surprised at how difficult it can be to get this allocation of people and funding in an organisation that clearly wants to go on this journey. It is worth taking the time to ensure this commitment is in place before you get going, however long it takes.
3. Communications
Different audiences respond to different messages. Take the time to understand your stakeholders and think about the kinds of communication they will find useful: Which channels? How often? What content? What is the goal of each communication? How can you meet them where they are? Where do you want them to be? Where are the gaps? From awareness roadshows to executive briefings, the way you structure and communicate your vision, aspirations and progress will be most people’s primary view into your world.
At the very least you should be able to answer “What’s in it for me?” and “What do you need from me?” for every stakeholder group. As well as the people you will be directly interacting with you should also consider anyone indirectly affected by the transformation. These could be internal and external suppliers, customers, partners, regulators, auditors, or anyone else
You will have your share of detractors, primarily the late majority and laggards who have a vested interest in maintaining the status quo, and who will be anything from indifferent to critical to actively sabotaging your efforts. And don’t be surprised to find allies in unexpected places. Amplifying your successes and neutralising your opposition can take up a lot of your time so having a robust communication plan in place will help you stay on track and not lose sight of important stakeholders.
4. Influence
More than anything else your core team needs both the ability and the credibility to influence up, down and across the organisation. Trying to do things on your own will be like boiling the proverbial ocean. You are trying to create a groundswell and encourage change, not do it all yourself. You need the requisite executive sponsorship, and people who are not afraid to speak truth to power, respectfully and professionally, and who know when to shut up and listen.
Some years ago Lean Operations veteran Richard Durnall wrote an article describing the arc of transformation an organisation goes through. That link is a slide from a talk I gave that includes a discussion of this arc, because Richard’s blog is no longer online. He describes six stages of transformation in terms of things that break. You start by introducing new ideas that challenge incumbent beliefs (“The people break”). Soon you find the processes and tools are no longer fit for purpose (“The tools break”). Measuring flow of value rather than busyness and effort brings you into conflict with the PMO (“The governance breaks”). As you start to scale you realise just how many stakeholders you need to bring on the journey with you (“The customer breaks”). Shifting to product rather than project management means you need regular incremental funding rather than infrequent, big investments, which the corporate finance model isn’t set up for (“The money breaks”). Finally you realise that silos of functional departments are exactly the wrong structure for business agility (“The organisation breaks”).
The two most challenging stages are around the governance and the money. This is where corporate structures, policies and culture are likely to be the most ingrained, and where you will potentially encounter powerful friends and adversaries! The sooner you can start to influence the governance and finance elements, the greater your chances of lasting success. Conversely if one or both of these are outside of your control, your potential sphere of impact will be correspondingly smaller.
5. Education
There are some core fundamentals that you and your pioneers will need to learn, practise and internalise. My starter list would include understanding the basics of Theory of Constraints, Systems Thinking, Throughput Accounting, Complexity Theory, Lean Product Development, Continuous Delivery, modern leadership, and change. If you are a book learner you can glean most of this from a handful of well-written books: The Goal, Thinking in Systems, Lean Enterprise, Continuous Delivery, Turn the Ship Around, Fearless Change, and for extra credit, The Principles of Product Development Flow.
The key here is understanding the core principles without getting bogged down with specific implementations. This is where those scaling frameworks can be helpful, as a “non-blank piece of paper” to demonstrate to your sponsors that you aren’t just making this up, and to provide an initial vocabulary. But take the time to understand the principles behind the methods and techniques so you can adapt them to your own context.
6. Practise
“Knowledge without practice is useless. Practice without knowledge is dangerous,” says Confucius. Reading about these topics is like reading about scuba diving or surgery. You won’t appreciate it until you do it for real, and like any new set of skills it will take time to get good at it. Messing up is a necessary part of learning. You should therefore think about how to practise in a safe-to-fail way. That conversation you want to have with the CFO about releasing smaller amounts of funding more frequently with less of the heavyweight approvals boards and governance theatre? You should probably practise that first on a friendly finance stakeholder who will politely let you know they glazed over as soon as you mentioned velocity and story points. And that they don’t think the CFO will appreciate the phrase “governance theatre.”
In the words of a famous Swedish poem, you should speak with farmers in farmers’ words, and with learned men in Latin, in other words practise adjusting your message to your audience. Likewise try applying flow tools like value stream maps, lead time measurement and cumulative flow diagrams on a small, friendly project first, before you try to roll it out across the wider programme. Gather evidence before you pitch flow metrics to the PMO. You may only get one chance.
7. External help
My favourite definition of a good consultant is someone who has screwed up enough times before on someone else’s dime that they don’t have to do it on yours. You can go it alone but you are likely to fall into all the traps everyone falls into, and your fundamental attribution error bias means you won’t believe me. There are two kinds of external help that seem to make a real difference: trusted advisers and embedded coaches. The former will be invaluable early on and should become less necessary over time. The latter you want to engage as you start to build momentum and realise you can’t be everywhere at once. The problem is that anyone can declare themselves an agile or lean coach just by updating their LinkedIn profile—around 18,000 at time of writing—so it is worth shopping around and doing the due diligence. Use your network—word-of-mouth recommendation and track record are by far the best
As you start to build momentum you don’t want an army of self-declared coaches with different levels of ability and experience, different approaches, ideologies and allegiances fragmenting your efforts. I have seen more than one transformation initiative hoover up all the agile coaches they could find, only to eject them all some time later with little progress having been made.
Frustratingly this is one area where certification could help, by assuring a level of competence, consistency and experience, but that would require peer-appraised, practise-based certification and assessment, and there is no network of peers that could guarantee any degree of quality or consistency here, especially between the various competing scaling methods.
8. Consistent, invested, resilient leadership
From the top of the organisation down, the leadership culture will make or break an agile transformation. There are many adjectives that could describe good leadership. I have chosen these three as my key ingredients, although I’m sure others will have different and equally valid opinions.
Consistent leadership is in it for the long haul. Various sources tend to agree the average tenure of a CIO is around 4-5 years, which means a good proportion of them will be moving after 2-3 years. (There is a tendency for CIOs approaching retirement age to stick it out and skew the graph to the right.) I have seen otherwise successful transformations stalled and then abandoned after a change of senior leadership, especially when someone is brought in to “control costs”. They invariably interpret this as slashing departmental budgets rather than trying to figure out why so much effort produces so little value. Ironically they would gain much greater savings by following through on the transformation.
I had the pleasure of meeting Henk Kolk, former chief architect at ING Bank, in 2015 when he was talking about their agile transformation journey. When we met this had been going for some years and was still well underway. A recent McKinsey article shows that although some of the names have changed, the new incumbents have carried forward the same culture and commitment.
Invested leadership realises this is the future of the organisation, not a side project. In Theory of Constraints terms, the management team chooses to define business agility as the goal of the organisation and makes everything else subordinate to this. Senior execs can get distracted, often by external market or political factors beyond their control, so it is important they have a clear and vocal commitment. At one bank I was working with the CEO ran a kanban board with his management team. They used this to make work visible and to limit the amount of work in process and it was the focus of their daily standup. This said more about his commitment to business agility than any Town Hall address.
Resilient leadership is bigger than a charismatic chief exec. For leadership to be resilient you need leaders up and down the organisation, all committed to a common goal. I advocate two complementary leadership styles, namely servant-leader and leader-leader.
Servant-leader describes a dual role. You are both a servant to your team, ensuring autonomy, and anticipating and meeting their needs, and their leader, setting direction and holding them accountable. Many people professing servant-leadership forget this latter part and just see their role as “protecting” the team, but without direction you lose the alignment across teams. As Kent Beck said, “autonomy without accountability is just vacation.”
Leader-leader is a term coined by former US navy commander David Marquet in his excellent Turn the Ship Around, one of my favourite books on leadership. Each person in the organisation considers themselves the leader of their own area and “expresses intent rather than asking for permission.” In Marquet’s words, the idea is to “move authority to the information” by delegating autonomy, rather than “moving information to the authority” and having decisions bottlenecked at a poorly-informed, senior decision-maker.
Concluding thoughts
If you are already SWARMing you have my respect and admiration. I hope this article helps you identify gaps in your strategy, or at least reaffirms that you have the bases covered. As with any complex adaptive system, the factors I have outlined are all interrelated. Influence can buy you time and investment. Investment will raise the profile of your efforts and can give you more influence. Resilient leadership creates an environment that encourages practise, and so on.
If you are considering a journey towards business agility, be aware there are alternatives to wholesale adoption of scaling frameworks, with their recurring revenue certifications, closed community of self-professed experts, and methodologies that simultaneously promote inspecting and adapting whilst insisting on strict adherence to their branded processes, tools and methods. At best they can cover only a fraction of the landscape I describe above. The rest is down to you and the people you choose to travel with.
Methods like SAFe, LeSS, DAD and others are based on sound principles and may make a useful starting point, for example I have seen DAD used in a number of places to create a consistent initial vocabulary and terminology. But the best person to change your organisation is you, and the best way is however you figure.
Share this:
[…] North, a well-known speaker, author and consultant on all things change-related, took a look at the ways we will be working in a post-transformation workplace, observing that the most […]
Conferences
- Agile Business Conference, London, 26‑27 September
- Test Expo, Agile & DevOps Expo, London, 4 October
- SEACON, London, 12 November
- GOTO Copenhagen, 19‑21 November
- FlowCon, Paris, 27‑28 November
Classes
- Software Faster with Xebia Academy, Hilversum, 9‑10 October, 2‑day masterclass
- Testing Faster at GOTO Copenhagen, 22 November, 1‑day workshop