Product Details Lean Enterprise: How High Performance Organizations Innovate at Scale (2015)
Part IV. Transform
Chapter 15. Start Where You Are
If you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.
A year from now you will wish you had started today.
Our goal with this book is to inspire you to envision an alternative future for large organizations. A future that puts employees, customers, and products at the heart of its strategy. A future where a renewed culture and environment enable the organization to adapt rapidly to changing market demands.
We have shared stories and lessons learned from a diverse set of organizations with varied backgrounds and circumstances to highlight that even in complex environments, you can thrive and address the most challenging problems. However, the path to success is not likely to be linear, with defined instructions, milestones, and KPIs. Organizations needed to get comfortable moving forward with uncertainty and imperfect information, while learning, adjusting, and developing their people along the way.
The biggest barrier to success in changing the way you work is a conviction that your organization is too big or bureaucratic to change, or that your special context prevents adopting the particular practices we discuss. Always remember that each person, team, and business that started this journey was unsure of what paths to take and how it would end. The only accepted truth was that if they failed to take action, a more certain, negative ending lay ahead.
Principles of Organizational Change
All change is risky, particularly organizational change which inherently involves cultural change—the hardest change of all, since you are playing with the forces that give the organization its identity. We are still amazed when leaders plan “organizational change” programs that they expect to complete in months. Such programs fail to recognize that turning innovation or change into an event rather than part of our daily work can never produce significant or lasting results. Periodically funding a new change program in response to current issues, leadership changes, or market trends without instilling a culture of experimentation will only achieve short-term incremental change, if any at all (Figure 15-1). Organizations will quickly slip back to their previous state. Instead, we must create a culture of continuous improvement through the deliberate, ongoing practice of everyone in the organization.
Figure 15-1. The reality of “event-based” change programs
If your organization is waiting for an event to stimulate change, you’re already in trouble. In the current environment and competitive economy, a sense of urgency should be a permanent state. Survival anxiety always exists in leading organizations, as we describe in Chapter 11. However, as Schein noted, using it as a motivator for ongoing change is ineffective. The only path to a culture of continuous improvement is to create an environment where learning new skills and getting better at what we do is considered valuable in its own right and is supported by management and leadership, thus reducing learning anxiety. We can use the Improvement Kata presented in Chapter 6 to create this culture and drive continuous improvement (Figure 15-2).
Figure 15-2. Continuous evolution and adaption to change
In order to propagate the Improvement Kata through organizations, managers must learn and deploy a complementary practice known as the Coaching Kata251 To start the journey, an advance team including an executive sponsor—ideally, the CEO—should pilot the Coaching Kata and the Improvement Kata. As this team will guide wider adoption within the organization, it is imperative that they understand how it works.
Watch out for the following obstacles:
§ Adopting the Improvement Kata requires substantial changes in behavior at all levels of the organization. The Coaching Kata is used to teach people the Improvement Kata, but the problem of how to deploy the Coaching Kata within an organization remains significant.
§ Running experiments is hard and requires great discipline. Coming up with good experiments requires ingenuity and thought. By nature, people tend to jump straight to solutions instead of first agreeing on measurable target objectives (outcomes) and then working in rapid cycles—and by rapid, we mean hours or days—to create hypotheses, test, and learn from the results. The body of knowledge on how to design and run experiments in the context of product development is still in its early stages, and the necessary skills and techniques are not widely known or understood.
§ Ensure there is capacity to run the Improvement Kata. One of the biggest obstacles teams face when trying to schedule improvement work is that it is often seen as a distraction from delivery work. This is a fallacy, and the point must be made early and forcefully. In the HP FutureSmartcase, the reason delivery work was progressing so slowly was that no-value-add work was driving 95% of their costs. It is vital for executives at the director or VP level to ensure that teams limit their work in process as described in Chapter 7 to create time for improvement work.
§ As with all methods, progress is likely to be bumpy at the beginning as people learn how to work in new ways. Things will get worse before they get better. Resistance is likely as people learn the new skills, and some will become frustrated when it conflicts with their existing habits andbehaviors.
Aim Towards Strategy Deployment
Although we discussed the Improvement Kata as a way to drive continuous improvement at the program level, it can be used at every level from individual teams up to strategic planning. To apply the Improvement Kata at the strategic planning level, start by agreeing on the purpose of the organization. What is it that we aim to do for our customers? Then, those participating in the strategic planning exercise must define and agree upon the overall direction of the company—identify our “true north.”
The next step is to understand and clarify our organization’s current situation. Participants in the strategic planning exercise should identify which problems need to be addressed and gather data to better understand each problem. Typically, even large organizations have limited capacity and can manage only a handful of initiatives at any one time; choosing what not to focus on and making sure the team sticks to its decision is critical. An economic framework such as Cost of Delay (see Chapter 7) is useful to stimulate discussion about prioritizing work.
Once we have decided what problems to focus on, we need to define our target conditions. These target conditions should clearly communicate what success looks like; they must also include KPIs so we can measure our progress towards the goal. The traditional balanced scorecard approach to KPIs has four standard perspectives: finance, market, operations, and people and organization. Statoil, borrowing from the balanced scorecard approach in their Ambition to Action framework (Chapter 13), added HSE (health, safety, and environment). The lean movement teaches us to focus on reducing cost and improving quality, delivery, morale, and safety (these five “lean metrics” are sometimes abbreviated as QCDMS). Bjarte Bogsnes, vice president of Performance Management Development at Statoil, recommends choosing 10–15 KPIs and preferring relativetargets that connect input with outcomes (for example, unit cost rather than absolute cost) and are based on comparison with a baseline (for example, “10% higher return on capital investment than our leading competitor”).252
The target objectives at the strategic level form the direction for the next organizational level, which then goes through its own Improvement Kata process. The target objectives at this level then form the direction for the next organizational level down, as shown in Figure 15-3. This process, allowing us to set targets and manage resources and performance by creating alignment between levels in the organization, is called strategy deployment (otherwise known as Hoshin or Hoshin Kanri; Ambition to Action is a variation of strategy deployment).253
The process of creating alignment and consensus between levels is critical. In strategy deployment, this process is described as catchball, a word chosen to evoke a collaborative exercise. The target conditions from one level should not be transcribed directly into the direction for teams working at the level below; catchball is more about translation of strategy, with “each layer interpreting and translating what objectives from the level above mean for it.”254 We should expect that feedback from teams will cause the higher-level plan to be updated. Don’t subvert Hoshin by using it to simply cascade targets down through the organization: the key to Hoshin is that it is a mechanism for creating alignment based on collaboration and feedback loops at multiple levels.
The time horizons for each level should be clearly defined, and regular review meetings scheduled, with target objectives updated based on the progress of the next-level teams. To be truly effective, this conversation must also be cross-functional, promoting cooperation along value streams, within and between business units. It’s not easy, as it requires honest listening to the ideas and concerns of the people responsible for results—and responding by adjusting the plans based on feedback.255
Figure 15-3. Using catchball to drive strategic alignment of objectives and initiatives
A top-level strategy planning exercise can have a horizon of six months to a few years, depending on what is appropriate to your business. Review meetings should be held at least monthly where the team, along with the leaders of all teams that report to them, gather to monitor progress and update target conditions in response to what they discover. Teams at lower levels will typically work to a shorter horizon, with more frequent review meetings.
Strategy deployment is an advanced tool that depends on the aligned culture and behaviors, as we describe in Chapter 11. The main goal is to create consensus and alignment and enable autonomy across the organization, following the Mission Command paradigm presented in Chapter 1.Let’s look at how the UK government applied a version of strategy deployment to transform its use of digital platforms to provide services to citizens, starting small and growing iteratively and incrementally.
The UK Government Digital Service
The UK government, like many others, has recognized the potential of the Internet “both to communicate and interact better with citizens and to deliver significant efficiency savings.”256 However, government projects involving software development have a checkered past. The UK government had several large IT projects go enormously over budget while failing to deliver the expected benefits, culminating in the “National Programme for IT” debacle. The world’s biggest civil information technology program, supposed to deliver a completely new IT infrastructure for the British National Health Service and a computerized patient record system, was projected to cost £2.3bn at its inception in 2002. Its delivery was outsourced to multiple private sector providers including Accenture, Computer Sciences Corporation, Fujitsu, and British Telecom. Despite the cancellation of the programme in 2011, it is expected to end up costing over £10bn.
The government procurement process for large IT projects involved writing a complete specification for the product, creating several business cases at increasing levels of detail, and then putting the contract out for bidding—a process that required one to two years before work could even start on the product. “By which time,” comments Francis Maude, Minister for the UK’s Cabinet Office, “it will almost certainly be out of date. You’re locked into a supplier, it’s really expensive to make changes.”257
As a result of the outsourcing of IT projects, every government department had their own independently designed and operated web presence, with dissimilar user experiences that reflected each department’s internal organization. It was complicated and extremely painful for citizens to use, so they preferred to use more expensive channels of service such as walk-in, mail, and phone services.
In 2010, Martha Lane Fox, co-founder of UK startup lastminute.com, was commissioned to advise the UK government on its strategy for online delivery of public services. Her report recommended creating a central team of civil servants responsible for designing and delivering the government’s online presence, implementing an open data policy whereby all government data was made available through public APIs, and appointing a CEO “with absolute authority over the user experience across all government online services (websites and APIs) and the power to direct all government online spending.”258 Thus the UK’s Government Digital Service (GDS) was born. Martha Lane Fox described her goals for the GDS as follows: “For me, the acid test…is whether it can empower, and make life simpler for, citizens and at the same time allow government toturn other things off. A focus on vastly increasing the range, usage, and quality of online transactions will deliver the greatest impact: less hassle for citizens & businesses, and greater efficiency.”
GOVERNMENT DIGITAL SERVICE CASE STUDY, BY GARETH RUSHGROVE
GOV.UK is the new single domain for all central government services in the UK. It was launched in October 2012 and replaced two of the largest existing government websites on day one, going on to replace all central government department sites over the next few months. By 2014 we will have closed thousands of websites and built a single service that is simpler, clearer, and faster, covering everything from information about benefits you may be eligible for to how to apply for a passport.
One aspect of GOV.UK that sets it apart from a typical government project is that it was developed nearly completely in-house, by civil servants working for the newly formed Government Digital Service (GDS), part of the UK Cabinet Office. It was also built iteratively, cheaply, and using agile methods and technologies more commonly associated with startups than large organizations. Here is a description of how that was done.
Alpha and Beta
By late 2013 the team running GOV.UK had over 100 people—but it didn’t start that way. In fact, the first version wasn’t even called GOV.UK. An Alpha version was built by 14 people working from a small back room in a large government building. Its aim wasn’t to be a finished product but to provide a snapshot of what a single government website could be, and how it could be built quickly and cheaply. In total, the Alpha took 12 weeks and cost £261,000.
The feedback from users of the Alpha led directly to work on a Beta, which scaled up the Alpha proposition and involved more people from across government. The first release of the Beta was six months after the Alpha project shipped, but this included time to build up the team. The first public Beta release was a real government website, but at the time it lacked all the content and features needed to replace the existing main government sites. Eight months of constant iterations later, with the team up to 140 people and with new content and features added daily, traffic was redirected from two of the largest government websites to the new GOV.UK.
All this work paid off. During the financial year 2012–2013, GDS saved £42 million by replacing the Directgov and BusinessLink websites with GOV.UK. In 2013–2014, it is estimated GDS will save £50 million by closing more websites and bringing them onto the single domain.
The Government Digital Service is made up of specialists in software development, product management, design, user research, web operations, content design, and more, as well as specialists in government policy and other domain-specific areas. From this group of specialists, teams were formed to build and run GOV.UK. Those teams did not have a narrow focus, however; most of them were multidisciplinary, made up of people with the right mix of skills for the tasks at hand.
As an example, the team that worked on the initial stages of the Beta of GOV.UK consisted of seven developers, two designers, a product owner, two delivery managers, and five content designers. Even within these disciplines, a wide range of skills existed. The developers had skills ranging from frontend engineering to systems administration.
By employing multidisciplinary teams, the end-to-end responsibility for entire products or individual tasks could be pushed down to the team, removing the need for large-scale command and control. Such small self-contained teams had few dependencies on other teams so could move much more quickly.
This multidisciplinary model also helped to minimize problems typical in large organizations with siloed organizational structures. For instance, the Government Digital Service has grown over time, adding experts in government information assurance, procurement, and IT governance to avoid bottlenecks and improve the prioritization of resources.
An important aspect of the success of GOV.UK has been constant improvement based on user feedback, testing, and web analytics data. The GOV.UK team releases new software on average about six times a day—with all kinds of improvements, from small bug fixes to completely new features, to the site and supporting platforms.
After the launch of the Beta of GOV.UK, one of the product managers, with bad memories of releasing software at other organizations, asked whether the software deployment mechanism was really going to work. The answer was “yes”: at that point, GDS had done more than 1,000 deployments, so there was a high level of confidence. Practiced automation makes perfect.
This rate of releases is not typical for large organizations where existing processes sometimes appear designed to resist all change. The development teams working on GOV.UK worked extensively on automation, and they had in-depth conversations with people concerned about such rapid change. The key term when discussing this approach was risk—specifically, how regular releases can manage and minimize the risks of change.
Most people are bad at undertaking repetitive tasks, but computers are perfect for automating these tasks away. Deployment of software, especially if you are going to do it regularly, is a great candidate for automation. With the development and operation of GOV.UK, this was taken even further: provisioning of virtual machines, network configuration, firewall rules, and the infrastructure configuration were all automated. By describing large parts of the entire system in code, developers used tools like version control and unit testing to build trust in their changes, and focused on a smaller set of well-practiced processes rather than a separate process (and requisite specialist skills) for each type of change.
Other techniques helped too. A relentless focus on users and a culture of trust from the very top of the organization have put GDS in a position to take much of what it learned building and running GOV.UK and use that to transform the rest of the UK government.
The GDS approach has been adopted by all arms of the government, with transformative results for citizens. To take just one example, the UK Ministry of Justice Digital Team recently worked with the National Offender Management Service and HM Prison Service to change the way people book prison visits. Previously, visitors had to request paper forms to be mailed out and then got on the phone to book a visit. Requests were often rejected because the date was unavailable, forcing people to start over. Now, prison visits can be booked online in 5 minutes, selecting from up to three dates.259
Not everybody is thrilled with the idea of governments growing their own IT capabilities. Tim Gregory, the UK president of CGI, the biggest contractor for the US HealthCare.gov website that received a contract valued at $292 million through 2013 before being replaced by Accenture in January 2014,260 argues that the GDS approach will make it unprofitable for large outsourcing vendors to bid for government projects. GDS Executive Director Mike Bracken describes Gregory’s view as “beyond parody.”261
There are several observations to be made from the GDS case study.
First, starting small with a cross-functional team and gradually growing the capability of the product, while delivering value iteratively and incrementally, is an extremely effective way to mitigate the risks of replacing high-visibility systems, while simultaneously growing a high-performance culture. It provides a faster return on investment, substantial cost savings, and happier employees and users. This is possible even in a complex, highly regulated environment such as the government.
Second, instead of trying to replace existing systems and processes in a “big bang,” the GDS replaced them incrementally, choosing to start where they could most quickly deliver value. They took the “strangler application” pattern presented in Chapter 10 and used it to effect both architectural and organizational change.
Third, the GDS pursued principle-based governance. The leadership team at GDS does not tell every person what to do but provides a set of guiding principles for people to make decisions aligned to the objectives of the organization. The GDS governance principles state:262
1. Don’t slow down delivery.
2. Decide, when needed, at the right level.
3. Do it with the right people.
4. Go see for yourself.
5. Only do it if it adds value.
6. Trust and verify.
People are trusted to make the best decisions in their context, but are accountable for those decisions—in terms of both the achieved outcomes and knowing when it is appropriate to involve others.
Finally, the GDS shows that extraordinary levels of compensation and using a private sector model are not decisive for creating an innovation culture. GDS is staffed by civil servants, not Silicon Valley entrepreneurs with stock options.263 An innovation culture is created by harnessing people’s need for mastery, autonomy, and purpose—and making sure people are deeply committed to the organization’s purpose and the users they serve.
Begin Your Journey
Use the following principles for getting started:264
Ensure you have a clearly defined direction
The direction should succinctly express the business or describe organizational outcomes you wish to achieve in measurable terms, even if they look like an unachievable ideal. Most importantly, it should inspire everyone in the organization. Think of HP FutureSmart’s goal of 10x productivity improvement.
Define and limit your initial scope
Don’t try to change the whole organization. Choose a small part of the organization—people who share your vision and have the capability to pursue it. As with the GDS, start with a single, cross-functional slice, perhaps a single product or service. Make sure you have support at all levels from executives down and from shop floor up. Create target objectives, but don’t overthink them or plan how to achieve them. Ensure the team has what they need to experiment, follow the Improvement Kata, and iterate.
Pursue a high-performance culture of continuous improvement
Perhaps the most important outcome of deploying the Improvement Kata is to create an organization in which continuous improvement is a habit.
Start with the right people
New ways of working diffuse through organizations in the same way other innovations do, as we describe at the beginning of Chapter 2. The key is to find people who have a growth mindset (see Chapter 11) and are comfortable with trying out new ideas. Once you have achieved positive results, move on to the early adopters, followed by the early majority. The rest is relatively easy, because there’s nothing the late majority hates more than being in the minority. This approach can be applied for each of the three horizons described in Chapter 2.
Find a way to deliver valuable, measurable results from early on
Although lasting change takes time and is never completed, it is essential to demonstrate real results quickly, as the GDS team did. Then, keep doing so to build momentum and credibility. In fact, the Improvement Kata strategy is designed to achieve this goal, which we hope will make it attractive to executives who typically have to demonstrate results quickly and consistently on a tight budget.
As you experiment and learn, share what works and what doesn’t. Run regular showcases inviting key stakeholders in the organization and your next adoption segment. Hold retrospectives to reflect on what you have achieved and use them to update and refine your vision. Always, keep moving forward. Fear, uncertainty, and discomfort are your compasses toward growth. You can start right now by filling out the simple one-page form shown in Figure 15-4 (see Chapter 11 for more details on target conditions). For more on how to create sustainable change, particularly in the absence of executive support, we recommend Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising.265
Figure 15-4. Draft transformation plan
Creating a resilient, lean enterprise that can adapt rapidly to changing conditions relies on a culture of learning through experimentation. For this culture to thrive, the whole organization must be aware of its purpose and work continuously to understand the current conditions, set short-term target conditions, and enable people to experiment to achieve them. We then reassess our current conditions, update our target conditions based on what we learned, and keep going. This behavior must become habitual and pervasive. That is how we create a mindset of continuous improvement focused on ever higher levels of customer service and quality at ever lower costs.
These principles are the threads that link all scientific patterns together. Whether you’re seeking a repeatable business model through the Lean Startup learning loop, working to improve your product through user research and continuous delivery, or driving process innovation and organizational change using PDCA cycles of the Improvement Kata—all that is based on a disciplined, rigorous pursuit of innovation in conditions of uncertainty. That the same principles are at the heart of both lean product development and effective process and cultural change was an epiphany for the authors of this book, but perhaps it should not be a surprise—in both cases we face uncertainty and have to deal with a complex adaptive system whose response to change is unpredictable. Both these situations call for iterative, incremental progress, achieved through human creativity harnessed by the scientific method.
Organizations must continually revisit the question: “What is our purpose, and how can we organize to increase our long-term potential and that of our customers and employees?” The most important work for leaders is to pursue the high-performance culture described in this book. In this way, we can prosper in an environment of constant advances in design and technology and wider social and economic change.
251 For free materials on the Improvement Kata and Coaching Kata, see http://bit.ly/1v73SSg.
252 [bogsnes], pp. 125–126.
253 For a detailed description of Ambition to Action, see [bogsnes], pp. 114–169.
254 [bogsnes], p. 124.
255 Find out more about strategy deployment in Chapter 3 of Karen Martin’s The Outstanding Organization [martin-12], and read a case study at http://www.lean.org/Search/Documents/54.pdf.
260 Reuters: “As Obamacare tech woes mounted, contractor payments soared,” http://reut.rs/1v741oJ.
262 GDS Governance principles, http://bit.ly/1v747fT.
263 In fact, the relatively low probability of a startup “exiting” successfully means that, for purely financial reasons, you’d be crazy to prefer a job at a startup over a solid position at (say) Google, as shown on slides 6–15 at http://slidesha.re/1v6ZQZZ.
264 These principles are partly inspired by John Kotter’s eight-step process described in [kotter]: establish a sense of urgency, create the guiding coalition, develop a vision and strategy, communicate the change vision, empower broad-based action, generate short-term wins, consolidate gains and produce more change, anchor new approaches in the culture.