Project to Product
Read the book “Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework ”, by Mik Kersten. I had written about my Learnings from Agile Journey , Agile, Product and Platform mindsets and Moving from Project to Product Delivery before. First part of this book laying out the case for moving from Project to Product delivery and why large enterprises should go beyond Agile/DevOps is insightful. When it moves to Flow Framework and trying to prescribe the model, it lost me a bit. Few excerpts and learnings from this below.
Need to go beyond Agile and DevOps
An Engineering Director recently asked me that the engineering metrics we use are no longer relevant beyond being guardrails, how should the value be measured? I think Agile/DevOps helped to identify bottlenecks and create linear local optimizations, but it is not focused end to end business value streams that deliver business outcomes.
“Agile development came to the rescue but oversimplified its view of delivery to exclude upstream and downstream stakeholders, such as business analysts and operations staff. DevOps addressed this exclusion by embracing operations, automation, and repeatability of deployment processes. But by overfocusing on linear processes rather than end-to-end flow and feedback, organizations are repeating mistakes by adopting an overly narrow and overly linear view of DevOps.”
“Due to all the disparate systems and focus on local optimization and tracking of activities instead of results, it was impossible for anyone to reliably know where the bottleneck was. There was no business-level understanding of what the real bottleneck was, as the gulf between what IT and developers knew and what the business assumed was so vast. That, in turn, led to the Agile transformation—implemented as a local optimization of the end-to-end value stream—yielding little result and not addressing the bottleneck.”
“A large gap exists between what technologists have learned about effective software delivery and how businesses approach software projects. While DevOps and Agile principles have made a significant impact on how technologists work, they have been overly technology centric and have not been adopted broadly by business stakeholders. To bridge the gap, we need a new kind of framework that spans the language of the business with the language of technology and enables the transition from project to product. We need that framework to scale the three ways of DevOps—flow, feedback, and continuous learning—to the entire business.”
Why enterprises should shift beyond Agile / DevOps?
Whole industries are getting “unbundled” and it is “Age of Software” as software is eating the world (11 yr old article, shows how dated many traditional businesses are).
“In order to win in the Age of Software you must precisely define which type or types of disruption put your business at risk. Wherever you land, the next step involves a significant investment in software delivery. The success of that initiative and your ability to win your market will be determined by your ability to define, connect, and manage your software value streams.”
This is not how we and our users think of the applications we build. Not as Products that we use in our day to day life. ?
“Consider the last time you derived new value from a product or went back to using a product that you had previously not used. What triggered that exchange of value in terms of spending your time or your money? Chances are that it was a new feature that met your usage needs and perhaps delighted you in some way.”
Digital natives are born into this way of thinking about products, but it is so difficult for large legacy organizations to rethink.
“Tech giants have already mastered this new means of production, and digital startups have been born into this new way of working, but the majority of the world’s organizations have not. This is not for want of trying, but the combination of scale, complexity, legacy, and dated managerial paradigms is making that transition impossible to achieve in a time frame that ensures survival.”
This fascinated me. What if we could see a large IT organization from the top as a MRI scan? Could we see the mess and start to align it to business value streams? ?
“If we could take a virtual MRI of the workflows in a large IT organization (similar to viewing a moving X-ray of the BMW Group plant from above), what underlying structure would we see?”
How do we go to transformation zone? We had this mental model of Systems of Record vs Systems of Engagement and different speeds for different needs. This could be another – to look at where the focus of enterprises could be develop new products.
“The Productivity Zone is focused on making the bottom line and includes systems such as HR and marketing. The Performance Zone is about the top line and includes the main drivers of revenue. The Incubation Zone is where new products and businesses are developed before just one or the other is moved into the Transformation Zone and used to play disruption offence or defense.”
Why Product Delivery?
Author talks about the epiphanies and lessons learned while comparing product development in manufacturing like in case of BMW, examples like Nokia and thinking through the troubles we continue to see in software development. There is a throwback to the The Goal and Theory of Constraints. Many of the problems of large enterprises compared to digital natives are about scale and lack of end to end visibility of value streams. “Applications” end up being managed in “Functional Silos” as Projects whereas business value is derived through products or services. Applying Agile/DevOps practices in linear fashion and optimizing locally deviated us from looking at this as complex system. ?
Epiphany 1: Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream.
Epiphany 2: Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project management model.
Epiphany 3: Software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products.
Lesson One: To avoid the pitfalls of local optimization, focus on the end-to-end value stream.
Lesson Two: If you manage a transformation according to cost alone, you will reduce productivity.
Lesson Three: Engineering/IT and the business must be connected.
This was an epiphany for me as well over years. Many orgs manage IT as cost center, but loses focus on value delivery.
"The issue is that a cost-centric framework did not deliver increased velocity, productivity, or efficiency, and instead resulted in the business getting a lot less for less instead of more for less. Boeing demonstrates across its operations is that it treats its plane development as a profit center. The business sets goals, metrics, culture, and processes in a completely different direction."
Instead of measuring value, we create proxy metrics and manage those processes with a bible. This from an Amazon memo -
Resist Proxies - As companies get larger and more complex, there’s a tendency to manage to proxies. This comes in many shapes and sizes, and it’s dangerous, subtle, and very Day 2. A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.
Another lesson – in projects world, there is only schedule, cost and quality and technical debt becomes second class citizen. In persistent product teams, without reducing technical debt, can’t increase speed.
"In project-oriented management, there is no incentive to reduce technical debt; its effects do not materialize until after the project ends."
I need to refresh on how to apply Lean properly in day to day product development.
Lean thinking can be summarized in five principles: precisely specify value by specific product, identify the value stream for each product, make value flow without interruptions, let the customer pull value from the producer, and pursue perfection.
I am yet to properly use Lead time and Cycle time to measure and drive behavior of entire product delivery teams. In TODOs..
Lead time focuses on measuring time through an entire process, while cycle time focuses on the time it takes to complete a step within the process. From the last Deployment Period of the Age of Mass Production, we know that both of these metrics are key to improving production processes. Cycle time can help identify constraints—where the step with the longest cycle time will typically be the bottleneck—while lead time tells us the time it takes for the end-to-end process to run (for example, starting at the customer order for the car and ending with delivery).
This lesson can be immediately applied. We slice the teams based on architecture and create silos, than create true autonomous feature teams.
"Realigning the daily work of software developers around the value stream, instead of the software architecture, produced a statistically significant productivity increase."
Theory of Constraints meet complex networks where alternate paths gets created all the time.
"The theory of constraints tells us that investing in just one segment of the value stream will not produce results unless that segment is the bottleneck. But how do we know it is the bottleneck? Even more important, what if we’re looking for a linear bottleneck in a nonlinear process? For example, in a linear bottleneck a single dependency can become a constraint. But in a network, there may be a path around the dependency. Software teams can be observed taking these alternate paths all the time (e.g., coding around the lack of an API they expected from an upstream team)."
Managing dependencies is hardest to do in complex networks. Increasing connectedness – one more TODO.
"One of the hardest things to manage in software delivery is dependencies between teams, components, and products. DeGrandis identifies three kinds of dependencies: architecture, expertise, and activity based.
Metcalfe’s law tells us that a network’s value grows with its connectedness."