Check out this enterprise leadership forum event I hosted with a panel of product management experts. We discuss the rapidly evolving field of product management and how you can use agile and DevOps practices to improve the time to market of digital products and services.
Here is the summary of the topics we discussed.
DevOps mindset and culture: A mindset and culture that enables the fast flow of customer value from development to production and into the hands of the customers rapidly and reliably.
DevOps mindset and culture: A mindset and culture that enables the fast flow of customer value from development to production and into the hands of the customers rapidly and reliably.
Funding product teams: A shift in how work is funded, from temporary project teams to long-lasting product teams that own the end-to-end value delivery.
Check out my webinar on addressing the challenges of the move to the cloud and how to capture the multiple benefits of the cloud. Here is the link to the LinkedIn event.
While organizations continue to invest in the cloud, they are not yet experiencing the promised benefits from these investments. Focusing on technology alone will not deliver success, innovation, or value – it will only deliver new technologies and infrastructure, but not necessarily business outcomes.
CIOs and CFOs are now tasked with developing and executing a strategy to realize the financial and non-financial benefits of the move to the cloud.
Check out the webinar to find out how to realize the financial and non-financial benefits of the cloud.
Scaling Agile & DevOps teams continue to be challenging, but scaling successfully delivers massive results. To find out how to handle the complexity that comes with scale, check out the Webinar I hosted on the complexity of DevOps at Scale on LinkedIn.
Your leadership style directly affects how people respond to changes in leadership, people, processes, and technology. How you lead determines your organization’s success.
When members of the organization are motivated, work autonomously, and feel ownership in an environment with a clear and shared product vision (formal or informal) leadership and a culture of trust, the organization, achieves maximum business value.
Check out the webinar on how to become an effective transformational leader.
I also offer an interactive, extremely engaging, experiential course on becoming an effective transformational leader.
Here are the details of the course.
The DASA DevOps Leader™ certification enables you to exercise leadership principles with like-minded DevOps leaders and focuses on how to lead, drive, and support a successful DevOps transformation in practice
The course focuses on leading, driving, and supporting a successful DevOps transformation in practice. With lots of best practices, patterns, and anti-patterns from organizational culture, change management, leadership, people, process, and technology points of view, you will understand the importance of (informal and formal) leadership to create high-performance digital organizations.
In the digital age, the capability to develop, deliver and operate software-based products is critical to organizational success. But measuring the organizational capability to build and operate software-based products has been fraught with challenges for several reasons.
Software products, unlike manufactured products, don’t have visible inventory and a visible manufacturing process, which makes the software development and delivery process challenging to measure.
Applying the manufacturing measurement paradigm to software development results in a flawed focus on outputs, such as measuring software development performance based on the number of lines of code. In software, it isn’t the number of lines of code that matters. What matters is achieving a business outcome with minimal lines of code.
With the advent of Agile software development, velocity- the number of story points completed in an iteration -became an accepted way of measuring development productivity. However, velocity as a measure of software delivery performance has several flaws Velocity is a relative and team-dependent measure. Secondly, it makes it likely teams will game their velocity, especially if it is used as a productivity measure.
Find out in the webinar how the DORA metrics help solve these problems and allow you to measure software delivery performance at a system and business level.
The defense industry, with its multi-billion dollar projects and contracts and multi-year timelines, has customarily built large cyber-physical products using waterfall project management methods. However, as technology advances rapidly and as the threat space within which these products operate continues to evolve, using the waterfall method to build such products no longer works. An alternative to waterfall project management is needed to build, operate, and continually enhance large and complex digital products.
Here is a case study of how the US Air Force (USAF) is making the transition from waterfall to SAFe to build its future land based intercontinental land based ballistic missile system. It has important lessons for companies making the transition from waterfall or partial agile (water-scrum-fall) methods to using agile at scale and DevOps to build and operate large digital systems, using multiple teams from multiple companies.
Here is the link to the Scaled Agile Framework’s video on how USAF / Northrop Gruman is making the transition from waterfall to SAFe and DevSecOps, along with my commentary on the reasons to move from waterfall to doing agile at scale with SAFe..
Start with the why : In order to succeed with a new way of working it is essential to understand why it is important to embrace the new way of working.
Here are the reasons USAF and Northrop Grumman ( the prime contractor) embraced the scaled agile framework to develop it new missile system.These reasons are general enough that they can be applied to any company building large and complex digital products.
So, here are my reasons why you should transition from the waterfall method or a partial agile method (scrum-water-fall) to the scaled agile framework.
You have delivery deadlines to meet : Most companies have to operate in conditions where deadlines for having a working product in operation are fixed, and the costs of missing deadlines are extremely high. In USAF’s case, if a new missile system wasn’t available to replace a rapidly aging existing system by a certain date, there would be gap in US’s deterrent capability. While the consequences of missing critical product delivery dates, for non military organizations, may not be that dire, they still have compelling reasons to meet product delivery deadlines. However, the waterfall method or a partial agile (water-scrum-fall) method , is notoriously unreliable and rightly associated with the watermelon metaphor – the project is green on the outside and red inside. So, this is my first reason why you should embrace the scaled agile framework – you have delivery deadlines to meet.
Your digital products are constantly evolving : In USAF’s case, and in companies building long lasting digital and cyber-physical products, products need to evolve constantly. So, the waterfall project management method and partial agile method ( water-scrum- fall) which use temporary teams and use proxy success metrics such as scope, cost and time to build products, is especially unsuitable for building constantly evolving digital products. Companies that need to build constantly evolving digital products need to urgently move to the organizational model of the development value stream, just as USAF did. A development value stream , as defined by SAFe ” are the sequence of activities needed to convert a business hypothesis into a digitally enabled solution” 1. These long lasting development value streams consisting of teams of teams ( Agile release trains and solution trains in SAFe terms) would be building and supporting constantly evolving digital products, iteratively and incrementally, through the life of the product. And this is the second reason why you need to move to SAFe : you need to build a constantly evolving digital product and you need to know how to use the development value streams model to build it. SAFe provides that guidance.
You need multiple teams from multiple companies to build your digital products: While USAF’s case of development involving 10,000+ individuals in hundreds of companies across the United states, may be an extreme example. However, building and operating a large digital product, involves multiple teams from multiple companies. Neither, waterfall method or a partial agile (water-scrum-fall) method, work in this context. What is needed is a method to scale agile product development across multiple teams and multiple companies. And SAFe, as corroborated by USAF’s use of SAFe to build its new missile system, is a trust worthy method for scaling agile product development. SAFe principle #7 ” Apply cadence , synchronize with cross domain planning ” 2 and practices (such joint planning at regular cadences, systems demos, etc.) based on it, provide the reliable means of managing product development involving multiple teams and multiple companies. So, here is the last reason for embracing the new way of working – doing scaled agile development with SAFe : you need to build a digital product using multiple teams from multiple companies.
SAFe 5.0 was a big release of SAFe, and responding to the demands of companies undergoing digital transformation, business agility is front and centre of SAFe 5.0. Dean Lefingwell’s conversation with Mik Kersten on the Project to Product podcast provides helpful insights for folks using SAFe or another scaling framework or even their homegrown framework to guide their company’s digital transformation. Here are my takeaways from that conversation on how you can use those insights to guide your digital transformation.
The focus on business agility in SAFe 5.0 : The reason SAFe 5.0 introduced business agility is because technical agility itself can’t deliver the mission of the business. You need business agility and technical agility to deliver the mission of the business. And the key enabling cultural practice for business agility is continuous learning. Other practices that enable business agility are design thinking, story mapping, customer journey mapping and value streams.
My takeaways :
Double down on agile, lean and technical practices, so you can deliver technology based solutions predictably. Build on this technical delivery competency, to deliver great technology enabled customer experiences and business results.
If Taylorism was the defining characteristic of the age of manufacturing, quoting Dean” continuous learning” is the paradigm that underpins the age of software. So, use the three ways of DevOps : flow, feedback and continuous learning, to continually learn about products and ways of working and use those learnings to continually improve them.
Move away from delivering features, to using design thinking in conjunction with customer journey mapping and value streams to design and deliver solutions that solve customer problems across all points of customer interactions.
Value stream thinking : Value stream thinking forces us to think about how the enterprise makes its money or delivers value. By doing that, we realize the larger context within which the development value stream (agile release trains or teams of teams) operates. The development value stream produces the products and systems that enable the operational value stream to deliver value effectively and efficiently.
My takeaway :
To achieve business agility it is time to stop funding one off projects for solution development, instead it is time to fund value streams and measure the business value and business outcomes being delivered through these value streams.
Hierarchy and the network : The key learning is that the organizational hierarchy and the entrepreneurial network can and should coexist. The hierarchy provides the structure to get routine work done, and the value stream based network provides the means to deliver customer-centric innovation.
My take way :
You don’t have to throw the baby out with the bathwater, i.e., you don’t have to get rid of the organizational hierarchy as part of your digital transformation. In fact to get the best of both worlds, you should embrace the dual operating system, with the hierarchy and network operating in tandem and in harmony, as espoused by John Kotter in his book, XLR8 (Accelerate). For a summary on how to balance the two operating systems, check out this SAFe article.
Tips for doing SAFe well : Here are some tips for doing SAFe well
Avoid painting the place SAFe i.e. avoid the tendency to start calling things SAFe and hope for the best, instead take the time to learn SAFe to do SAFe well.
Focus on principles : To get more out of ceremonies and more out of SAFe focus continually on principles. For example continually focus on principles to get the corrective action loop with the Inspect and Adapt (I & A) event.
Outcome metrics : Make your teams and teams of teams (Agile release trains / Development value streams) predictable, as their predictability drives the rest of the outcome metrics.
Based on the work of the economist Dr. Carlota Perez, Mik Kersten describes in his book, Project to Product, how to survive and thrive in the age of digital disruption with the flow framework, what happens to companies as the transition happens from one technological age to the next. Each technological age brings with it a new means of production, and companies that master it, survive and thrive in the new technological age. Companies that couldn’t master the new means of production become extinct.
Agile and DevOps emerged as responses to problems faced by technologists: Agile to solve the problems associated with waterfall software development, and DevOps to solve the problem of getting software into production. While the need to solve these problems is immensely important, success of agile and DevOps transformations should be measured not just by how effectively they solve these problems. They should also be measured by how effectively they improve the ability of the companies to deliver business results through software. This is what the modern age of software demands.
The means of production of the previous age of oil & mass production was mass production. Manufacturing companies that mastered mass production survived and thrived. Those that couldn’t master it, disappeared.
The means of production of the modern age of software is software delivery at scale. As software is pervasive and impacts all economic sectors, all companies have become software companies. And their ability to deliver software at scale is now critical to their business success.
To master software delivery at scale, companies launch agile and DevOps transformation initiatives. However, the transformation initiatives don’t explicitly set out to improve the ability of a company to compete and win in the age of software. They are primarily focussed on improving technical and process capabilities as illustrated by these sample success metrics: number of agile teams stood up, number of people trained in agile and DevOps methods, team velocity, deployment frequency, lead time from code commit to code deploy. None of these agile & DevOps transformation metrics are business metrics.
These metrics don’t tell you if your company’s ability to compete and win has been enhanced or diminished. And that is an existential problem – your company’s survival may depend on it.
The flow framework helps you solve this existential problem. It helps you measure if your transformation initiatives have enhanced or diminished your ability to deliver business value, by measuring the time it takes from intent to create business value to the delivery of business value.
In addition, by enabling you to measure the flow metrics (velocity, time, efficiency, load, and distribution) of the four items of business value (Features, Defects, Risks and Debts), you can execute your business and technology strategy in unison – the secret sauce of technology giants and startups. With the flow framework, you too have the ability to do the same: execute business and technology strategy in unison. And, this should be the overarching goal of agile & DevOps transformations, and a measure of their success.
Note : The article is based on the book Project to Product, Dr. Mik Kersten
Innovation is hard, scaling innovation is harder still. However, for businesses to compete and win in the age of software and digital, they need to innovate at scale and at speed. They need to bring to market digital products (software products or software enhanced physical products) quickly, learn from them and continually enhance them. Innovation with digital products is never done – the product is continually evolving based on digital feedback.
While delegating innovation to a research lab may have worked in the previous technological age, it won’t work in this modern age of software and digital. In order to deliver innovation at the pace and scale demanded by this age, businesses need to build an enterprise-wide infrastructure to deliver software based innovation.
And the way to build out this infrastructure for innovation is by adopting and adapting Lean and Agile practices.
A sneak peek of how to drive innovation at scale through lean and agile practices was the topic of the September 15 SAFe peer connect online event. I am sure there will be more discussions on this topic at the upcoming SAFe Global Summit. So, watch this space for further updates.
SAFe’s September 15 Peer Connect : Lean — Agile in practice : How to drive innovation at scale
Based on a very informative and interactive panel discussion led by these experts : Phil Alfano, CTO of Apptio, Jennifer Dahl, Agile Portfolio Manager at Clorox, and SAFe® Co-creator Dean Leffingwell ; here are my takeaways from that session on how businesses can drive innovation at scale with lean and agile practices.
1. Agility at scale: Having a few agile teams working in isolation won’t cut it. You need to scale agile so that a team of teams is delivering a release ready product increment on a regular cadence. This really is the table stakes.
2. Transition to product-based value streams: This is one of those evolving meta topics, where the details on how to do it well are still emerging. SAFe provides you the thinking tools and the vocabulary (development value streams, operational value streams, assessment etc) that will help you make this transition.
3. Visualize and limit WIP: This is a critical SAFe principle. Although, it is difficult to implement in practice due to the intangible nature of knowledge work, it is imperative you to do it well. Doing well allows you to align demand with capacity, both human and financial. With the help of tools such as Apptio target process you can make this alignment visible at different layers of the system – teams, products and portfolios – enabling you to drive innovation at scale.
Finally, these field tested nuggets of wisdom on driving innovation at scale based on conversation among peers in the break-out session. Thanks folks for a great conversation.
· Transparency is critical to successful delivery. (Sean Depkin)
· The importance of agile management tools and the visibility they provide, when done well (Ann Kahraman)
· The need to connect operational value streams to development streams to drive business results (Tom McDonnell)
RTI Consulting Services 