{"id":21192,"date":"2018-11-30T08:36:14","date_gmt":"2018-11-30T14:36:14","guid":{"rendered":"https:\/\/blog.planview.com\/dont-do-a-capital-a-capital-t-agile-transformation\/"},"modified":"2018-11-30T08:36:14","modified_gmt":"2018-11-30T14:36:14","slug":"dont-do-a-capital-a-capital-t-agile-transformation","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/dont-do-a-capital-a-capital-t-agile-transformation\/","title":{"rendered":"To Transform to Have Agility, Don\u2019t Do a Capital A, Capital T Agile Transformation"},"content":{"rendered":"
\n
\"To<\/div>\n<\/figure>\n

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 <\/span>Flow: A Handbook for Change-Makers, Mavericks, Innovation Activists and Leaders: Digital Transformation Simplified<\/span><\/a>. <\/span>In a previous article, “<\/span>Modular Architectures Make You Agile in the Long Run<\/span><\/a>”, 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.<\/span><\/em><\/p>\n

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. <\/span><\/em>— <\/span>Mik Kersten,  CEO & founder Tasktop, <\/strong><\/em>author of Project to Product<\/em>, creator of the Flow Framework™<\/strong><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

As of 2017, only 10 percent of <\/span>Fortune<\/span><\/i> 500 companies from 1955 were still in the <\/span>Fortune<\/span><\/i> 500.<\/span>1 <\/sup>At the current churn rate of the S&P 500, half of the firms will be replaced over the next 10 years.<\/span>2<\/sup> Tectonic shifts in the competitive landscape are occurring owing to:<\/span><\/p>\n