#158: The Pitch - one-size does not fill all

In episode 150, I reintroduced this series with a new pitch. It was my way of taking what I've learnt over the last three years, the last 150 episodes, and almost 33 hours of content and updating the why of the podcast. Over recent episodes, I've take a deeper dive into the themes of the pitch and why they made the cut.

And in this weeks episode, I want to explore the idea that there is no a one-size fits all approach to Software Development

Or listen at:

Published: Wed, 14 Dec 2022 16:43:40 GMT

Links

Transcript

Hi.

In episode 150, I re-introduced this series with a new pitch. It was my way of taking what I've learned over the last three years, the last 150 episodes and almost 33 hours of content, and updating the "why" of the podcast.

Over a number of episodes, I've been taking a deeper dive into the themes of the pitch and why they made the cut. If you've not listened to the pitch, it's worth pausing and going back to episode 150 for context.

In episode 152-154, I talked about the business side of the pitch. Almost half of the pitch was devoted to the business context that we are doing our Software Development in and why our organisations are under so much pressure to change - and possibly most importantly, how each organisation needs to embrace changes something they do rather than something that happens to them.

In episode 155, I moved on to exploring the second half of the pitch, the actual Software Development part. And in that episode I talked about how Software Development was a young, evolving field - a long way from achieving maturity and as such, need support from organisational leadership to learn and improve.

In episode 156, I talked about the history of management practices and how much of what we know today has its roots in Scientific Management, or Taylorism, which aimed to improve the efficiency of the deterministic work - work that we can know ahead of time and is best suited by carrying out pre-defined Best Practice.

And in the last episode I use the Cynefix framework to help us understand why software development cannot be deterministic - why do we have so many unknowns? why can't we make it as deterministic as moving pig iron or flipping hamburgers at McDonald's?

The Cynefin frameworks helps us to understand the deterministic work falls into the Clear domain, the domain best handled with Best Practice.

And that Software Development will either fall into the Complicated or Complex domain, with Complicated being best served with Good Practice and Complex being served with Emergent Practice.

And in this week's episode, I want to explore the idea that there is no one-size fits all approach to software development.

So from the pitch:

"So what is the solution to this?

What is a silver bullet?

What is the magic unicorn dust that can be sprinkled over the problem?

I'm sorry, but there isn't one. Like the Age of Software and Digital itself, getting the best from Software Development is an emergent field. Indeed, like any knowledge-work - any work that is fundamentally a thinking problem, a problem solving activity - we are learning how to do it better daily."

Unfortunately, getting the best from your software development isn't easy. It isn't quick. And can often feel counterproductive.

And regardless of what highly lucrative consulting firms will tell you, it is not a two day training course and following a prescriptive application - I even covered this in episode 67 "Bad for ROI - the Silver Bullet" - expecting to use any quick fix scheme is only ever going to cause more problems down the road.

The Software Development community has learnt that each individual organisation, and even team, is different. There is no cookie cutter approach that can be used, but rather there are lessons to be learnt and adapted.

Now this lines up nicely with the recommended approaches from the Cynefin framework, the use of Good Practice for Complicated domains and Emergent Practice for Complex domains. Only in that Clear domain can you expect good results from prescriptive Best Practice - and we've already ruled out the chance that Software Development will ever be within that Clear domain.

That isn't to say that the Software Development industry hasn't tried to implement what it thinks may be Best Practice, only to find what worked well in one environment wasn't well suited for another - which would have been expected had they consulted the Cynfin framework in advance.

The practice of copying blindly has even been given a term "Cargo Cult Programming.

From Wikipedia, Cargo Cult Programming is defined as:

"by slavishly following a software development process without understanding the reasoning behind it

The term cargo cult as an idiom originally referred to aboriginal religions that grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like beings who arrived in airplanes that had brought marvelous cargo during the war."

Possibly the canonical example of this is the Spotify model.

In 2012, Spotify shared with the world how it did things - I include an article discussing it in the show notes.

The Spotify model was welcomed by the Software Development community at large as a proven approach from one of the world's largest software organisations. It was exceptionally exciting to get that much insight into how Spotify was doing so well.

And of course, there were those that wanted the same level of success that Spotify enjoyed.

Thus, many organisations attempted to replicate it by rote.

Yet, even as they shared the model with the world, Spotify made it clear that the model was always adapting, always learning and improving. The model being demonstrated would not be the same model in place within five years, a year, a month, possibly not even by the end of that presentation. It was never meant to be a prescriptive approach.

It was part of that shared learning. By sharing what worked for them, it helped to share ideas and concepts that could be considered by other organisations - used for inspiration - not to be followed as a cargo cult.

And those organisations that attempted to replicate by rote soon found this out.

And that same practice has been seen with organisations slavishly adopting Agile, Scrum, or any other number of practices without fully understanding them - with those organisations failing to learn from the approaches and adapting as necessary for their unique environment.

It doesn't take much to find organisations or professionals that have been scarred by some failing initiative, now reluctant to try again, because they failed to understand it in the first place. And this is where we often see negativity and resistance to taking some of these approaches back up again. When organisations do not experience the predicted outcome, there is a swing back to what they had previously believed to have worked.

So if we shouldn't be following by rote, what should we be doing?

We should be taking these Good and Emergent practices and experimenting with them.

We should treat them with the same Scientific Method approach I've advocated for all of our Software Development:

  • We observe,
  • we question,
  • we hypothesise,
  • we experiment,
  • we analyse the results,
  • we draw conclusions,
  • and then we repeat again and again and again - a continual learning cycle.

It takes continual work to improve and get better. We should always be learning. We should always strive for our organisations, our teams, our individuals to always be learning.

And sometimes it can feel like a pendulum as we swing one direction with an experiment only to swing back again based on the results. But in truth, this is better explained as an upward spiral. Yes, we may feel like we're always spinning from side to side to get the best balance, but we are always moving upwards, always improving, always being better.

And for me, this is a very personal story. I've been at software development for over 30 years.

I learned my management craft based on Taylorism and Scientific Management. I gained great personal success from using them.

And as I've then learned better approaches, I've tried to slavishly replicate them. And I've learned the mistakes of that.

I realised I still need to learn. And I will never be finished in learning how to be better at my craft.

And in that, this podcast series is partly about sharing my success and mistakes - but also to encourage me to learn more, learn faster and improve myself.

I now like to consider myself someone that has strong opinions that are weakly held. If I can find something that I believe to be right, has a better way of doing, or actually is producing a negative effect, then I change my stance - I adapt, I grow, I learn.

I take evidence based approaches in trying to find the best way to do my work and Software Development as a whole. And with that, I embrace the fact there are things I don't know. I embrace the fact that I could be wrong. And I embrace the fact that the second half of my career, the next 30 years, I will have to continue to learn. I embrace the fact that learning is probably one of the most important things I can do for myself, my family, my organisations and the teams that I work with.

And this concludes the series of episodes looking at the themes of the pitch. I hope this has helped to expand on the pitch and why I felt that various sections had merit, along with some background behind them.

Thank you for taking your time to listen to this podcast. I look forward to speaking to you again next week.