Welcome to the 100th episode of the Better ROI from Software Development podcast. In this episode, I introduce the second book that I would recommend to any non-technical CxO. Project to Product by Mik Kersten joins War and Peace and IT by Mark Schwartz on the mandatory reading list for any business leader navigating the modern digital age.
Or listen at:
Published: Wed, 15 Sep 2021 16:15:08 GMT
Links
Transcript
Hello and welcome back to the Better ROI from Software Development podcast.
And welcome to the 100th episode of this podcast.
In this 100th episode, I want to give you my second book recommendation.
In Episode 12, I introduce you to War and Peace and IT by Mark Schwartz. In this episode, I want to introduce you to Project to Product by Mik Kersten.
There are a lot of great books out there on business management, technology and software development. I read probably somewhere between 10 and 15 of these a year. But these are the two books that I really would recommend to any CxO. These are the two books that I would recommend to any non-technical exec trying to lead a business through the modern world.
The idea of project to product probably won't be a new one for any of my long term listeners. I introduced the idea of product thinking over project thinking back in episode 3.
For me, projects are the wrong way to think about software development. And in truth, I think projects are probably the wrong way of thinking about any form of knowledge work where there's a level of uncertainty.
For me, projects are time bound and force us to think about the short term, they force us to think in a narrow focus, a focus that is not the best for us delivering the right thing or indeed for long term results.
Whereas products encourage us to think of that lifetime, encourage us to think of a wider focus. And thus for me, product thinking over project thinking encourages better, healthier and more productive ways of working.
And thus its probably not much of a surprise to find myself agreeing with a book entitled "Project to Product" with a tagline of "How to survive and thrive in the age of digital disruption with a flow framework". Very much of what's in this book aligns closely to my own thinking, on my own worldviews.
But let's talk about the book itself.
For me, it probably breaks down into three main sections - setting the imperative of why an organisation needs to change, a description of product versus project, and the flow framework.
When it comes to setting the imperative of why organisations need to firstly read this book and more importantly, then change the way they're working, the book is very similar in terms of War and Peace and IT.
It sets out early why the status quo needs to change.
It very much sets out the stall of you cannot continue doing things as you have done them traditionally. Continuing to do things as you have done them will no longer see you through the modern world. It will not take your organisation through. Being good at what worked previously, is not a guarantee of being able to apply those same thinking, those same mindsets to a modern organisation.
I worry a little bit that some people may get put off the book by the phrase "digital disruption". It, like so many other phrases like agile and lean, have been corrupted a little by marketing and spin agencies almost to the point where it's just a buzzword with very little understanding to it.
Again, it may become a detractor, but in this situation, stick with the idea that it is about digital disruption.
The book sets the scene by talking about historical disruptions and then looking at how this current digital disruption is going to follow a similar trend.
And it talks about disruption from those historical technical revolutions that have impacted industry such as the Industrial Revolution, the age of steam and railways, the age of steam and heavy engineering, the age of oil and mass production.
Each of those revolutions caused a massive impact to the industries before and after. And of course, the book introduces the idea of the age of software and digital as another technical revolution that we are in the midst of. Another technical revolution that have a similar impact to industries before and after, in the same way as those other technical revolutions, the industrial revolution, the age of steam and railway, the age of steel and heavy engineering, the age of oil and mass production.
The book talks about the history of some of those other revolutions, some of the other technical innovations and how it affected organisations and how organisations that weren't appropriately equipped fell by the wayside. With other organisations that were ready to capitalise on those revolutions, on those technical innovations, skyrocketed.
The book then goes on to compare project vs. product thinking.
It looks at why we've used traditional project thinking, but why it's more appropriate now, looking at this new technical revolution, of using product thinking and summarises the differences across a number of categories - including budgeting, the time scales, you need to think about the success criteria, what risk looks like, how teams work and operate together, how work is prioritised, and how the work is made visible.
All of which are important in terms of understanding how your organisation can cope and may take advantage of the software and digital revolution.
The book then goes on to describe the flow framework, a framework for aligning the entire organisation around value streams. And it gives a way of the organisation working with product thinking.
The framework is made up of four tiers from the bottom up.
From the bottom, you have the tool network above that you have the artefact network, above that you have value stream network, and above that, at the top level, you have value stream metrics.
The lowest of these, the tool network, being closest to the technical activities - then each layer as you move up is a layer that supports the above and below layers and aligning the entire organisation to the framework, both in terms of distilling information down as well as pushing information up.
At the heart of the framework are value streams, as I introduced in the last episode. A whole layer is devoted to those value streams and the interactions between them in the value stream network.
Then at the highest level, the value stream metrics are the lifeblood of the organisation, and it's the focus of the entire framework from a top level.
It focuses on giving you business results of more value, less cost, more quality and greater happiness. And these business results are achieved through flow metrics, which they define as flow velocity, flow efficiency, flow time and flow load.
The idea of flow will be familiar if you've looked at Lean or DevOps. By improving the flow metrics, thus the flow through the value streams, we improve the business results - the business results have more value, less cost, more quality and greater happiness.
And those four layers - the value stream metrics, the value stream network, the artefact network and the tools network - work together to allow us to align our entire work all the way from the bottom, where we've got the technical activities, all the way to that top layer where we're talking about business outcomes.
I also like the way the framework describes four types of work. It describes features which deliver new business value. Defects, which delivers quality. Risks, which delivers security, governance, compliance. And debt, which delivers removal of impediments to future delivery.
And it's certainly important to get those right balance between those four - the features, defects, risk and debts - as type of work so that it bubbles up through those flow metrics properly and into the business results.
More often than not, an organisation will focus just on features. This will have long term effect - it will decrease quality, it will increase costs and probably reduce happiness because we're not covering that healthy balance that's needed by the software and thus the organisation.
I wanted to leave you with my own thoughts on the flow framework.
I'm not suggesting you take the flow framework verbatim.
But I do think it's an excellent source to start thinking. It's an excellent way of looking at your organisation and how it interacts not just with software development, but in all parts of your organisation.
And as I've said before, your business is a software company. Your business is a technology company. It is not what you thought it was. It is not an estate agents. It's not a grocers. It's not a manufacturer. It's not a logistics operation. Whatever business you're in, now the key to success is being able to move data efficiently and effectively.
You are a technology business, thus you are a software business, and thus you need to be thinking about that in terms of being able to take advantage of that software and digital age. Otherwise, you're going to be caught up and lost in the disruption caused by it.
Thus, I think this book is an excellent way of starting to think about that.
Personally, I think one of the hardest things may be to start looking at understanding what values streams you map. I think it will depend greatly on your organisation and how your organisation is managed as to what things are considered value streams.
If you ask any manager within your organisation, I wouldn't be surprised if every value stream they see is their piece of the puzzle - very narrow, focussed on their activity. Whereas what you want to do is you want to focus your value stream work on the things that really produce value for the organisation, for producing value to the customer.
And I think even that is then just a benefit, thinking about your business differently, is such a major change in how you can operate and behave as an organisation.
Now, as I've talked about previously, in culture episodes, this can be incredibly scary. It will change the management in the hierarchy. This can put people off looking at changing and adjusting the way they work. It puts them off improvement because they're defending their territory.
They may have worked really hard to reach the position they have, maybe some middle management, maybe even a CxO level, and now we're talking about reorganising the business. Changing the way the business works. Taking it away from something that they are comfortable with. Something that they used to and have actually done their entire life - and got them to the position they are. Got them the seat at the table. And then we're asking them to look at changing everything that's got them to where they are, to something else. That can be an incredibly challenging and scary thing for people to adopt, and I can understand why there's resistance to that. It's scary. It's change.
But as the book sets out in showing us history of those technical revolutions, doing the same as we used to do is not enough to survive. It is not enough to thrive going forward.
Just doing what we've done historically is not enough.
And this is one of the most major messages coming out through this and through other publications at the moment. We've trained our management teams in techniques that have worked historically. They go to university to learn these techniques. They study these techniques. There's books, there's podcasts, there's literature extolling the virtues of these legacy techniques. These techniques have worked for us. They've got us to the point where we've got to. They've brought us to the point where we are.
But as the industry changes, those are not techniques, are not management styles, are not processes that will take us into the new ways of working. It will not take us into that new industries.
And it's those organisations that realise that, that will be the ones that will be able to take advantage of that disruption - that will be able to take advantage of this new age, not just to survive, but to thrive.
And that's the reason why I recommend this as my second book to any CxO - anyone who has a level of leadership within an organisation - I recommend this book and War and Piece and IT by Mark Schwartz.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.