12 Scaling agility

Big is a collection of smalls.

Nigel Bogle

New ways of working such as Agile, Lean, and Scrum and operating in small, multi-disciplinary teams are not only the domain of startups. With rapidly shifting contexts every company needs to become more adaptive, iterative and emergent, and work to combine functional expertise horizontally across the organization in smarter, more fluid ways. As Silicon Valley entrepreneur and academician Steve Blank has pointed out a startup is not a smaller version of a large company.

As an organization scales, functional groups are an excellent way to optimize efficiency and craft. As it scales and diversifies further to become multi-product, divisions (which each house their own functional groups) allow these efficiency and expertise gains to be extended. But this comes at the expense of structuring for the benefit of the organization, not for the customer. Customers are horizontal. They don’t care about the differences between sales, customer service, or marketing. They don’t care about how company divisions are structured. They just want products that work, and to be able to find solutions to problems easily and quickly. So the need for more seamless customer experience and greater agility creates a heightened horizontal tension and obligation to counteract the constraining impact of organizational silos. Adept collection and application of data can mitigate this (utilizing a ‘single customer view’ in order to join up customer touchpoints and help interaction to be more personalized and intuitive, for example). But the organizational response needs to stretch deeper into processes, culture and, of course, structures.

This means finding better ways to combine the benefits we can derive from unifying expertise in functional groups (HR, finance, sales, marketing, operations), with the ability to capitalize on the agility and momentum that can come from small, multi-disciplinary pods. Organizational systems and ideology are weighted heavily towards optimizing efficiency through functional groups. We need to find a new balance, one that reflects a greater emphasis on learning, velocity, focus and flexibility through agile, iterative, multi-functional pod working.

More commonly iterative methodologies and pod working seeds first in technology teams, centralized digital units, innovation or product development labs and incubators, or standalone catalyst brands that are established to enable a large organization to experiment with new approaches. But confining these ways of working to small units or single teams misses the huge opportunity that companies have to scale agility far more broadly across the organization. We can represent this progression of agility through several distinct stages:

Dispersed mavericks: Restless change agents in dispersed areas of the business recognize the need for different approaches and start to question the status quo and agitate for change. This may initiate pilot projects or minor revisions in local areas efforts are not joined-up and substantive change is difficult in the face of a lack of senior support, and wider organizational complacency.
Focused agility: As the strategic imperative for change takes root at senior levels, investment and resources are allocated towards digital capability development and innovation. New agile ways of working become established in specific areas such as innovation units, catalyst brands, technology teams and digital centres of excellence. Centralization brings focus, a visible statement of intent, easier prioritization, efficiency, better governance and commonality of approach. Iterative, sprint working in small, multi-disciplinary teams enables faster learning and greater experimentation, agile culture and behaviours are nurtured and protected through senior backing and ‘translator’ roles.
Scaling agility: As the need to scale agility becomes more pressing, small multi-functional pod working, and iterative experimentation is expanded beyond tightly focused innovation, technology or digital areas more broadly into the wider organization. This is accompanied by senior vision, communication and support, along with a clear link between corporate and team strategy, objectives, execution and measures. Over time the proportion of the workforce that is working in this way increases.
Dispersed agility: As agility naturally scales ever wider, it becomes essential for the business to manage the ever-fluid proportion of staff that are working in multi-functional pods, and continually balance that with the efficiency and craft benefits gained from functional groups. Ongoing sensitivity to the type, scale and scope of customer needs, and the ability of the business to respond to these and other contextual challenges is key.

The stage when we are looking to scale agility can be particularly challenging. It is at this point that we are expanding new approaches, behaviour and culture beyond an isolated area, so a senior mandate, permission to fail-safe but to orient to learning becomes critical to success. Initial focus may be on setting up small multi-functional teams to address key business challenges through iteration and experimentation. Or establishing areas at a divisional level that can enable the introduction of these new ways of working focused on divisional priorities – more of a hub-and-spoke model to scaling agile working.

Exposure to agile working and culture can support wider adoption over time. This might come via staff, functions and teams that interface regularly with already agile areas (osmosis). Or wider assimilation through deliberately including an ever-wider coterie of staff to experience agile working and be included in pod team working (diffusion). Or encouraging the larger organization to learn from catalyst brand initiatives (mother-learns-from-baby).

Businesses cannot go from a rigid, functionally oriented state to a highly fluid, agile, learning-oriented organization overnight. The staged approach allows for proper establishment of supporting structures and cultures, and the proportion of workforce that is ultimately working in pod-like structures is likely to be fluid.

To see an exemplar of scaling agile structures, we can look at Spotify. Agile and organizational coaches at Spotify, Henrik Kniberg and Anders Ivarsson, have detailed an approach that the company has adopted successfully, focused on what they call Squads, Tribes, Chapters and Guilds.¹ Spotify has scaled more rapidly than most companies but the structure that they have adopted in their engineering teams is specifically designed to maintain an uniquely advantageous level of agility across 30 teams and three cities.

The basic unit of development at Spotify is the ‘Squad’, a small, nimble, multi-disciplinary, autonomous self-organizing team that is designed to feel like a mini-startup. Squads are co-located and focus on specific areas of the product or service, incorporating all the tools and skills they need to take an idea from design to test to release and production. Much like Amazon’s two-pizza teams, Squads are clearly focused on a specific task and KPI.

Squads are grouped together into related product areas called ‘Tribes’. Tribes are like the incubator for the squad mini-startups and designed to be no larger than 100 people. Specific processes help minimize the potential of dependencies to slow things down.

‘Chapters’ and ‘Guilds’ link Squads horizontally together, enabling some economies of scale without sacrificing autonomy, and acting like the glue that binds the company together. Chapters group together people with similar functional expertise and meet regularly to share learnings. The Chapter lead is the line manager for chapter members and has more traditional staff-management responsibilities, but is also a member of a Squad themself so stays in touch with the work. Guilds are looser, more organic and wide-reaching communities of interest that can stretch across the whole company (rather than just how a Tribe like a Chapter does). They enable knowledge and tool-sharing across a wider group.

As Kniberg and Ivarsson describe it, it is like a matrix organization but one that is weighted towards delivery. The structure is a departure from typical organizational approaches in that rather than people being grouped into vertical silos defined by function, the vertical dimension is customer and product focused, and defined by those multi-disciplinary, self-organizing, co-located Squads, while the horizontal dimension is all about sharing knowledge, best practice, learning and tools.

The risk in having a looser organizational structure focused around small, nimble teams is that an increased level of complexity is created through a greater number of dependencies, coordination issues, a possible lack of focus on developing vertical functional expertise, and the difficulty in effectively sharing learning horizontally across the organization. What’s interesting about Spotify’s approach is that it specifically finds ways to avoid those potential pitfalls, while making for a customer focused structure that is far more flexible and empowering, and one that can be far more adaptive at scale.

Managing core teams and dependencies

When scaling agile working and small multi-functional teams through the organization we need to remove barriers to ensure that they can move fast. An important part of this, as we have discussed, is being ruthless about keeping the team small. But we also need to ensure that teams have the necessary support and input they require, what they need when they need it, in order to generate and maintain momentum.

The model of Agile team onions (Figure 12.1), originated by Agile practitioner Emily Webber, is a way of structuring dependencies which, in a large organization may be required functional inputs (perhaps ops, legal, finance and so on) that are involved in some way in delivery but which are still situated in vertical silos, around the core team.² The onion is a way of creating understanding about who is in the wider team, and inviting them in without disrupting the small (and effective) size of the core team:

Figure 12.1 The Agile Team Onion

This isn’t just a stakeholder map, it is about bringing the organization in and having shared responsibility for what you are creating together.

The onion is classified thus.

Core team

Purpose: delivery of digital services
Communication: daily (all stand-ups, retrospectives, planning, show and tells)
Co-located: daily, all day
Types of people: product owner, scrum master, developers, designers, etc.

Collaborators (who might be working on multiple teams)

Purpose: bring in specialist information to assist the team, assurance as needed, reduce dependencies and blockers (open doors)
Communication: regularly, they come to some agile meetings
Co-located: on a regular basis (as a guide ~2 days a week) – this also depends on what is needed and the phase of project – but enough to be able to not block anything
Types of people: other delivery teams working within the same portfolio, security liaison, policy liaison, portfolio manager, operations, suppliers, etc.

Supporters

Purpose: keep informed, feed into broad organizational priorities
Communication: every sprint/iteration (show and tells, ad-hoc when needed)
Co-located: monthly or as needed
Types of people: steering groups, wider organization.

Mapping out your team onion, inviting people in, agreeing expectations and protocols establishes the right footing for it all to work. So, ultimately, an organization may consist of many overlapping onions (Figure 12.2).

Figure 12.2 Overlapping onions

In this way, the core team is kept at a suitable size to maintain velocity, collaborators provide necessary inputs to maintain momentum, and supporters remove barriers and provide direction to empower agility.

Getting the right mix: pioneers, settlers, town planners

David Smith, of Global Futures and Foresight, has written about³ achieving effective change through a model which positions the right person in the right place at the right time. It’s interesting, says David, that the business world has more recently prized leadership over managers and entrepreneurs when, of course, all three are critical to the effective running of a business. Yet they are very different beasts:

The Entrepreneur: dreams about the future, is strong on ideas, and brilliant at vision.
The Leader: plans for tomorrow, is strong on people and brilliant at behaviour.
The Manager: delivers today, is strong on process, and brilliant at capability.

Entrepreneurs in companies are the ideas people who often end up being put in charge of building new capability or business units. But once those units are established they require managers to extract the full value or generate sustainable sales or greater ongoing efficiencies.

Conflict can occur between entrepreneurs and managers as the former struggle to get the latter onside with new ideas, and the latter despair of getting the former to appreciate the nuances of running the ongoing business. As entrepreneurs are focused more on the ideas of tomorrow, and managers more on the business of today, the former may see the latter as ‘change blockers’. Once a new venture has been created, entrepreneurs may be less equipped or enthused to optimize the venture on an ongoing basis and so may be moved out of the business rather than be assigned the next entrepreneurial challenge, resulting in innovation loss for the company. For this reason, says David, more entrepreneurs feel that they don’t belong on corporate world and so end up in SMEs.

But all three are, of course, essential. Leaders need entrepreneurs (to identify and capitalize on ideas), and entrepreneurs need leaders (so that they are not working in isolation). Both need managers who can take innovations and make them work, and managers in turn need leaders and entrepreneurs. Everyone has a profile that mixes these three attributes to a greater or lesser degree, and it goes without saying that where things go wrong is where someone’s profile is mismatched to the role that they find themselves in. In the context of achieving change, awareness of the profiles enables you to identify where support for the change will come from, and where there might be blockers. In the context of a senior team in the corporate environment, leadership may be overvalued (everyone wants to be a leader) at the expense of entrepreneurs and managers, resulting in an imbalance.

We need to ensure that our best talent is oriented towards opportunity, not just to efficiency. Putting the right people to work on the wrong thing can have a disastrous impact. Take Microsoft, a business that many believe badly trailed its competitors in its development of key technologies including mobile. In a 2014 Vanity Fair article on Microsoft, Steve Ballmer talked about the cost of the misalignment of the talent that the company had:

The worst work I did was from 2001 to 2004. And the company paid a price for bad work. I put the A-team resources on Longhorn, not on phones or browsers. All our resources were tied up on the wrong thing.⁴

Researcher Simon Wardley has described an approach that brings together the unique combination of resourcing characteristics needed to bring products and services to life (in a concept itself adapted from Robert X Cringely’s description of companies in terms of Commandos, Infantry and Police).⁵ Pioneers, settlers and town planners are each brilliant in their own way, but demonstrate different attributes:

Pioneers: have the ability to explore uncharted territory and generate entirely new concepts: ‘They show you wonder but they fail a lot.’
Settlers: can turn incomplete ideas into something useful for a larger audience, make prototypes into products, commercialize, build understanding and trust: ‘They make the possible future actually happen.’
Town planners: are able to industrialize young products to capitalize on economies of scale: ‘You trust what they build. They find ways to make things faster, better, smaller, more efficient, more economic and good enough.’⁶

While pioneers will be experimenting iteratively, prototyping in-house, using agile working and techniques, settlers may be utilizing more off-the-shelf technologies, tapping into ecosystems, using lean methodologies, and town planners will likely be using existing tools to drive efficiency, perhaps outsourcing, and maybe even using more traditional waterfall development. Each of these stages are critical in the agile organization, and great people are needed in each of these roles to create the right combination that can not only generate new ideas, but also commercialize and scale them at pace. There is even the potential to deploy small, multi-functional pods to fulfil each stage of this process.

While the pioneers may logically sit within the innovation area or digital team, and the town planners within vertical functions, the settler stage is a key one. During this phase the concept or project may start as an early stage prototype that has established an early value proposition and product-market fit, but then needs to be properly commercialized, and the business model and proposition developed to make it repeatable and ready for scale. The inherent dangers at this point are that the concept moves out of the innovation area, straight into business-as-usual functions where it is saddled with a short-term profit target and given to a functional leader and staff who have not been invested in the idea from the start. Under these burdensome conditions, the idea (even if it is a great one) will often wither and die. There are several factors that can instead contribute to success:

A clearer metrics journey that can show early stage value before revenue (see ‘Pirate Metrics’ in Part Two).
Senior patronage, and a clear understanding of the role of the new initiative in progressing towards a long-term vision.
A continuum of resourcing on the project – key people who have been there from the start continuing to work on it. The balance here is ensuring that pioneers, adept at ideation, rapid experimentation and prototyping, are not being forced unnecessarily to play the role of the settler.
Resourcing dedicated to the commercialization of early stage ideas. Sometimes, with the right support, the same team can take an idea through from initial concept to commercialization. But even a startup adapts its skill base in tune with these critical stages. So more commonly in a large organization we need committed staff with the right expertise, or a multi-functional team specifically focused on establishing scale and economic viability. We need not only systematic ways of testing new ideas, but also disciplined ways of commercializing the ones that show early stage promise.

Figure 12.3 Attributes of pioneers, settlers and town planners

We need to create the conditions in which each phase can feed off the others. This is about building a systemic way to orient the organization towards not only continuous experimentation but also continual commercialization and scaling of early stage ideas.

Agile decision-making: flatter structures, quicker decisions

The primary purpose of the organizational hierarchy in a company is decision-making efficiency.

Ben Horowitz⁷

Here’s a scenario. The CEO needs to do a big review presentation. So they ask five of their direct reports to help put it together. Those five leaders brief five of their subordinates to compile the material. Those five subordinates brief out another five of their juniors asking for specific information. Each of those stages requires just two meetings between each of the individuals involved (briefing and review), and perhaps five e-mails. A not unreasonable scenario and yet that is already 156 people, 310 meetings, 775 e-mails for one presentation. Over-burdensome hierarchy creates its own over-burdensome process. And it can be paralysing.

Consider a second scenario. A team wants to implement a change that will support one of their objectives but which impacts another team’s activity. In an overly hierarchical business the proposal gets passed up the line to the department head, who engages the head of the other team in trying to win support for their initiative. The other department head consults their own team to understand the implications of the change. In the absence of appropriate data, the decision becomes drawn out and protracted as the department heads go back and forth to negotiate a solution they are both happy with. Instead of being dealt with quickly at an appropriate level, multiple decisions are passed up the line, across, down the line, and back again. Time passes. Projects are stalled.

In order to move quickly it is essential in a large organization (particularly in the context of leading transformation) to invest time in understanding where decision-making and influence resides. In other words, to know ‘who’s who in the zoo’. Attempting to implement change that carries dependencies without the support of key stakeholders or influencers within the organization will at best slow things down and at worst result in failure. Simple frameworks such as RACI (Responsible, Accountable, Consulted, Informed) are useful not only in assigning and managing responsibilities, but also in determining the required actions necessary to smooth the process of change and ensure continued support.

Over time, the number of managerial layers in large organizations seems only to increase; yet flatter structures reduce unnecessary communication and expedite speed of decision-making. The secret is to have just enough hierarchy. Yet reaping the benefits of a flatter business is not just about formal structures. Decision-making needs to be empowered with ease of access to relevant data, and the kind of culture that is not suffocated by internal politics. Effortless access to the right data at the right time (through dashboarding, for example) can bring agility by supporting and removing contention around a proposed course of action. Teams that have access to relevant data make better decisions. Companies that make that data easy to access enable their staff to make those better decisions faster.

Similarly, senior perks and other visible symbols of status might make a few staff feel self-important but are largely counter-productive to open communication and can be a barrier to just getting the job done. Are executive floors, large exuberant offices, and other visible perks of seniority really necessary?

When he was CEO of successful work productivity company Evernote, Phil Lipin said that such signals: ‘create artificial barriers to communication. They create artificial things that people focus on rather than just getting their job accomplished’.⁸ Eliminating all distractions so you can just focus on achieving means that you attract people who are primarily motivated by how much they achieve.

We should all be passionate in the pursuit of maintaining decision-making structures that enable clarity of responsibility and authority while preventing redundant or avoidable hierarchy and process.

Agile governance and the digital board

If the rate of change on the outside exceeds the rate of change on the inside, the end is near.

Jack Welch

Slow decision-making can be anathema to effective digital management and transformation. As the pace of digital development accelerates and pressure on resources intensifies, one of the key challenges that arise in organizations undergoing digital transformation is the effective prioritization of digital projects and developments. There is just so much to do, so many different (and potentially competing) priorities that it can be hugely difficult for those at the top tier to know the right thing to do (especially if their level of knowledge of all things digital is not what it could be).

The issue is often not about the level of comparative significance attributed to digital developments by the company board, nor their visibility among the most senior staff of the company. A more likely scenario is that while an organization may already have digital development as a strategic pillar of the corporate strategy, the difficulty comes in taking account of multiple dependencies or risk factors and in elucidating and defining a priority list that will ensure that the most meaningful and impactful changes are prioritized above those which may have less significance. Sometimes impact is difficult to demonstrate or even to determine. Sometimes changes that have short-term impact might be unfairly or misguidedly prioritized over those with potentially much larger long-term impact. Sometimes involvement of multiple senior-level stakeholders slows the decision-making down to the point where the impact of development is negated.

Companies might try to mitigate this risk by appointing digitally savvy people to the board, or having a board member take responsibility for becoming a digital ‘champion’. Both of these options can help. Yet there can be little substitute for a board that is conversant and experienced as well as informed. The broader this capability across the board the better. Every company is operating in a digitally empowered world, which means there is now little excuse for lack of board level competency and proficiency.

Outside of board meetings, decision-making structures need to be agile in support of an empowered board. Clear delineation of responsibility helps. Peter Thiel has said:

The best thing I did as a manager at PayPal, was to make every person in the company responsible for doing just one thing. Every employee’s one thing was unique, and everyone knew I would evaluate him only on that one thing.⁹

While the clarity, focus and simplicity that this brings may reap dividends for startups and small businesses, as a company scales applying this approach to small teams rather than individuals is likely to be easier. Clear and sensible escalation procedures also help.

More formalized decision-making and feedback structures such as the creation of a ‘digital board’ can, however, prove to be extremely valuable in facilitating agile governance while providing a crucial link to most crucial decision-making body in the company: the main board.

A ‘digital board’ might typically comprise key main board members (the board ‘digital champion’, or Finance Director or perhaps even the Managing Director or CEO) and other principal digital stakeholders, and becomes the main decision-making body for the digital development roadmap, meeting regularly to make key investment and strategy decisions.

This ensures the ongoing commitment, involvement and engagement of key senior staff including the CEO, CFO, and/or the IT and Operations Director, provides a crucial link between digital operations and the main board, while still keeping the decision-making process as agile possible.

Notes

1 Henrik Kniberg and Anders Ivarsson (October 2012) Scaling Agile @ Spotify, with Tribes, Squads, Chapters and Guilds, [Online] https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf [accessed 25 October 2016]

2 Emily Webber, 14 May 2016, The Agile Team Onion. How many pizzas does it really take to feed your team?, Emily Webber http://emilywebber.co.uk/agile-team-onion-many-pizzas-really-take-feed-team/ [accessed 25 October 2016]

3 David Smith (26 October 2016) Effective Business Change: Right person, right place, right time, Global Futures and Foresight, [Online] http://thegff.com/Articles/205178/Global_Futures_and/Methods_and_tools/Effective_Business_Change.aspx [accessed 25 October 2016]

4 Bethany McLean (November 2014) The Empire Reboots, Vanity Fair, [Online] http://www.vanityfair.com/news/business/2014/11/satya-nadella-bill-gates-steve-ballmer-microsoft [accessed 25 October 2016]

5 Robert X Cringely (4 April 1996) Accidental Empires: How the boys of Silicon Valley make their millions, battle foreign competition and still can’t get a date, 2nd revised edition, Penguin Books Ltd, ISBN-10 140258264 ISBN-13 978–0140258264

6 Simon Wardley (13 March 2015) On Pioneers, Settlers, Town Planners and Theft, Gardeviance.org, [Online] http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html [accessed 25 October 2016]

7 Ben Horowitz (24 April 2014) The Hard Thing About Hard Things: Building a business when there are no easy answers, Harper Business, ISBN-10 62273205 ISBN-13 978–0062273208

8 Adam Bryant (7 April 2012) The Phones Are Out, but the Robot Is In, New York Times, [Online] http://www.nytimes.com/2012/04/08/business/phil-libin-of-evernote-on-its-unusual-corporate-culture.html?pagewanted=all&_r=1 [accessed 25 October 2016]

9 Peter Thiel and Blake Masters (16 September 2014) Zero to One: Notes on startups, or how to build the future, Crown Business, ISBN-10 804139296 ISBN-13 978–0804139298