In this episode I wanted to continue the conversation on Learning. In the last few episodes, I talked about; In this episode I want to looks at how the Software Development team can learn through a number of deliberate practices.
Or listen at:
Published: Wed, 08 Jul 2020 15:16:22 GMT
Transcript
In this episode I wanted to continue the conversation on Learning.
In the last few episodes, I talked about;
- Why learning is so important to me personally
- Organisational Learning
- And how to support and encourage individual learning.
In this episode I want to looks at how the Software Development team can learn through a number of deliberate practices.
Wikipedia describes deliberate practice as
"Practice is the act of rehearsing a behaviour over and over, or engaging in an activity again and again, for the purpose of improving or mastering it, as in the phrase 'practice makes perfect'."
When I think about Deliberate Practice in every day life, I think about group of individuals going through drills to practice working together.
For example, Fire Fighters the world over are using Deliberate Practice. They will drill repeatably as a team to refine their abilities and capabilities to work together in dangerous situations.
Even in our own business we will have the minimum of a fire drill. A deliberate practice to ensure that everyone would get out of a burning building safely.
So what is happening during those drills.
At the most basic level we are ensuring that the individuals know what to do in those events.
For a fire drill, we want to make sure that each individual knows how to exit the building in a safe way and can be accounted for. We practice to ensure that each individual understands their responsibilities and what is expected of them.
Thus in a real fire, we aren't putting peoples lives at risk entering a burning building to trying to find individuals that has decided that the fire drill is a good excuse to disappear to the pub.
And each time the drill in conducted we are looking for possible improvements.
Are there potential improvements that can be made towards the desired outcome - which in this case is the protection of life.
Within Software Development, the drills improve the teams ability to their job.
And in this episode, I want to introduce to specific practices;
Katas and Game Days
A Kata is a training practice from the martial arts.
Wikipedia describes a Kata as:
"Kata is a Japanese word meaning literally "form" referring to a detailed choreographed pattern of martial arts movements made to be practised alone, and also within groups and in unison when training. It is practised in Japanese martial arts as a way to memorize and perfect the movements being executed."
When, years ago, I practiced Karate - a kata was a means of teaching and learning successful combat techniques.
As a beginner you learnt basic form - how to attack and defend. You learnt by rote - almost like a dance.
As you progressed in mastery, you understood the inspiration being each move - each sequence. You could understand what sort of attack you maybe defending against.
And that was part of the Kata's heritage. It was a way of passing down retained knowledge to future generations.
And as a student it allowed you to first learn those basic steps. And over the years continue to practice it to greater insight and mastery.
And there would always be further insight and mastery to obtain.
Software Development uses the Code Kata as a means of Deliberate Practice in a similar manner.
Wikipedia describes as Code Kata as:
"A code kata is an exercise in programming which helps programmers hone their skills through practice and repetition."
While the actions in a code kata are not as defined in a martial arts kata; the aim is very much the same - to help beginners to learn basic form and then progress through to further insight and mastery over time.
A typical code kata will be time spent solving a relatively simple problem with a focus on a specific practice or method.
The aim is to solve the problem. Review how the problem was solved. And then solve the problem again. And repeat.
This may seem like a waste of time - why repeat the process?
Well, like the martial arts kata, is helps the learner build up muscle memory on the use of the specific practice or method.
It also allows them to refine their usage through review.
Maybe they have realised that they could have done something a little better last time.
In the same way that a martial arts learner will make minuscule adjustments to foot placement, body weight, strike speed and direction ... Hundreds of little improvements that improves their skills over time.
In the same way that the Respective process I introduced in Episode 45, the improvements are like compound interest; individual improvements on their own they may seem almost inconsequential.
Overtime however, the compound interest pays real dividends.
A code kata can be performed as an individual or as a team.
It is actually an incredibly powerful tool for team learning - especially for practices like pairing and mobbing that I introduced in episodes 23 & 24.
It is some much easier to learn if the a team focus on the act of learning the practice - rather than trying to learn the practice while also having to get the "real job" done.
Its very easy for the "real job" to become the focus and the opportunity to learn and improve is lost.
The code kata should be used to help the team improve there ability BEFORE they get to the "real job".
Its the same as the firefighters practicing to fight fires BEFORE they turn up the burning building.
The other practice I wanted to describe in this episode was Game Days.
Game Days are a practice similar to military war games.
A fictional scenario is created and the team go through how they would deal with it.
Think of it as rehearsing how the team would handle something going wrong.
Let taken an example;
Maybe you have an ecommerce website and you want to rehearse what would happen in the database went down in the middle of the night.
You gather then team and you either roleplay the scenario on a test system or on a whiteboard.
As a team you brainstorm the possible impacts - how each system will be affected.
You walk through all the steps to resolve.
How will you know there is a problem in the first place?
Who will be looking at it?
Will they have the tools or access to be able to do that from home at 3 in the morning?
What if they need to get hold of a senior decision maker?
The Game Day serves two purposes;
Firstly to help the team learn the basic steps - similar to using the coding kata to learn basic form.
And secondly to identify improvements that can be made - either to the systems to make them more resilient or to the process to make it robust.
Having a team with the muscle memory to resolve a problem can greatly reduce the further problems that can be produced from a panicking team during a high pressure situation.
What would you prefer at 3am in the morning with your e-commerce website down?
A disorganised collection of people trying to ring each other in the middle of the night - attempting to resolve a critical problem while suffering from tiredness and panic.
Or a relaxed "we've got this" approach because they've practice for it. They know who they need to contact and they know the actions they need to perform.
Again, wouldn't you like those firefighters to have some experience working together, having using the correct tools BEFORE they turn up to your burning building?
And of course the Game Day throws up those potential improvements.
Improvements to make the e-commerce platform more resilient, or the monitoring more timely, or simply the ability to access those systems from home at 3am in the morning more practical.
And again, Game Days are an activity that should be repeated.
You incrementally learn from each one. You improve the people, practices and systems over time.
Netflix actually take this approach to the extreme by introducing "Chaos Engineering";
Wikipedia describes Chaos Engineering as:
"Chaos engineering is the discipline of experimenting on a software system in production in order to build confidence in the system's capability to withstand turbulent and unexpected conditions."
So rather than the Game Day situation I describe - using a test system or a whiteboard, Netflix randomly inject failures into their systems.
And this can be anything as small as a single machine all the way up to a data centre.
And they will do this in production.
At any time.
This creates a culture that system failure is a normal, every day event - and as such resilience needs to be build into the people, practices and systems.
And this leads to an exceptionally stable and reliable platform for its users.
One concept I wanted to highlight was the idea of repetition in our learning.
It comes up over and over in Software Development.
Agile and DevOps both recommend small repetition in their approach to Software Development.
The Retrospective practice I introduced in episode 45 used the repetitive reflection to review and learn.
And both the practices of Code Katas and Game Days encourage repetition and learning from the prior activities.
And again, it is that similar try, review, learn cycle I've described so many times from the Minimal Viable Product mindset.
In this episode I talked about two forms of Software Development deliberate practice; Code Katas and Game Days.
I'm summarised the activities for each and also talked about how they are aimed at improving the capabilities of the team.
Its not about building the right thing, but rather building the thing right.
Its focusing on the team's ability to do the work, not the output of the work itself.
Its not about do the right thing, its about doing the thing right - and this will be the subject of the next episode.
I'm coming up to the 50th episode of "Better ROI from Software Development" podcast
I've been recording these episodes for just over a year now, and have over 8 hours of episodes.
Week in and week out I script, record, edit and produce these podcasts - and sometime it can feel like I talking to the wilderness.
So if you're a listener I'd love to hear back from you. Please reach out and let me know if you are listening.
I'd love to include any feedback or comments in the 50th episode.
Thank you for listening.
I look forward to speaking to you next week.