The team I work on has been performing coding katas for some time to improve our coding chops. It is a great way of practising test-first programming, it can test your program design skills and it helps you to gain familiarity with your tools.
So when my team re-designed our working methods, we thought we’d test out the ideas with a process kata.
We have been running Scrum by the book on existing applications for quite some time. The process has worked its magic, helping a company to transition from an unnamed process to an Agile way of working and there are clear improvements in terms of communication, application stability team effectiveness. The whole team is functioning well using Agile and Scrum.
Given a new and challenging stream of work, though, we recognised that we wanted to raise the bar on our way of writing software and there was a clear opportunity to pivot the process in a more dramatic way than our regular tuning had offered.
So we created a process based on impact mapping, specification by example, limited work-in-progress, executable specifications, test-first programming, continuous integration / delivery and a whole host of other ideas from Agile and Lean thought leaders (acknowledgements later).
It would have be somewhat rash to start “day one” of the new method on real work without having validated the ideas, so a process kata seemed to be the sensible way to test our theories before undertaking actual work in this way.
A process kata is very similar to a coding kata; in fact, we used the bowling score card kata to do it. The idea was to get the following benefits:
- Try out our entire process end to end in a safe environment
- Discover any tooling problems before starting real work
- Gain familiarity with the tools
- Iterate the process very quickly and adjust it, before starting longer iterations
We spent half a day testing out the process and kept a list of elements we wanted to fine-tune. Most of the tuning was tool-related, where the tools were getting in the way or not producing the results we wanted. Of course, the value was much greater than the list of things to improve – we got all of the benefits of practice in an environment where total failure would have been perfectly acceptable.
Interested? Read the Process Kata Questions and Answers article.
The process we designed is a subject for another time, but it is thanks to the following thought-leaders whose books, blogs, videos and Tweets have changed the way I think about software development, people and programming:
- Gojko Adzic (Impact Mapping, Bridging the Communication Gap)
- Woody Zuill (#NoEstimates)
- Neil Killick (#NoEstimates)
- Uncle Bob (Clean Code, Clean Coder, Agile PPP)
- Tonianne DeMaria Barry and Jim Benson (Personal Kanban)
- Jim Benson (Personal Kanban, Beyond Agile, Why Plans Fail)
- Joanne Ho (Beyond Agile)
- Maritza van den Heuvel (Beyond Agile)
- Eric Ries (The Lean Startup)
- Geoff Watts (Scrum Mastery)
- Gerald Weinberg (The Psychology of Computer Programming)
- Kent Beck (Extreme Programming Explained)
- Jerome Bruner (Towards a Theory of Instruction)
- Johanna Rothman (Behind Closed Doors)
- Esther Derby (Agile Retrospectives, Behind Closed Doors)