Mik Kersten

Hello everyone. I am thrilled to be here today and to share the story behind my book, "Project to Product."

My name is Mik Kersten. For my entire career, I have been on a journey to help transform how software is built. For the first ten years of that journey I was a developer, writing a ton of code, because I thought the problem was with the code and with the way code was disconnected from the value stream. I ended up writing over a million lines of open source Java code, still in use today in frameworks such as aspect-oriented programming, which you may know from Spring, and tools such as the Eclipse Mylyn project.

As Gene said, what I realized is that if we remove impediments from developers and connect them to the users they support and to the flow of business value, we get a sense of focus, flow, and even joy. I got my PhD in software engineering on exactly that topic. When my supervisor and I realized this, we decided to scale it and make it work at very large scales. We looked to enterprise IT and started Tasktop to do just that.

Enterprise IT taught me different lessons than open source. I noticed a hundredfold productivity difference between how quickly open source developers could create value, in a community of hundreds of contributors, and what I saw in very large enterprise IT organizations. The problem was deeper than improving the lives of 10 million developers. As Gene inspired us this morning, we now have to think about 40 million IT specialists.

I can quantify this past decade of my life not with lines of code, but with over a million air miles, which is nowhere near as fun or rewarding as writing a million lines of code. But it taught me valuable lessons by letting me meet hundreds of IT leaders struggling with the weird, broken layer we have put between technology and the business. To bridge those gaps, I created the Flow Framework, which is featured in "Project to Product." Its goal is to give us a common language between what we have learned from Agile and DevOps and the way the business thinks about surviving and thriving in the age of digital disruption.

For me, the journey started at Xerox PARC in 1999. I had just received my undergraduate degree from the University of British Columbia in computer science and anthropology, and I had the opportunity to work at PARC, where the graphical user interface, the mouse, and object-oriented programming were pioneered. I was having the time of my life working on new programming tools that were supposed to bring business requirements closer to developers and express them in code.

I started working 80-hour weeks because we had a thriving user community and I loved what I was doing. Then the RSI started. I got bad tendonitis, which progressed into nerve issues in my arms. I tried mousing with my other hand, but my boss eventually told me he had seen careers end this way and suggested paid time off. That was the last thing I wanted to hear. I was far from burnout; my body was just not holding up. I decided to figure out why this was happening.

When I analyzed my own work, the most surprising thing was that coding was not causing the RSI. It was all the thrashing across windows, which was ironic at PARC. The windows had stack traces, tickets, instant messaging, and email, because we were tracking user stories in email. We had already done continuous integration and continuous delivery automation, so I was not thrashing that way. The thrashing was all the communication about what we were supposed to be doing and how misaligned our software architecture was with the flow of value stream artifacts.

If the problem was misalignment, I thought we could make a software tool to solve it. That experiment became Mylyn. It fixed my RSI because it bridged the gap between what I was working on and the structure in the code. Other people had the same problem, so we saw millions of monthly downloads, and it became the foundation for my PhD thesis. That was my first epiphany in the book: fragmented value streams kill personal productivity. In my case they caused physical injury; in other cases they cause burnout and demotivation because people cannot get work done the way they want to.

Fast-forward to 2007. Nokia had started its Agile transformation. Like Jeffrey Snover said earlier this morning, Nokia realized it was about to be disrupted. They knew about the capacitive touch screen and the large screen of the iPhone a year ahead of time. They understood they had to get better at software. They were incredible at manufacturing physical devices, but the phone screen was getting bigger and software delivery would become their bottleneck.

Nokia started adopting Agile practices, hiring more developers, and doing the things companies do today. It appeared they were doing it the right way. At the Agile Conference in 2009, every room I entered had a consultant saying Nokia was a poster child for enterprise Agile. But when I started working with Nokia, the truth was different. The business measured the Agile transformation by how many teams were Agile and how many had been trained on Scrum.

That was a proxy metric: a metric of activity, not a metric of result. The Nokia test for agility measured whether they had optimized a narrow segment of value stream development. Kevin Fisher mentioned this morning that when Nationwide looked at its end-to-end value stream, only 2.5% of the time was actually spent in development. Nokia could have hired 20 times the developers or 20 Ken Schwabers to help with Scrum, and it would not have helped the problem.

Because the business did not realize this, Nokia lost the mobile market it created. That was my second epiphany: silos and proxy metrics destroy transformations. Change success rate and development cycle time are important, but they are not enough. We cannot measure proxy metrics in silos and expect a transformation to succeed.

By 2016, we should have learned those lessons. I was at a top-25 bank by revenue, which was in its third transformation. The first two failed in similar ways to Nokia. The third was an Agile and DevOps transformation with automation, and it had a billion-dollar budget. Everyone wanted it to succeed. But I realized it would fail, and two years later it had.

There was another big silo: IT was doing the transformation within IT. Chief digital officers and others were creating amazing dashboards for the bank, but because those dashboards were separated from IT, they would never work in the planned regions. The software architecture would not support them. The silo between the business side that wanted transformation and IT got in the way. The transformation was managed to cost because it was a project management transformation. Costs were reduced after two years, but everyone said the ability to deliver value had also been significantly reduced.

The layer between the technology side and the business side was the wrong lens and the wrong layer. That led to my third epiphany: project management and cost centers are the wrong model if you want to become a software innovator. They derail transformations and must be replaced quickly because other companies have already done it.

From 2006 to 2016, Amazon had a 1910% stock-price increase. It aligned business strategy to software products, software architecture through microservices, and organizational structure through two-pizza teams. It out-innovated everyone else. Some of that stock price is AWS, and there is more to the story. Target is also making steps in the right direction. But this is not just retail. Some organizations have become software innovators by not having a project management layer that assumes a high degree of certainty about the next two years of the market. At today's churn rate, half of the S&P 500 will be replaced in the next ten years.

I wondered whether this had happened before. Gene introduced me to the work of economic historian Carlota Perez, who studied technological revolutions: the Industrial Revolution, steam and railways, steel and heavy engineering, mass production, and today's age of software and digital. These revolutions have an installation period and a deployment period, with a turning point between them.

In the installation period, there is a frenzy because some new means of production becomes cheap. In Detroit over 100 years ago, there were over 300 car startups, fueled by financial capital. Today that is venture capital; there are over 2,000 fintech startups. These companies are mastering the new means of production. This causes tremendous creative destruction, and then masters of the new means of production emerge: Facebook, Amazon, Netflix, Google, Microsoft, Alibaba, JD.com, and others. The key is to help the rest of the world economy move into the wealth generation that happens when the new means of production disseminates.

The question is how our companies survive this turning point. What do we learn from startups and tech giants? What are they doing differently from enterprise IT organizations, which still represent most of the world economy? How do we survive the mass extinction event that happens at a turning point? We are in the middle of that turning point.

Each technological revolution has brought a new managerial discipline. There have been new financial systems and managerial methods such as factory systems, subcontracting, Taylorism, and Fordism. Taylorism is where we learned to do amazing projects; the Hoover Dam was created with Gantt charts. But you could not create an economy of mass production that way. Mass production used lean methods, products, and value streams. Many companies founded before the age of software are still using management techniques from two ages ago to run their businesses and strategies.

To understand how mass-production companies survived the last turning point, I looked at BMW. BMW is one of the masters of mass production and made it through that turning point. I visited the BMW Leipzig plant. Its architectural elegance and complexity are tremendous: a new one- or two-series car comes off the production line every 70 seconds, in the same sequence it was ordered, called just-in-sequence delivery, with an ecosystem of 12,000 suppliers.

Enterprise IT cannot use complexity as an excuse; the BMW plant is near the same scale of complexity. But no one there talks about project management. They live lean principles: precisely specify value by product, identify the value stream for each product, make value flow without interruptions, and let the customer pull value from the producer. Everybody knows where the bottleneck is, including the CEO. When I asked IT executives and business leaders what the bottleneck of their software production was, I often got vague answers or blank stares because we are not sure what the units of production are in software.

BMW architects everything around value streams. You can see the value stream architecture from space. The one- and two-series building is a long, high-automation line delivering cars every 70 seconds, so no manufacturing step can take more than 70 seconds. The electric i3 and i8 series used a more configurable line because BMW did not know demand levels. The i8 production step takes 30 minutes and has much less automation. Everything is configured as value streams, and the business understands product lines and value streams.

Compare that to enterprise IT. Car production has integrated production lines, not disconnected tool chains. It is managed as products, not projects; architected around flow, not technology layers; optimized end to end, not in silos; and measured by business results, not proxy metrics. In software, we have not agreed on what productivity in software delivery is.

At the BMW plant, business value flow is about quality cars that deliver sheer driving pleasure. Those cars are designed in yearly cycles and delivered every 70 seconds. Creative and manufacturing processes are decoupled and flow across a linear production line. In IT and software, we delight customers with new features, not with releases, because releases should now happen continuously. Features can be designed weekly or daily. The creative and manufacturing processes are one, and the flow is not linear; it crosses a complex value stream network of designers, developers, support staff, operations, and other specialists.

The Flow Framework answers the question: what flows in software delivery? We need a common definition of productivity and flow. There are four units: features, which are new business value pulled by customers; defects, which are quality improvements pulled by customers; risks, which are security, availability, compliance, and other risk reductions pulled by risk officers; and debts, which are technical debt improvements pulled by architects, developers, and others. These four flow items are mutually exclusive and comprehensively exhaustive, representing all work being done. Specific taxonomies, such as the Scaled Agile Framework, map into these four flow items.

Consider a big push to market. Feature work probably defines product success, but because the four flow items are a zero-sum game, pushing features means taking on additional debt and risk. Quality goes down, defect work rises, and you can enter a debt spiral. Developers want to deliver features and see the impact of their work on customers, but instead they get trapped in defect work, and employee net promoter scores drop.

This is what Nokia got into. John Cutler's example shows a reference feature taking 15 to 30 days in 2015 and 150 to 300 days in 2018. Technologists understand they need to invest in technical debt reduction, but the business often does not. By contrast, after SQL Slammer in 2003, Bill Gates sent a memo that effectively said Microsoft would drop feature work across value streams and reduce debt. That Trustworthy Computing Initiative assured Microsoft's future and helped it move to cloud faster and more securely. Nokia failed to make that business-level move.

The goal of the Flow Framework is to provide a common language that tech giants led by former software developers innately understand, and make it accessible to business leaders. The framework measures flow distribution: how many of each flow item was delivered during a sprint, release, year, and so on. It measures flow efficiency in the value stream network; flow time, or how long a feature or fix took to reach market; and flow load. Too much load on a value stream causes burnout and decreases productivity.

The key is that these measures are for each value stream, not for operations, one feature team, or a Scrum team. A value stream is usually bigger than feature teams. You then correlate the flow metrics to business results specified for that value stream: revenue, adoption for internal products such as developer platforms or APIs, cost across all specialists involved, quality, and happiness such as employee net promoter score for everyone working on the value stream. Happiness is an early warning indicator that too much load or too little time to reduce technical debt may burn people out.

Flow metrics also help end-of-life products. In project management, things go on forever. If business results are dropping while features are still being added, maybe it is time for that thing to die. Flow efficiency should measure end-to-end flow time from the customer's perspective, not only development cycle time or code commit to deploy. Dashboards should be for each value stream. They will not tell you whether you are bringing the right features to market, but they will show bottlenecks and time thieves such as dependencies slowing a value stream down.

How do we go from silos and proxy metrics to a connected value stream network that we can measure, optimize, manage, and see? We take all the different tools and create a tool network, then stop thinking about individual tools. We create an abstract model on top of the tools and measure cross-tool flow through that artifact network. We map those flows into product value streams and measure the flows there.

That lets us move from a waterfall world of projects, where we assume we know what we should deliver for years, to a flow orientation that measures results. We can still create a product development budget, but we allow reallocation between product value streams on a shorter timeframe than a year, so we can adapt to the market based on business results. We stop bringing people to the work and bring work to the people. Stable product value streams, bigger than feature teams, get autonomy, mastery, purpose, and the ability to set their flow distribution. Those teams know when they should reduce technical debt to reach a North Star and when they should move faster on feature delivery.

At Tasktop, the Flow Framework changed how I manage software delivery. We connect our value stream network: customer requests come into Salesforce, move into the product management tool, then to Jira, which is connected to contractors' Jiras, then to service desk, and so on. We have an abstract model on top of that and measure it.

A live dashboard I look at weekly shows different product value streams. It revealed something I did wrong. I set a North Star a year earlier for feature delivery, because more features would make a new product successful. I put it on the strategic plan, so some managers were bonused on it. I knew we would pick up technical debt and planned to pay it down once the product succeeded. But there was a lot of flow load, a predictable rise in defects, more defect work, and more time spent. I did not predict how much that load would affect team happiness or that we had not fully communicated that the team would later be able to reduce it.

The dashboard let me see the problem. It also showed that the team that had been unhappiest the year before became the happiest team after being given time to re-architect continuous delivery and the test infrastructure. This is useful at Tasktop scale, where I might look at six value streams, but across a portfolio of hundreds of internal and external products it becomes a very important tool.

My advice to business leaders is to define product portfolios and product value streams and track value stream metrics. Empower delivery teams to allocate flow distribution; they know when they need to reduce technical debt, and leaders need to listen. Sometimes hitting a North Star requires a global focus, such as major risk reduction or an investment in GDPR, and leaders must accept that this takes flow away from feature delivery.

To technologists: create your value stream network by connecting your tool network and abstracting over it. Define your value stream architecture, which is as important as your software architecture. Use flow metrics to identify bottlenecks. You can then see whether a team has an inverted testing pyramid, whether a CI/CD pipeline is incomplete, or where to extract a platform because everyone depends on one internal component or team.

The idea is to move from project and cost centers to product value streams; from silos and proxy metrics to flow metrics and business results; and from fragmented value streams to an integrated value stream network. The book launches November 20. We are documenting best practices at flowframework.org, and the book is at projecttoproduct.org. Gene and I are trying to understand how best to present this to CEOs, boards, and executive teams so they understand where to invest to help companies through the turning point. If you have ideas, please get in touch. Thank you; I hope you enjoy the book.