JOURNALFrom Project to Product
The future is flow
Posted by Gillian Clark . Apr 06.21
Last week, we hosted an executive round table with senior leaders of some of New Zealand’s largest enterprises. On the breakfast menu was the shift from Project to Product – how focusing on flow with Value Stream Management is the Quiet Revolution that will become the next new normal management practice. Dr. Mik Kersten and Eric Willeke, global authorities on VSM, shared their views and experiences with our audience. Here are the highlights...
On the Golden Age – the shift to economies of flow
We're at the end of the Turning Point, though it depends a little on which industry. Retail is beyond the Turning Point – you've either adapted or have a major problem. Applying the practices that the tech giants and unicorns and startups apply no longer feels like it's innovation – it's about mastering software at scale. Some companies don't have that capability so our goal here is to help put those practices in place, to start thinking and operating in terms of Value Streams. We're still at the point where a lot of organisations haven't understood this at the leadership level because their backgrounds are from working in economies of scale and not the economies of flow.
On creating alignment on investment decisions
Time and time again, teams say they have too much work. Of course they have too much work! In the modern era, we have more product that we want to build and that anybody can envision. But why is there too much work? I found myself working with executive teams who couldn't identify alignment within themselves let alone identify alignment across the organisation. All the work was coming from the leadership team because you might have five or seven leaders, each putting their own projects and initiatives forward and these would cascade down through the random project network to the same team.
Focusing on Value Streams, finding that end-to-end value for internal products and external products, is really about identifying a product landscape, a language, the topology of the organisation. Then you can use that to generate alignment within your leadership team… you have a high-level understanding of the shape of your products and your Value Streams, both external and internal, so you can start to have much better conversations as executives about which things you want to invest in and where the most important elements to advance a strategy lie.
We need leadership to be able to see the dynamics of the Value Streams of software delivery…. then everyone is in the same boat of driving business results through better flow. We need to understand that technical investment results in better flow, the delivery of more value and better business outcomes, such as better customer conversion, higher revenue, lower costs.
I’ve seen a business where 99% of the time the work that should have been done is stuck, waiting on some dependency, some security review, some compliance process, and from the overload on those Value Streams themselves, because so much work had been put on the teams.
The investment difference between internal and external products is a really big issue now. I see in most large enterprises a systemic underinvestment in internal products in favour of external ones. But the bottlenecks and constraints in external products are because of the problems in the internal products. We see the dependencies once we start measuring flow. So I think the key thing is internal product Value Streams need to be celebrated, augmented and invested in further because they power all the external ones. We can't have initiatives where we say, for example, technical debt is something that we're going to tackle next year… or we're going to commit just 30% of the budget on technical initiatives.
On shifting from Project to Product
I feel a lot of people in companies start to slip when they look at a Value Stream as if it's a process – it's just a bunch of boxes on a flowchart or something. One of my cardinal rules of agility is Value Streams are firstly about people. And if I take a look at a new business's initiative or feature or capability that it wants to deliver, the first thing I do is look across the company, see who has to touch it, what people and/or Agile teams are necessary to bring that work to fruition. At a certain level, that's your Value Stream. Beyond those people and teams, it's the funding, the support systems, the development environments and the release pipelines that are necessary to deploy. All of that also becomes your Value Stream.
On getting the board to think about funding models
The funding model is critical. But changing from a project to a product-funding model requires political change. To do that overnight is quite hard. You have to be careful about snapping back into the old model. I think what executives love is metrics that are meaningful and predictive to them. The metrics they had in the past were org charts and costs. So find the new set of metrics that actually empowers leadership and executives – measuring value and flow. Then find a champion in finance or in the PMO… someone who will understand why actually measuring value and flow is going to be more meaningful for the organisation than simply measuring cost alone. You don’t stop measuring cost, you just start measuring cost differently because you do it less by silo and more by Value Stream. The finance people get excited about this – they have a value metric for a Value Stream and a cost metric for a Value Stream. Another big benefit the finance team and PMO will love in a new funding model is that most organisations have a staggering number of resource allocation and reallocation requests a year, resulting in new allocations and then allocations of reallocations. With stable product Value Streams, these requests basically disappear!
I take change itself and treat it like a product. I model my transformation teams through stakeholder mapping. If I want to make that shift to a different way of thinking, I map who’s involved and what's in it for them, I do the empathy interviews, the analysis and treat them as the market. I don't expect anybody to take it on belief. I'm not going to come in and just say “Hey, Agile is gonna make everything better”. I'm going to ask how I can generate proof – metrics – that show people how this is going to make their life and the company better. I want to do that for each stakeholder that's impacted by change.
I’ll find champions in an area of the organisation where I can carve off a product (-like-shape… it doesn't have to be the ideal product shape) and use that to experiment with the change and prove that it works. Once we start generating proof, people get excited. I can show the old metrics and the new metrics side-by-side. Groups that are doing better are the ones focused on the new metrics. Like taking the architectural pattern or strangulation pattern for transitioning systems, you can apply it to change management. People will increasingly use the new ways, not the old ways. And you slowly turn off the old reports and nobody cares! If you want a bigger bang you'd have to convince more people. If you want sustainable change, just start generating proof and people come along.
With a shift to product Value Stream and metrics, the bottlenecks you find are stark. There's a lot of low-hanging fruit to pick. So much that you can probably double the pace of delivery in fairly short order. You can hit on better business outcomes faster than anyone's ever seen before. And that's just immensely powerful. So don't go try and convince everybody, go prove it. I like Eric’s strangler pattern metaphor… applying how you move off legacy systems in the context of change management.
As a consultant, often I find the first big part of an engagement is getting people to stop talking about Agile and start talking about how to make your company better. One of the biggest risks I see is premature scaling where something is taken on confidence or taken on a standard model without adjusting that model and testing it. I see companies go from exploring agility where a few teams are trying it and then they try to expand it so fast – a phase two that I call ‘exploding agility’ – where it just blows up because nothing works, because you haven't slowed down to fix all of your different systems and infrastructure and policies and procedures, and everything else that has to happen inside your organisation to use these new tools. Instead. I like to ‘tap the brakes first’ and prove it works.
I intentionally slow down while there's still a lot of pull in demand. I use that desire to start to fix the systems in a couple of critical initiatives, a couple of things that the company has to care about on the scorecard, then over focus on changing those well. I pull everybody that's impacted by the change to a product way of thinking and figure out how to make agility work for everybody, not just technology. Then, once you do that, then you can start to expand rapidly without things blowing up.
Say we've got 500 people and we’re investing in some products we want to make faster and better – getting the existing flow for those working better. We’ll hire new people and put them into those products. Then you can make the highway bigger because you’re growing the new model. Whatever you do, resist the urge to grow (hire) into the old model because you're just creating a bigger change backlog and a bigger problem for yourself in the future – you'll outgrow your ability to deliver. So ease the right talent into your growth where flow is already good or improving. Get the stability there first, make those products your bright spot and then hire into them in order to grow your teams.
I was working with the CIO of a major US insurer. We measured their Flow Time – how long it was taking to get significant new features and functionality to their customers across their 200 Value Streams. There were a lot of mobile and web initiatives that they believed were really strategic to them. But Flow Time average was 120 days. And so, of course, the business said, “We're up against all these insurance startups, we need to run faster and deliver more quickly”. So they started a massive recruiting initiative on the assumption that the bottleneck was too few developers. But when we looked at the data to understand how many days were spent in development in the end-to-end Flow Time of 120 days, it was just under three days. Hiring more developers wouldn’t help because obviously that wasn’t the constraint! The key constraint turned out to be that their ratio of graphic designers to developers was worse than 1:100. With all those mobile and web initiatives, the design of modern user experiences was critical. We found their competitors had ratios closer to one designer for every seven developers (1:7). So the key thing is understanding your Value Streams, where the bottlenecks are, and investing to remove them.
Imagine development suddenly became magical and it cost zero days and $0 – the moment you started to write a feature it was instantly done. How quickly can this feature be delivered? You still have to do all of your upfront approval processes, chartering, annual budgeting etc., plus all of the existing release cycles, approvals and, or course, everything else downstream. Ask yourself how much that free feature actually costs. How much time and money does it really take to deliver something through the end-to-end Value Stream when you take development costs completely out of it. It’s weeks or months and, in one case, I found 24 months of delay.
On ‘operate, change and reduce costs. All at the same time’
One of my biggest frustrations is when I see that every department is expected to reduce their costs. I have no problem with cost-reduction initiatives, as long as they're targeted in the parts of your product portfolio that deserve to have their costs reduced. Moore’s ‘Horizons’ model is my go-to perspective here. When you're no longer actively investing to grow your market share, you are just ‘operating’ and you should do everything you can to reduce costs and improve your margins. But if you're transforming or trying to incubate a new technology or new business, don’t try to reduce costs at the same time or you'll just cripple growth. So I very carefully, but directly engage when people start to talk about cost-reduction initiatives, making sure about the intention of transformation, about the outcomes that need to be achieved and ensuring that you're creating space for that change and growth. There has to be capacity for change and this takes time and energy and money.
It's actually about segmenting and understanding your product portfolio and then giving each part of that portfolio relevant business results in terms of the Flow Metrics that they're being optimised for. So you want to optimise your work in Productivity or Performance Zones to take out costs in systems used to run the business – those off-the-shelf solutions, SAS solutions, data centres and other things that you might want to eventually retire. Then you've got your Transformation Zone, which is where you do new things – say a new product offering – and your Incubation Zone where you prove out altogether new ideas – that’s where you invest and you invest for faster flow. The tangible example I give is BMW when it was dealing with disruption by Tesla years ago. BMW had plenty of cost-cutting initiatives going on, but at the same time they invested heavily in the ‘i programme’ (electric cars). The whole car was carbon fibre and carbon fibre is really expensive. Ramping up all that battery production and manufacturing was really expensive too. But they knew that their only shot at surviving the next 20 years was to actually invest in learning how to get good at building electric cars and to eventually bring that capability to their other production lines. It was a really large investment with no corresponding profitability as its business case. Measuring those Value Streams for profitability would have been the wrong thing to do. It was always going to be more expensive because the primary thing BMW was getting was an education – learning about new business models, new business cases and new markets. The programme was actually transforming the company's business case.
On visualising Product Architecture to make decisions
I want to highlight something that's a foundation for just about everything Mik and I are talking about. It's having that understanding of your product portfolio so you can talk about these things. It’s critical to understand where in the horizons and zones any part of the product portfolio lies, and then to set the right metrics for it accordingly. ‘Product Architecture’ or ‘Product Portfolio Management’ is the language I use, creating a visual map to understand the product architecture across the board to enable the right conversations and making the right decisions. You’ll generate the nuance of saying that “in this two-thirds of my portfolio, we’ll reduce the cost. But this slice, we're going to over invest because we want change there”. Across the scale – from startups coming out their third or fourth external product to a 30-year-old company with 400 people that has a dozen products – I see a huge lack of understanding of that Product Architecture as they talk about making changes. A simple Product Map will help you start to gain either consensus within your leadership team, where you don't agree and where you don't have a common language for reality. It gives you a lot more nuance in how you steer and invest in your business and it’s probably the foundational capability that allows you to both reduce costs and grow your capabilities.
Tech companies are really, really good at managing their product portfolios – not just for launching new things, but sunsetting and ending the life of old ones. Legacy enterprises are really, really bad at this. It’s happened because of their old ‘project mindset’, where they just take on more and more and more until the support and maintenance base of legacy projects becomes so significant that it gets in the way of innovation.
On introducing Value Streams successfully
Make sure you establish a baseline and measure the right things. You want to demonstrate that this investment and that this change actually produces the result. So my focus would be on making sure that you're measuring the Flow Metrics in the Flow Framework®, defining the business outcomes you want. It might simply be a measure of their Employee Net Promoter (staff engagement) Scores before the shift and after. And if you can show to your business that you've got happier staff and making better software, and bringing it to market more quickly, that's just such a powerful thing.
You’ll need to make sure you have business-wide engagement – team of teams level, the actual Value Stream level. If it's just limited to technology teams working for themselves and the business partners or the people close to the business and the customer are disengaged, that won't work.
I've also seen things go sideways when the business side sees a shift from project to product to Value Streams, as a way to make sure that teams get more done. Teams will end up with even less capacity and their backlogs get even bigger.
Finally from me, avoid an ‘A-to-B’ understanding because there isn't really a finish line. Things will evolve all the time and this change is going to become a way of life.
I think you have to tie a shift from project to product with a bigger change that matters to the company. Don't just do this as its own thing, align it to a much wider all-business goal and make sure that you're advancing the cause of your business partners, not just doing it as a technology thing, or as a process-driven thing or strategy-driven thing. It needs to be aligned to something that truly matters and impacts the company as a whole.
Another one is keep it simple. And then emerge the complexity inside the simple container. So I like to say the first draft has to fit on a page. It's just a bunch of big boxes that are your product families. And then inside of those product families, you start to detail the next layer of complexity, using the people that are inside that product family to do the work. And if you have a bigger company, nest and rinse and repeat further down – don't try to do a bottom-up assembly. Start with the big box and work your way down and out.
Then iterate and learn because you're going to get it wrong. I don't think I've seen a single company get their product shape right the first time. Give yourself permission to make those mistakes, learn and make sure that’s heard especially at the level of leadership. You're modelling the safety that allows your teams to iterate and refine and not be right the first time.
On catalysts for, and leading, change
One catalyst I saw which was very effective was with my teams (here at Tasktop). I just put the product portfolio, the Flow Metrics and the business metrics in my board slide deck without values and I told my team we had to populate them. It was a very good catalyst for change because it was effectively asking ‘what do we really care about reporting at the CEO and board level? How are we doing on this product and that product?’
You might want to put something to your directors which you're not ready for but it starts the right kind of conversations. It starts people thinking about what parts of flow do we care most about. What in our product portfolio is really at the business level? What do we want to invest in and grow versus sustaining something. As leaders, we have a sense for where we want to take our organisations and where the big opportunities are between technology and the business.
Change is much harder than it should be and is much more prone to failure. One of my focus areas right now is what I'm calling compassionate change. I think, as the leaders in the room, we're in the business of change management. What challenges almost every leader is how do you both operate and drive change at the same time? Change management is the compassionate part that I'm trying to bring in – a little more humanity – because it's fundamentally a human-driven activity and you're asking the people that work for you to behave differently at every level of the organisation.
When you have a great view of your internal and external products, you can start to bring purpose to your portfolio. Every product, every product family should have a clear vision and clear purpose about what it’s trying to achieve for the company and for the world. This becomes a language that pulls your people forward… we need to engage our employees in a different way and bringing purpose to the work they do is one of the most powerful techniques I've seen to do that.
You need to get beyond ‘mechanical agility’ – where people are just throwing processes at things expecting transformative results. Changing a process may get you a small percentage improvement, but changing how you lead the company and how people behave at a cultural level... that's where you get the 10x or the 30x improvements.
Most companies will be stressed as they go through a product transformation – you’re asking silos that previously ran their own shops to work together and share results. Successful transformation starts right at the top with the executive leadership team – if they're not used to truly working as a cross-functional team and sharing outcomes, then that behaviour is going to cascade down through the rest of the organisation. Leadership must start to model working as an actual team of a team of leaders, not just a group of leaders. If you get that group aligned and operating as the team behind the changes – leading with a product mindset themselves – the belief and alignment will inspire both the board and the rest of the organisation to come on the journey. So pay attention to the human side of the change – compassionate change. Make change a lot less threatening for people.
You’re winning when everyone is on the same page looking to remove impediments to flow and delivering more to the customer and the business. When you're fixing bottlenecks, you're making teams happy because you're taking friction out of their way, they're able to do more value work in their day and everyone's happier.
Read more about the Quiet Revolution...
Subscribe to our digital magazine
Signing up for an Emergent VIP subscription also gets you that annoying validation email that helps prove you’re a human with a real email address. If you’re angsty about that because you don’t want to be bombarded by newsletter nonsense, here’s a promise... We’ll email you:
- Twice a year to give you access to the Magazine
- Twice a year with priority invitations to events (48hrs ahead of any public offering)
- No more than three emails telling you of early-bird availability on the best Agile training in New Zealand. Your VIP sub entitles you to 10% off courses at any time, but 20% off in conjunction with the early-bird booking discount
And, of course, if you don’t like what you get, you can always unsubscribe. But please, subscribe first…