Deliberate Learning & the need for Code KATA

As a software craftsperson, I believe in deliberate learning. I don't just mean the usual collection of continual professional development and "Training" offered by external companies who promise to dramatically transform your team - usually this is fluff that is not really going to get your team to learn anything. One of the problems I have with these off-site courses, and online training systems is that you get a fancy shiny folder, you make some notes in it, you learn something new on that day - perhaps - but within a week of returning to the normal day job the folder is put on the shelf, the piece of new knowledge is forgotten and the notes placed in the drawer of the desk - slowly decomposing under a steady diet of pens, staplers, fragments of old lunches and more pieces of paper on which once very important things were written. I call this type of learning as WORN - Written once, Read never.

As I see it, with these things, is that it enables the company collectively to think and feel that they have ticked the box, done some training and "Aha, I must have improved the engineering culture!". The reality is that it usually costs the company a bunch of time and lot of money and there is no measurable improvement in the quality of the code produced, the morale or the practices in the team.

Enshrining deliberate learning as a practice in engineering teams is traditionally actually very hard to achieve because almost everybody else fights against it or fails to see the value of this practice. I recall a CPO saying "We haven't got time for this we need to deliver more stories this week!", the CEO saying "Why did we hire people who don't know how to do this already?". A founder saying "Why aren't we going faster than this?" This thought process is the origin of so many failed projects and awful job adverts saying things like "must have 3 years of Scala, or must have 2 years of c#" as if this is the only requirement and ignoring the abilities of the person to move the needle in your business.

To get the team you want you need to not only hire the right people with the right skills, but you must also enforce a focus on deliberate learning and continuous improvement. There are many ways of doing this but its important that this is done inside the team, inside the business and that it is practiced every day till it becomes a mental muscle memory. It must be practiced in the team that will be doing this every day. A traditional training and learning on the job.

I have observed that a really good CTO brings this deliberate learning in house as part of the every day work week and really measures and cares about the nature and benefits of this approach. Demonstrating to the board over time the difference that this approach makes to the business. Fewer defects, faster story delivery, happier customers, longer staff retention, lower recruitment costs, less waste, cleaner code.

I have hired people with 0 experience straight out of university because they clearly espoused to me values that are part of the software craftsmanship ethos -although they themselves had never heard of software craftsmanship before. They did very, very, very well and they made a considerable, measurable improvement in the velocity of the team. They lifted other members of the team because of their enthusiasm, expression of values and dedication to improving themselves. They had the "deliberate learning" value. They were a joy to work with.

In short having a focus on deliberate learning inside your team, as part of your lean, kanban, sprint or XP practices accelerates the performance of the individual and of the overall team. This effect is measurable and will move the needle on your business.

Software development - like most things - is a skill, its a skill which only gets better after practice, lots and lots of practice. In your business if you are restricting your engineering team from practicing and getting better you are shooting yourself in the foot. If you really want to improve how your engineering function works start by setting up your culture to have deliberate (in-house) learning. This is going to give your developers better skills, when they are better skilled they will go faster. When they go faster your business has more velocity.

There are a variety of ways of doing this, but my favorite I like to employ is the application of code kata. That is giving a specific problem to a developer which already has a known solution and has been solved many times by many others. Ask them to solve it using their favorite language first so that they are comfortable. Then ask them to solve it in at least 2 other languages that they have never used before. Through this practice of solving a known problem again and again in different languages practices the mental muscles and forces the learning and application of design patterns - learning the nuances of one language over another. Helping them understand the limits of their favorite tooling and that there is more than one way to skin a cat. In short this practice makes programmers better - because they are practicing.

Greatness comes from practicing; applying the theory over and over again, using feedback to get better every time.

If you decide to make this investment in your team, and I hope you do. I would suggest 4 hours per week per person on your team where they practice a Kata.

Measure the number of bugs, defects and flaws before, measure the story velocity before. Then set to installing this as a way of working, an engineering practice.

Over a period of 6 months you will see a marked improvement in performance, an increase in the velocity of stories, a reduction in the number of defects, an improvement of morale in the team, an increase in enthusiasm in the team.

Although, regrettably I have not been able to introduce this to every environment I have ever created, I have experienced this first hand and I can attest to the difference it makes to the team and the business.

If you want a better business.

Develop your developers to be craftspeople

Craftspeople create better code, faster

Better code = Better business.

Regards Julian