We are bombarded with the need for business change - which means systems change. At the same time, we need to be faster, safer and more secure than ever. How can you learn to make software delivery effortless, and how can you use the best knowledge on the planet to help you?

In this episode, I introduce the best books on software and IT change in business and how I would deliver effortless change dependent on context. If you want to know where to start tackling legacy systems change, start here.

NOTES

Check out this link for the map of the Books I mention in the podcast:

https://richardwbown.com/how-does-ability-to-innovate-impact-bottom-line/

• Domain Driven Design by Eric Evans (the blue book)
• Test Driven Development by Example by Kent Beck
• Out of the Crisis by W. Edwards Deming
• The Phoenix Project and the Unicorn Project by Gene Kim et al
• Team Topologies by Matthew Skelton and Manuel Pais
• The Goal by Eli Goldratt
• Crossing the Chasm by Geoffrey A Moore
• Working Effectively with Legacy Code by Michael Feathers
• Obviously Awesome by April Dunford
• Accelerate by Nicole Forsgren, Jez Humble and Gene Kim
• The Value Flywheel Effect by David Anderson et al
• The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, John Willis and Nicole Forsgren

QUOTES

[01:18] "So what is the secret glue that holds successful tech companies together and lets them succeed with it and software delivery where others fail?" [RB]

[01:55] "From what I can see, there is no secret to success in software change for your business. You need to be clear, consistent, pragmatic" [RB]

[02:22] "These are some of the lessons already distilled from the biggest and the best companies on the planet" [RB]

[02:37] "This, how quickly can your systems react and anticipate to changing market conditions? " [RB]

[03:47] "Almost anyone can manage IT and software delivery but the best always ask what appear to be on the surface, the most obscure, unrelated, or perhaps downright stupid questions." [RB]

[04:24] " it helps if you have a decent, wide base of technical knowledge before you start asking the questions" [RB]

[05:11] "So find the rough spots. Be an ear to those who are upset or disaffected or annoyed by how things are going now, and use their knowledge to inform your opinion" [RB]

[06:10] "At that point, no matter what the size or the shape of the system or the solution you're proposing, you'll be in a position to potentially deliver something that might make a difference to the business." [RB]

[06:43] "Ensuring that you have listened and understood is a priority. Then show how change can work for everyone and finally, show the results." [RB]

[07:10] "Therefore, it is not your change, it is the business' change, it is everybody's change" [RB]

[08:05] "I've put together a map of the best books that I feel contribute to this area, and I've also created a suggested path, which will help you navigate" [RB]

[09:41] "You can't afford to ignore product development as part of software development these days" [RB]

[10:59] "software deployment in a real life situation is always inevitably going to involve a legacy system or is going to involve a legacy decision that you've made on a previous deployment." [RB]

Hello, I'm Richard Bown and welcome to the Loving

Legacy Podcast, episode 30.

This is your regular dose of discussion that helps you pick the path between

complex human systems and the accompanying complex software systems.

This time I'm talking about the business of legacy, or how the world's leading

companies make software change successful over the last year in an effort to make

more sense of the world of building commercial and enterprise software.

I've talked to lots of people.

I've been reading a lot of newer and older books that speak about software

delivery, business efficiency systems, product processes, and organization.

These all give a perspective on the human aspect of business delivery

systems, which is now, of course, pretty much software systems delivery.

Business delivery can be something.

Like a production line for a manufacturing company or a system that provides direct

value to an end user, say a website for a retailer or perhaps a business to business

system that allows better integration and eventually leads to downstream

sales or savings or an opportunity.

Wherever systems are built these days, they are partly software,

partly IT change and partly social.

So what is the secret glue that holds successful tech companies together

and lets them succeed with it and software delivery where others fail?

This is what I want to understand today.

If you read any of the great books out there, like Accelerate or Team to

Apologies or the Value Flywheel Effects, They will all give you case studies and

there must have been millions, if not billions, maybe of words written on the

subject, let alone talked about by now.

So none of this stuff is really secret.

It's just complicated.

It's out there, but it's hard to get to the, the bit that you need to understand

in order to go forward with your business.

From what I can see, there is no secret to success in software

change for your business.

You need to be clear, consistent, pragmatic.

You need to be bold, but also bold enough to know when to pivot.

The way I've boiled it down is a bit like this.

There is a process you can follow to make any businesses a success,

but you also need to be able to react to changing circumstances.

And then you also always need a little bit of luck on your.

These are some of the lessons already distilled from the biggest and the

best companies on the planet, the ones that run the big supply chains, the big

manufacturers, the digital exchanges, the ones who make a lot of the money,

the essence of modern businesses.

This, how quickly can your systems react and anticipate

to changing market conditions?

How reliable are they?

How resilient are they?

How secure are they and how do we make software change successful

while doing all these things?

What can we learn about existing best practices and the experience and stories

of hundreds and thousands of engineers that have gone before and more than that

with so much information and best practice out there, how do you make sense of it

all and know what to do and when I would.

All of this starts with learning.

You need to have a baseline of knowledge to understand how to work with IT

systems and software together with Legacy in the modern enterprise or

in the modern startup because none of us working in any company of any size

lives in a world free of legacy systems.

All systems are ones which we'll need to do something about

at some time in the future.

So how can we learn to love our systems and how can we learn to live with them?

My approach, the approach I've always taken is to keep learning.

And the best way to keep learning is to keep asking questions.

Almost anyone can manage IT and software delivery but the best always

ask what appear to be on the surface, the most obscure, unrelated, or

perhaps downright stupid questions.

When I start a new job, I learn by listening, by reading, by starting to ask

questions to everybody that is around me.

And then also I start to question some of the assumptions I'm making when

I'm exposed to the way things work.

Before you can ask the right stupid questions you need

to know what you don't know.

You need a framework for something to put your knowledge upon.

Therefore, it helps if you have a decent, wide base of technical

knowledge before you start asking the questions in the first place.

Especially if you're talking to technical people.

That replies you're gonna get are usually going to be technical in nature

and they might be quite wide ranging.

Learning a technical discipline and reading around that subject

will help you talk to the techies.

Secondly, you need to learn the domain that you're working in.

The business does something to make its money.

And now this is your primary concern.

Make sure you spend as much time as you can learning about the intricacies

of the business from the people who are closest to the customer.

These are the people who will have discovered all the friction with

the existing systems and are the most invested in making a new system

that works better than the old one.

So find the rough spots.

Be an ear to those who are upset or disaffected or annoyed by how

things are going now, and use their knowledge to inform your opinion.

Thirdly, try to model something.

Use the knowledge of the system, the knowledge that you've gained from the

people you've spoken to in the business.

User knowledge or reactions of the customers you have contact

with to play with some idea.

You can run these out as questions to begin with.

What would happen, for example, if we didn't have a system here, or we

did this manually, or we automated this piece of work, how do you

think that would change anything?

You can also do modeling in your head or modeling on paper to understand

better and analyze a situation.

Finally, when you have a solution, get confirmation that what you want

to try is the right next thing to do.

Make sure that you get technical, functional, and business buy-in, and that

everyone is aligned to accept this change.

At that point, no matter what the size or the shape of the system or the solution

you're proposing, you'll be in a position to potentially deliver something that

might make a difference to the business.

But don't leave that to chance.

Don't leave the.

To chance, try as closely as you can to track the course of this work in

order to show what you have achieved.

It's not enough sometimes to sweat away tirelessly working on a solution

which no one is interested in.

Likewise, it's no good making projections based on little knowledge of the

technical or functional landscape.

Ensuring that you have listened and understood is a priority.

Then show how change can work for everyone and finally, show the results.

All of this is a learning path to a successful software change.

Whether you are a dedicated staffer, a consultant, an external

contractor, it doesn't matter what your investment is in the firm you

work for, you are working together to make the business more successful.

Therefore, it is not your change, it is the business'

change, it is everybody's change.

This is a mindset that asks questions to find out what people

know and what people don't know.

When you get people to confront what they know and what they don't

know, they sometimes think long and hard about what they're doing

and why it's good to make a change.

So as a starting point, how do you know what to do and how do

you know what you don't know?

And how do you know what is the best next thing to do to make a change?

This very much depends on your journey.

Very much depends on your knowledge and where you're

starting from with the business.

For example, you may be technically capable but unsure

where the actual pain is.

As a techie, you might want to feel that you're working on something

that is delivering business value.

As a manager, you are closer to the business impact of changes.

So your responsibility is to help show this impact to everyone you work.

I've put together a map of the best books that I feel contribute to

this area, and I've also created a suggested path, which will help you

navigate these books or navigate this knowledge in a way that depends on the

context which you're starting from.

The books are as follows, and I'll link this in the show notes.

Domain driven, designed by Eric Evans, also known as the Blue Book, test

Driven Development by example, by Kent Beck ,Out of the Crisis by w Edwards.

The Phoenix Project and The Unicorn Project by jean Kim, and others, Team

Topologies by Matthew Skelton and Manual Pais ,The Goal by Eli Goldratt,

Crossing the Chasm by Jeffrey Moore.

Working effectively with Legacy Code by Michael Feathers,

obviously awesome by April Dunford.

Accelerate by Nicole Forsgren, Jess, humble and Gene Kim.

The Value Flywheel Effect by David Anderson et al and the DevOps Handbook by

some other names I've already mentioned.

These are mainly software related books at various levels of scale, from

architecture to delivery, approach to team, and organizational concerns.

Additionally, there are two business process related books,

the Goal and Outta the Crisis.

The goal in particular, has influenced many of the things that we do day to day

now books such as The Phoenix Project, which was very much a peon to that book.

Very much a tribute to that book.

Plus I've also included two product related books in crossing

the Chasm and obviously awesome.

You can't afford to ignore product development as part of

software development these days.

I would argue that having a nodding reference to all of these books would

give a great view of software product development and product delivery in 2023.

Additionally, depending on your context, whether you are struggling

with legacy systems, technical debt, too much bureaucracy or that you

just lack an idea where to start.

Then look at the diagram in the link that I've included and follow the arrows.

From that perspective, this will give you a context and a way forward.

I hope you've found this useful today.

I've been trying to work some context into the reading that

I've been doing, and as I work.

Interactions with clients.

I also see that the ideas and lots of these books can be

useful at certain points in time.

However, your context will always differ, and if you read any of these books, it

will say that very clearly in all of them.

Your individual context is something that you need to be aware of.

So by finding your context, finding out where you are starting, then

you can start to approach tackling.

Any particular challenge that you have with software deployment in a real life

situation, software deployment in a real life situation is always inevitably

going to involve a legacy system or is going to involve a legacy decision that

you've made on a previous deployment.

Therefore, it is essential to be able to understand the full

context in order to move forward.

I hope you find.

This list useful.

I hope you find this episode useful.

Thank you for joining me.

My name's Richard Bown.

This has been The Loving Legacy Podcast.