In the last five episodes I've introduced a number of terms to help us move away from the traditional software development practices. In episode 6, I introduced the Minimum Viable Product as a way to rethink our traditional ideas of waterfall style software projects. I recommend using MVP as a way to approach the traditional problems of unknown benefits, unknown costs and unknown risks. In episode 7, I introduced Lean as a backup to the mind set behind Minimum Viable Product. Lean's strong manufacturing pedigree stands out as a proven method of reducing waste, delivering faster throughput and ultimately value to the customer. In episode 8, I introduce Agile as a complementary mind set to back up Minimum Viable Product. I introduced the Agile Manifest; the commitment behind much of the work in the Agile movement since 2001. I showed how the manifestos recommendations aligned with Lean and MVP. In episode 9, I introduced the Cloud as a key enabled to support the adoption of Minimum Viable Product, Lean and Agile. I talked about the value that the flexibility of the Cloud can provide - along with the potentially market changing opportunities made available by initiative services the Cloud makes available. And in the last episode, episode 10, I introduced DevOps as a set of practices and process that build on a Lean & Agile heritage. I also introduced the State of DevOps report as providing evidence that DevOps is helping organisations meet and exceed their goals. In this episode, I want to take a step back and address some of cultural issues that these episodes generate.
Or listen at:
Published: Wed, 02 Oct 2019 15:45:57 GMT
Transcript
You organisation will have to change if you want to receive the best return on your investment from Software Development.
Actually, let me rephrase that;
Your organisation will have to change to survive.
That is simply the environment we are in.
Every organisation must be willing and able to adapt to the markets, customers and environments we find ourselves in.
That ability to adapt will be the key differentiator over an organisations ability to compete.
There is plenty of evidence that being the biggest or the oldest just isn't enough any more.
But for many organisations, change is scary. Something they have an institutionalised fear of.
And there is no way of sugar coating it, to get the best ROI from Software Development your organisation - and its culture - will need to change.
To get the best from Minimum Viable Product, Lean, Agile, Cloud and DevOps may organisational norms need to be broken down.
The traditional silo'd department needs to go.
The traditional accountability models need to go.
The traditional control structures need to go.
Yes, an organisation will see benefit from local adoption of some of the practices advocated by Lean, Agile and DevOps.
For example, Automated Testing can provide benefits to a traditional Software Development team. And it can actually be good initial steps on an organisations journey to embed some of the practices and processes locally first.
But ultimately, it will simply highlight the problems elsewhere in the organisation.
If you have a production line made up of three sequential steps - there is only so much benefit you will achieve from continual focus on step 2.
At some point the overall production line will either be limited by the output from step 1 or be blocked by the ineffectiveness of step 3.
At some point you have to look at the whole.
Many of the practices from Minimum Viable Product, Lean, Agile and DevOps simply cannot be achieved by a single team on their own.
Without doubt, to achieve the transformation that your organisation will require, it needs to come from the top.
The executive need to set the appropriate culture and imperative to change.
Without that reassurance from the top, your organisation is unlikely to feel secure enough to undertake such a change.
In the rest of this episode, I want to touch on some of those things that you need to think about to preparing fertile soil.
You will need to amend how you manage downwards.
When moving to a much faster, smaller, experimental cadence - it will be very unlikely that you will be able to lead it directly as you may have done with a traditional project.
In a traditional project, you may have been involved in the start to shape and approve it. But you will likely then have been hands off for a considerable portion of the time. You may occasionally get a status update - a red, amber, green indicator in a slide deck maybe. But your direct involvement is only likely to be needed if something goes really, really wrong.
This light touch, fairly limited pull on your availability will change drastically if you insist on being at the heart of any work in this new world.
This maybe fine if your primary responsibility is getting the software work completed - but not if you are trying to run an entire organisation.
You have to look at true delegation.
You have to pass the responsibility, and probably more importantly the accountability and authority, down into the team actually doing the work.
The team has to be self sufficient.
The second that the team needs to reach outside of its own boundary for approval or seek guidance, the effectiveness of that team (and thus ROI) is impacted. The team (and the supporting organisation) should continually strive to remove any need to cross that boundary. Breaching that boundary should be treated, and accepted, as a traumatic event and a sure sign something is not correct.
The role of the executive then becomes one of setting the organisation goals and empowering those team to address those goals as they deem best.
As part of this, the approval process will need to change.
If you current process requires any form of approval outside of the team, then it will not be performing at its optimum.
You may have a centralised authority for change, such as Change Advisory Board (CAB) or the executive insist on signing off on every change.
This comes back to empowering the team to get their work done.
I'm aware that this may seem at odds with running a sustainable business.
There will generally be a good reason that an "approval" process was put in place in the first place - maybe for some compliance or audit reason. Thus you may struggle to agree with it as being problem.
Fundamentally though these processes will likely to have been put into place to reduce risk. In most cases however I find that these processes are not actually the best way to address that risk.
For example, if the process is in place to provide an audit trail of changes - then automation of the systems through DevOps will give a much greater audit trail that any form of manual process.
Any manual process will have its exceptions. Some emergency which just requires someone to fix something - it may get down "off the books". It happens all the time, regardless of how disciplined a team is.
If however that fix has to go through the automated processes, then there will be a clear audit trail.
The DevOps automation can also handle things like segregation of duties and greatly reduce the need for any member of staff to every directly access production systems.
It comes down to thinking about the reason the process would have been put into place in the first place. Look for the fundamental risk it is trying to alleviate. In some case the risk will simply not exist any more.
Its important to remember that Lean, Agile & DevOps are in use in heavily regulated industries - banking, pharmaceuticals, government - this is definitely doable.
You will need to encourage teams to fail.
Yes, you've heard me right, to fail.
We have a natural avoidance of failure. We treat it with incredible levels of negativity.
Failing however is a key way to learn.
This goes back to the experimental mind-set around Minimum Viable Product.
We don't know if our experiment will work.
We have a hypothesis. We may even have great evidence to support that hypothesis.
But until we do it, we don't really know.
And if our hypothesis proves to be wrong, then great, we take that feedback and adjust our next steps.
So much of modern business is about placing a large number of small bets to see which ones pay off.
The majority won't - that's to be expected.
A minority will - and in some cases they will be in unexpected ways.
So, again failure should be encourage.
It should be baked into a Learning culture. Failure & success are both valuable to in that learning. They key is learning from both.
There is a concept know as psychological safety which applies here.
Wikipedia describes it as:
"Psychological safety is a shared belief that the team is safe for interpersonal risk taking. It can be defined as "being able to show and employ one's self without fear of negative consequences of self-image, status or career"
Again from Wikipedia; it states that the most widely empirically supported affects of a team being psychologically safe are:
"1 - Improves likelihood that an attempted process innovation will be successful
2 - Increases amount members learn from mistakes
3 - Boosts employee engagement
4 - Improves team innovation"
I'm going to blunt here
If you have a tradition of being perceived as a blame based culture, then you have work to do to establish that safety.
You will need to support the organisation as they travel this journey.
In the early days you will certainly find concern and worries being raised - any organisation not used to change will get push back from its people if it tries to transform itself overnight.
Each individual can react in a random way to those changes, and it is on the organisation to understand that and provide the relevant support and time.
So while I definitely advocate for a top-down approach - it definitely should not be an overnight edict.
Each organisation will be different, but expect it to take time to embed itself.
In some organisations, this can take years.
With anything like this start small ... You know what, MVP it.
Find something with which to run a Minimum Viable Product style experiment with it.
Take a specific product or team - or even create one. Use that as a starting point to minimise organisational impact.
Learn from the success (and the failures).
Find the wins. And build on it.
Use the same process and principals that I advocate for performing software development to roll it out - allow it snowball.
In this episode, I've provided a recap on the last 5 episodes - in which I introduced;
- Minimum Viable Product
- Lean
- Agile
- The Cloud
- And DevOps
I've then talked about how the organisation culture and management structure will need to change to accommodate this.
Along with provided some examples of keys areas of focus, and some advice on how to get started.