Welcome to the 25th episode. I decide I wanted to use this episode as both a recap to the series so far and as a good entry point for new listeners. During this episode, I'll be summarising the key takeaways so far - and which episodes to listen to if you want more.
Or listen at:
Published: Wed, 22 Jan 2020 16:55:53 GMT
Transcript
Let's start with the fundamentals;
Every business is a technology business.
It is my belief that all companies today rely on software - be that brought off the shelf or custom developed - we live in world where it becomes almost impossible to operate without software.
And overtime, the shift to custom developed software is a natural one as our businesses need more from that software. Something that gives them a competitive edge.
So if you are involved in the management or leadership of an organisation, then you will likely be involved with custom software development. Even if you are only on the receiving end of it as a user.
Software Development - along with technology in general - should now be as much a core executive skill as marketing, sales or finance.
Without that understanding, your organisation will simply not be able to compete.
You have to be taking software development seriously.
So assuming you have bought into the need for software development;
The next step is to see it as an enabler rather than a cost.
Many business I have dealt with know they require custom software to operate. But they begrudge the cost and effort to build and operate it.
They see is as a necessary evil and something to be managed down as much as possible.
They are not looking at is an enabler.
As something that is transformational to an organisation when done right.
So you should be investing time and money in innovation to that software. The question then becomes one of how to invest.
Traditional management and project techniques are unfortunately poor ways of getting good a return on your investment.
Many of us will have built our careers using command and control style management. Very much theory X thinking which would have us assume that our staff need several layers of supervision and management to be effective.
We will have been in environments where Gannt charts are used to predict the course of a given project.
Environments where we have weekly or monthly slide packs with red-amber-green status reports across a variety of projects.
And we will be familiar with the failures these bring.
No matter how good the Gannt Chart or how detailed the slide pack, projects are being constantly delivered over budget, late or not at all.
And I've talked indepth why this is.
We make a number of assumptions in building those plans.
Let me correct that.
We make a number of guesses in building those plans.
Then when those guesses turn out to be incorrect - as they will certainly be - we lay the blame at the team delivering the plan.
And how do we deal with that?
We put further supervision and micro management in place. We push for more planning, more bureaucracy.
Somehow we've been taught to ignore that actual failure and double down on it. Adding more of what is going wrong to the things that is already going wrong.
I talk about this in episode 1; why is it difficult to get the best return on investment
In episode 2, I talk about starting to change how we think about our investment - that its not about staff utilization.
I followed this with a discussion on why Projects are bad for return on investment in episode 3.
Thinking in terms of projects - with their Gannt Charts and monthly slide packs - is very much how we have done it traditionally.
But projects force us to focus on very short term aims - its what a project is - and that forces a very short term view of investment.
Given our software systems have a much longer life than any single project, then our investment is automatically skewed.
We simply aren't taking into account the total cost of ownership of that software system.
Costs such as maintenance, licences, and even decommissioning at the end of its life.
Along with that, our traditional project management approach is based on a series of guesses. Guesses which, somewhere in the project process become commitments.
We are guessing at the expected benefit of a project.
We are guessing at the complexity of a project.
We are guessing at the time and effort to deliver the project.
However, the minute that it is on a Gannt Chart or Slide Desk - deviation from that is considered a failure.
I cover some of the reasons why establishing the time and effort to deliver a software project will never be any better than a guess in episode 4.
I follow this on with a deeper dive into why software estimates should be treated as guesses rather than commitments in episode 5.
In episode 6, "Introduction to the Minimum Viable Product" I start to look at thinking about software systems as a product along with treating our changes in a much more experimental nature.
Minimum Viable Product prompts us to treat everything as a hypnosis and to design the smallest experiment to prove or disprove it.
This is very much using scientific thinking in terms of how we evolve our software system - and indeed ultimately our organisation.
I then back up the Minimum Viable Product thinking with complimentary software development practices through episodes 7 to 10.
In them I introduce;
Lean - a set of principals originating in manufacturing to reduce waste and improve flow of work through the system.
Agile - a set of principals originating from software development, focused on better ways of developing software.
Cloud - a utility method of commissioning computing systems and services.
And DevOps - a set of principals and practices that is, to me, a natural successor to both Lean & Agile and relies heavily on the enabler that the Cloud provides.
Lean, Agile, Cloud and DevOps are very important terms in modern software development. While you don't need to understand them in detail - each is a very deep subject - having a high level awareness of them is critical.
The ideals they represent are crucial for the operation of a modern business.
They teach us ways to adapt our business to not just cope, but thrive within the modern environment.
But with them come change.
In episode 11, I address a number of the cultural concerns that those changes bring.
Change can be one of the most difficult things to achieve in an organisation.
Organisations, team and even individuals can be reluctant to change.
That's understandable ... It can be scary.
And I'm asking you to give up long held beliefs, control and power.
And that acceptance of change is probably one of the hardest hurdles to overcome.
To help with the justification to make that change in episode 12 I talked about the book War and Peace and IT and in episode 13 the State of DevOps report 2019.
The State of DevOps report is an annual survey of how organisations are succeeding in the adoption of DevOps along with the benefits it brings.
The State of DevOps report is based on statistical rigor, and I point to it often as evidence of what great things can be achieved from DevOps.
In the 2019 report, it highlights that the elite performers;
- Have 208 time more frequent code deployment
- Are 106 times faster to deployment
- Are 2,604 times faster to recover from incidents
- And have 7 times lower change failure rate
The book War and Peace and IT is something I recommend every business leader read.
In the book, Mark Schwartz covers much the same ground as I do in this podcast.
And if I'm being honest, I've very much in awe of how he does it.
This should be mandatory reading.
I then move into subjects that will come up during Software Development.
Again, each is a major topic in its own right; and each episode I aim to provide enough of an overview that you are familiar of what it is, why your software development teams should be using it and the ROI benefits.
In episode 14 talks about Software Testing. Every software system developed will have bugs. That is a given.
The quicker they are identified however, the more cost effective it is for you.
Its much better for a bug to be identified minutes after a developer created it, than after 6 months of production use.
The difference financial impact to your organisation can be staggering.
Traditional software development has often left testing and Quality Assurance to the end of the work - often with it being squeezed out when deadlines loom.
I push for bringing that Quality Assurance work as early as possible to find as many bugs as early as possible.
I introduce a number of types of testing and how they fit in to assist in that Quality.
I also tie that Quality mind set back to Lean, Agile and DevOps principals.
In episode 15 follows on that Quality objective by introducing post release monitoring.
While software testing is to give us confidence and reduce risk pre-release.
Monitoring is our safety net post-release.
Again, we will have bugs that make it into production - that is inevitable.
So again the key is to identify them as quickly as possible - thus reducing their financial impact.
I then talked about its use in giving us confidence in the overall health of the system and for providing us metrics which our Minimum Viable Product experiments can be targeted against.
As Peter Drucker is credited with:
"If you can't measure it, you can't improve it"
In episode 16 introduces the term Technical Debt.
A useful way of reflecting technical problems within our Software System using the analogy of financial debt.
We all understand the idea of interest and the burden that increasing debt can put on an individual and organisation.
By equating problems in our Software Systems to a growing debt, it provides a shared language that can be useful for discussing those problems.
Understanding that you are accepting an amount of ongoing debt to achieve a short term goal is a very powerful concept.
You are then able to make a meaningful decision if its correct to accept that debt for the goal.
And you can start to get an idea of the interest that you are incurring overtime - allowing you to manage it such a way as it remains serviceable.
In episode 17 I talk about how the size and complexity of a deployable piece of software matters to the ability to deliver value to the customer - and thus ROI on our Software Development.
I introduce two architectural extremes - monoliths and microservices.
Monoliths representing software systems that are not modular. While generally easier to understand, they can be complex to change.
Microservices representing software systems that are modular. They are much easier to change, but can be more complex to understand.
I talk about why your development team maybe talking about your software system in terms of monoliths and microservices.
And why monoliths can be advantageous in obtaining initial market fit - but have shown themselves as considerable risks to an organisation as it tries to scale.
In episodes 18 through to 22 I took us through a series of tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer.
I wanted to cover some of the things that you really need to have in place from a technical level to help your development team to provide value to your customer safely and quickly.
First of these was Source Control - the system for storing the software code that we invest so much into to produce.
Source Control provides us with the security of knowing who did what and when.
Once our software code is stored in Source Control, it is then picked up by Continuous Integration.
Continuous Integration automatically verifies that the software code builds and passed our automated tests.
It ensures that the any problems from multiple developers working together is identified quicker - allowing for more cost effective resolution.
As Martin Flower described it:
"Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove."
And easier to find and remove is better for ROI.
Following that our code can then deployed by a button press by Continuous Delivery.
Continuous Delivery automates what is often a complex, expensive and error prone activity - deployment of our software system into production.
Through automation, Continuous Delivery provides us with the confidence that we can deploy our software system into production whenever we want ... Its our choice ... We just press the button.
Continuous Deployment takes that one step further by removing the button press.
It completes the pipeline that allows our development team to save change into the Source Control system and have them infront for our customer within minutes.
As I phrased it:
"one small step for deployment, one giant leap for an organisation"
This really changes the flexibility and agility of an organisation. It really supports our ability carry out multiple Minimum Viable Product style experiments per day.
I then closed out that mini-series with a discussion on how to handle incomplete code.
By improving the flow of our software code from Source Control into Production, we haven't magically removed the time it takes for our developers to produce the software code.
While we certainly will see benefits in the overall return on the work due to fast deployment and customer feedback - development is still a problem solving activity and doesn't suddenly condense from 6 months to 6 hours.
But I still advocate for putting incomplete code into our flow - into Source Control, through Continuous Integration, Delivery and Deployment and ultimately into production.
The value we get from doing so is too great to ignore.
So I cover ways to handle that incomplete code using techniques like Feature Toggles and Deployment Rings to expose the new code to only those people that should see it.
I then round out the series to date out with a discussion of two development practices that will seem very much at odds with traditional development practices - Pair Programming in episode 23 and Mob Programming in episode 24.
Both practices initially come across as prohibitively expensive by having multiple developers doing the work of one.
I re-iterate that great return from Software Development investment is not achieved by focus on developer utilisation - its from the value that the resulting software provides to our customer.
I talk about how more eyes on the code helps to produce better quality, better design, better supportability and faster delivery.
I also talk about how its a great way to learn and an enjoyable way to work.
And that brings us up to date.
I hope you are enjoying and receiving benefit from this series.
If you are ... Or even if you're not ... Reach out to me on Twitter @redfoldermark.
I'd love to receive feedback on the series - along with areas for improvement.
I've already got plans for the next few episodes ... With probably another recap when I reach the 50th episode.
Thanks you for listening