The concept of “flow” is a common thread in DevOps. Fin Goulding and Hayden Shaughnessy do a great job summarizing the concept of flow and how it relates to digital transformation in their book Flow: A Handbook for Change-Makers, Mavericks, Innovation Activists and Leaders: Digital Transformation Simplified. In a previous article, “Modular Architectures Make You Agile in the Long Run”, Dan Sturtevant summarized how our thinking about software architecture needs to change to support flow. But software architecture alone isn’t enough. If we’re going to take a holistic view of DevOps and agile development, we need to consider how the organization and business need to change.
This notion is easy to consider on a small scale but is an entirely different problem when an organization has tens of thousands of IT staff. Consequently, few people have the experience of implementing flow at scale. Jon Smart – Partner, Enterprise Agility Lead at Deloitte Digital (previously Enterprise Agility Lead at Barclays) – is a rare exception and one of the best thinkers I know on this topic. Here, he shares his experiences on how to shift our perspective on organizational transformation and objectives to take DevOps’ benefits from the small scale of startups and “unicorns” to the massively more complex scale of enterprise IT. — Mik Kersten, CEO & founder Tasktop, author of Project to Product, creator of the Flow Framework™
Historically, in large, old, complex organizations (the horses rather than the unicorns) that have adopted agile and DevOps principles and practices, the adoption has been at the team level. From my experience of delivering software with agile principles since the early 1990s, these “islands of agile” most often arise despite the firm, not because of the firm, owing to employees with a growth mind-set willing to take a personal risk.
The agile islands are a local optimization in the end-to-end value stream. A 90 percent reduction in a development team’s lead time might have a negligible impact on the time from when customer needs are identified to when those needs are met. Look to the right, the constraint could be IT operations staff, who are incentivized to protect up-time, batching up change. Look to the left, the constraint is the portfolio management and funding black hole, with an annual cycle. Look up, there’s a command-and-control leadership style, with low levels of psychological safety. Look around, other teams aren’t agile and dependencies aren’t broken, such that the end-to-end lead time for customer value doesn’t decrease.
As of 2017, only 10 percent of Fortune 500 companies from 1955 were still in the Fortune 500.1 At the current churn rate of the S&P 500, half of the firms will be replaced over the next 10 years.2 Tectonic shifts in the competitive landscape are occurring owing to:
- cloud computing;
- mobile devices’ prevalence and capabilities;
- increased communication bandwidth and information transparency;
- increased venture capital funding chasing a return, owing to historically low interest rates and volatility;
- government regulation increasing competition; and
- increased competition from nontraditional born-agile competitors.
These shifts are leading companies to realize that a business-as-usual approach won’t result in business as usual.
In recent years, enterprise-wide DevOps and agile at scale have surged. Compared to nearly 30 years of “lightweight methodologies” for team-level software development, this is a new field. DevOps emerged as a term in 2009, with scaled agile frameworks coming out comparatively recently: SAFe (Scaled Agile Framework) in 2011, Disciplined Agile in 2012, and LeSS (Large-Scale Scrum) in 2013. However, relatively little research is available about these frameworks’ effectiveness in practice, especially on an enterprise scale.
Here, I share lessons learned from being a servant leader for agility at scale across Barclays. Barclays is a global financial-services firm, with 80,000 employees in 40 countries, founded in 1690 in the City of London. Every day Barclays processes the equivalent of one-third of the UK’s annual GDP—approximately £600 billion. Barclays meets a financial need of almost 50 percent of UK adults and operates in a highly regulated industry.
Context is key; the context here is large, old, complex, not born-agile organizations with many diverse product offerings, colleagues, and customers, used to working in a traditional way. Reinventing organizations with legacy and complexity as we enter the digital revolution is a difficult and interesting challenge in which only the most adaptable will survive. On the basis of my experience, here are the main anti-patterns related to scaling agility and DevOps, paired with the patterns that have helped us succeed at Barclays’ scale.
Antipattern 1: Doing a Capital A, Capital T Agile Transformation
A capital A, capital T Agile Transformation, from an employee’s perspective, implies involuntary, mandatory change being done to you, whether you like it or not. The capital T denotes that you must change; the capital A denotes exactly how you’ll change. This provokes fear and resistance for many reasons,3 including the fear for your survival, which in turn leads to less rational thought as the primitive brain takes over.4
Dan Pink posited three key drivers of motivation: autonomy, purpose, and mastery.5 In this antipattern, two of those drivers—autonomy and mastery—have been taken away. If the “why” isn’t well articulated, meaningful purpose is also removed, eliminating all three key drivers.
Pattern 1: Start with “Why,” and Focus on Outcomes
As Simon Sinek articulated, start with “why.”6 There should be a clear, well-communicated “why” of the need to change. The “why” should be more than profitability, shareholder returns, or stock price. In “The Irrational Side of Change Management,” Carolyn Aiken and Scott Keller stated,
What the leader cares about (and typically bases at least 80 percent of his or her message to others on) does not tap into roughly 80 percent of the workforce’s primary motivators.7
This research shows that employees are most motivated by a purpose that’s split equally across five forms of impact: society, the customer, the company, the team, and the individual.
From the “why,” identify high-level, thematic desired outcomes, rather than agile for agile’s sake. For us, the desired outcomes are described as Better, Value, Sooner, Safer, and Happier, each of which is measurable.
Antipattern 2: The Bigger the Capital T, the Bigger the Change Curve
The Kübler-Ross Curve (see Figure 1) originated from psychiatrist Elisabeth Kübler-Ross’s work on grief. We’ve repeatedly observed these behaviors to hold true in the context of change, via feedback from employee surveys.
The bigger the capital T Transformation, the bigger the change curve. If embarking on one large Transformation, expect a deep dip in the curve. Such a transformation doesn’t apply an agile mind-set to increase organizational agility. It will make the journey more challenging, with more denial, frustration, and anger. The change stands a higher chance of cultural rejection, with more ammunition for those averse to change.
Pattern 2: Achieve Big through Small
Instead of a big bang transformation, with one big dip in the curve, achieve a big outcome through early, frequent, and small slices of value. Pursue evolutionary and continuous transformation aligned to outcomes, linking together a series of smaller change curves. Start in areas that are naturally receptive. The dips aren’t as deep, the learning comes quicker, there’s less risk, and the champions, who have been trying to do this despite the firm in the past, are best placed to beat a path through the organizational jungle.
Antipattern 3: One Size Fits All
Often combined with the previous antipatterns is the imposition of a one-size-fits-all approach across an organization. Large, old organizations are heterogeneous, not homogeneous. A one-size-fits-all approach won’t maximize the desired outcomes. Scaling is about complexity, diversity, and building a learning and continuous improvement (CI) capability. With many unique contexts, the practices should differ:
Principles + Context = Practices9
Pattern 3: Focus on the Outcomes, with an Empowered and Federated Model
Each area has autonomy and is empowered via a federated model to improve on the desired outcomes as it sees fit, with fast feedback supported by training, coaching, and data. The context, culture, history, starting point, and impediments are unique. There’s no silver bullet. People are more likely to accept change if they have autonomy and empowerment to figure out the “how” for themselves, building mastery in the process.5 There should be a small “center of enablement” team that provides servant leadership, coordination, and sharing and owns the resolution of impediments that span business units.
A few areas exist that share a common approach, to ensure organizational consistency. This includes consistent role names (e.g., Product Owner, Agile Team Lead, and Architecture Owner), a consistent target-state organizational-design model, and, especially for regulated firms, a consistent lifecycle that supports continuous delivery.
Antipattern 4: Transformation Treated as a Project with an End Date
A capital T Transformation is launched with fanfare and an initiative name, articulated as a program with an end date, at which the transformation will be done. There’s a significant investment, with significant savings predicted, which further fuels the capital T in Transformation with the need to do more, faster.
Pattern 4: Transformation Is Continuous
For organizational agility, there is no end date. Transformation is never done; it’s a constant process of learning, retrospection, experimentation, and improvement. The environment in which organizations operate changes constantly, more quickly and unpredictably than ever. Progress is tracked via measures in line with the overall desired outcomes. The goals are to be the best at being better and become a learning organization.
Antipattern 5: Leaders Say, “Tell Me When It’s Done”
Leaders have initiated an agile transformation, and the behavior observed is “tell me when it’s done,” with arms metaphorically crossed and little or no change in the leader’s or leadership team’s behavior.
As Frederic Laloux commented, “The level of consciousness of an organization cannot exceed the level of consciousness of its leader.”10
Pattern 5: Leaders Go First
Transformational leadership is a critical factor for successful ongoing continuous transformations. The 2017 State of DevOps Report showed that teams with the least transformative leaders were half as likely to exhibit high IT performance.11
Leadership can’t be outsourced. It can be supported with coaching, training, and advice to shortcut learning. The first team to adopt continuous transformation should be the leadership team, role-modeling the desired behaviors.
Antipattern 6: Middle Management Has No Role
A common antipattern is when middle management, also called the “Frozen Middle,” has no clear role to play in the continuous transformation.12
Middle management not only has a hard job of delivering complex change and keeping stakeholders happy but also now needs to change the way of working at the same time, to a way it hasn’t experienced before. This can be deeply unsettling. Not only am I flying the plane through storms, with expectations on the landing time, I’m also now being asked to both fly it differently and upgrade the plane mid-flight.
Pattern 6: Middle Management Has an Explicit Role
Middle management, as well as leaders, needs an explicit role in the continuous transformation. That role is being a coach, trainer, and teacher to one or more mentees, as per the Toyota Improvement Kata:
The primary task of Toyota’s managers and leaders does not revolve around improvement per se, but around increasing the improvement capability of people.13
This gives leaders at all levels a role to play that’s built into the daily work rather than simultaneously being classroom based and empowering the mentee.
Antipattern 7: Not Institutionalizing the Change
As John Kotter observed, one anti-pattern is the failure to institutionalize the change.12 This is manifested in not tackling systemic or behavioral norms in the organization, such that as soon as a key leader who’s championing the change moves on, the organization snaps back to how it used to be with surprising speed.
According to Accelerating Performance, organizations take five years to move up one performance sector and only 18 months to slip back again.14
Pattern 7: Institutionalize the Change
For large, old, bureaucratic, complex organizations, especially regulated ones, driving change through official standards can be effective. We’ve re-written internal standards and the product development lifecycle to embed desired behaviors, such as continuous delivery, long-lived products, and a focus on outcomes over output.
This isn’t scary or intimidating; the “A word” isn’t being used. Internal audits are your friend; they help to independently verify that the standards are implemented and driving the right outcomes.
Antipattern 8: Measuring Nothing or the Wrong Things
There are five easy ways to reduce the likelihood of a transformation’s success via the inappropriate use of metrics. First, don’t take a data-driven approach. Second, focus on team-level metrics (such as velocity or the “say–do ratio”) and weaponize them. Third, measure just one thing, such that it’s achieved at the expense of other things (for example, measuring flow at the expense of quality). Fourth, measure the workers, not the work system, aiming for busy people. Finally, align top-down targets with anything other than outcomes.
Pattern 8: Measure the Desired Outcomes
Take a data-driven approach, with measures that are in line with the desired outcomes (for example, flow, incidents, and the colleague and customer Net Promoter Score). Make this data transparent to all, showing the trend over time.
Focus on the work, not the workers
The biggest issues will be where the work isn’t—that is, the big wait times due to handoffs and dependencies. Measure the flow efficiency in the value stream. In our experience, and anecdotally from other large companies, work typically is being worked on only 10 percent of the time between when it starts and when it reaches the customer’s hands.
Antipattern 9: Not Prioritizing Technical Excellence
The 2017 State of DevOps Report showed that the gap between high- and low-performing organizations is closing regarding deployment frequency and lead time.11 However, the gap is widening for the change failure rate and mean time to recovery. This implies that the low-performing teams are working to improve speed but aren’t sufficiently prioritizing technical excellence or building quality into the process.
Pattern 9: Prioritize Technical Excellence
Along with adopting agile ways of working and reducing lead time, it’s equally important to prioritize investment in automation and the shifting left of quality (that is, incorporating testing early during development), with test-first development and high levels of automation. Tests, code quality analysis, and security scanning are built into the CI pipeline, with the assembly line stopping when an issue arises. Quality becomes part of everyone’s job.
So, here are the takeaways from this article:
- Have a compelling “why.”
- Focus on outcomes, not agile for agile’s sake
- Achieve big through small.
- Foster autonomy, purpose, and mastery with psychological safety.
- Don’t take a one-size-fits-all approach.
- Pursue continuous transformation and CI.
- Leaders go first.
- Give middle management a role.
- Institutionalize the change.
- Measure the desired outcomes.
- Prioritize technical excellence.
In short, apply an agile mind-set to the rollout of agility, and treat it as a tool in the toolbox to achieve desired organizational outcomes. Approach continuous transformation as a capability to be nurtured rather than as a project with a silver-bullet solution. Be the best at being better.
See Jonathan in action
DevOps Enterprise Summit 2018, London
DevOps Enteprise Summit 2018, Las Vegas
Begin your Project to Product journey
For more on making a success of your Agile and other IT transformations, grab Du projet au produit – available in print, Kindle and audio – by clicking on the front cover below:
Sign up to the Product To Project newsletter
This is the seventh blog in a series promoting the genesis of Mik’s book Project To Product. If you missed the first six blogs, cliquez ici. And to ensure you don’t miss any further blogs, you can receive future articles and other insights delivered directly to your inbox by signing up to the Project To Product newsletter.
References
- M.J. Perry, “Fortune 500 Firms 1955 v. 2017: Only 60 Remain, Thanks to the Creative Destruction That Fuels Economic Prosperity,” Am. Enterprise Inst., 20 Oct. 2017; http://www.aei.org/publication/fortune-500-firms-1955-v-2017-only-12-remain-thanks-to-the-creative-destruction-that-fuels-economic-prosperity.
- S.D. Anthony, S.P. Viguerie, and A. Waldeck, Corporate Longevity: Turbulence Ahead for Large Organizations, Innosight, 2016; https://www.innosight.com/wp-content/uploads/2016/08/Corporate-Longevity-2016-Final.pdf.
- R.M. Kanter, “Ten Reasons People Resist Change,” Harvard Business Rev., 25 Sept. 2012; https://hbr.org/2012/09/ten-reasons-people-resist-chang.
- R. Maurer, One Small Step Can Change Your Life: The Kaizen Way, Workman, 2014.
- D.H. Pink, Drive: The Surprising Truth about What Motivates Us, Riverhead Books, 2009.
- S. Sinek, “Start with Why,” TED Talk, Sept. 2009; https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.
- C. Aiken and S. Keller, “The Irrational Side of Change Management,” McKinsey Q., Apr. 2009; https://www.mckinsey.com/business-functions/organization/our-insights/the-irrational-side-of-change-management.
- Anastasia, “Understanding the Kubler-Ross Curve,” Cleverism, 24 June 2015; https://www.cleverism.com/understanding-kubler-ross-change-curve.
- D. North, “Kicking the Complexity Habit,” 2014; http://gotocon.com/dl/goto-chicago-2014/slides/DanNorth_KickingTheComplexityHabit.pdf.
- F. Laloux, Reinventing Organizations, Nelson Parker, 2014.
- N. Forsgren et al., 2017 State of DevOps Report, Puppet, 2017; https://puppet.com/resources/whitepaper/state-of-devops-report.
- J.P. Kotter, Leading Change, Harvard Business Rev. Press, 2012.
- M. Rother, Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results, McGraw-Hill, 2009, p. 186.
- C Price and S. Toye, Accelerating Performance: How Organizations Can Mobilize, Execute, and Transform with Agility, 2017, John Wiley & Sons.
A version of this article was originally published in the November/December 2018 issue of IEEE Software: J.Smart, “To Transform to Have Agility, Don’t Do a Capital A, Capital T Agile Transformation," IEEE Software, vol. 35, no. 6, pp. 56-60, ©2018 IEEE doi: 10.1109/MS.2018.4321245 - Original article
