The Business of Legacy - Making Software Change Successful

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]