Kaizen (改善), Japanese for “improvement”, or “change for the better” refers to philosophy or practices that focus upon continuous improvement
Strangely I’ve never blogged about something I’ve implemented in virtually every Agile environment I’ve worked in recently, something I call Team Kaizen’s. Kaizen’s are often associated to Kanban, but there’s no reason why you cannot use Kaizen’s in Scrum, XP, DSDM, etc… (most already have some form of CI method method).
Often I use Team Kaizen’s to replace traditional retrospectives (Team Kaizen’s can be implemented irrelevant of which Agile methodology you use).
Why delay waiting until the end of a time boxed period to raise possible improvements? Why wait to discuss these improvements? Why delay working on making improvements?
Why not encourage people to raise improvements at any given moment in time, and if feasible (I’ll clarify later), discuss and act upon a raised Kaizen.
Team Kaizen’s
Next to the teams physical task board, I mark out an area for the team to put their Kaizen’s. When one of the team thinks of an improvement (related to the project or team), they write down a brief note and put it up on the wall. Depending on the team there is two ways to deal with Kaizen’s raised.
- 1) Daily update- Team review’s each new Kaizen after each team member has given their update. The team will then bin any Kaizen they collectively do not feel has any value add. For the remaining value add Kaizen’s, depending on your Agile methodology, you can;
- Scrum – Flag it for conversation at the next Sprint planning session. At Sprint planning the team selects 1 or 2 of the flagged Kaizen’s and includes them as deliverables within your Sprint. Like Stories, Epic Kaizen’s are not allowed, if it cannot be completed within your time boxed period (1-4 weeks) then it needs decomposing.
- Kanban – Associate a class of service and put into the backlog
- 2) Agreed cadence – Review the Kaizens at an agreed cadence (end of Sprint or at an agreed reflection point in Kanban). The team would discuss all of the Kaizens on the board and select 2 to work on over the period of the next month. Again, like Scrum epic’s, the only rule I would put in place would be that the Kaizen/s chosen can be delivered before the next review period, otherwise you could end up with a Super Tanker Kaizen and that is more than likely outside of the scope of the project or team.
Optional extras
You can tweak when you carryout your Kaizen review, so additional triggers could be used exclusively or in addition;
- Team Kaizen area is overflowing
- Team has no more backlog
Replacing the retrospective or retrospective-lite
You could do team Kaizens and continue your full fat retrospectives, but with a little Lean thinking you could either reduce the time of your retrospectives greatly or do away with them completely.
One of my previous teams had a 15min retrospective at the Kaizen wall every 4 weeks (Kaban team), they would carry out their Kaizen review, discuss and select two Kaizens to work on and briefly discuss AOB. Done.
This worked well for the team as they were driven by getting deliverables out of the door, though some teams I work with have a more ‘emotional’ angle to their retrospective (like group therapy), in which case they still may want to have 10-20mins to talk about how they feel, draw pictures, etc… its not personally something I like, as I’d rather focus on identifying area’s for improvement, generate an action list based on these areas and get out of the room (teams who moan about to many meetings or don’t value / get anything from retrospectives often like Team Kaizens as they are focussed, constant and mitigates the need for retrospectives)
* Warning – If the team does do away with retrospectives, the Scrum Master needs to communicate that any sensitive Kaizen’s or other issues that may normally get brought up in a retrospective should be emailed to him and an ad-hoc meeting arrange to discuss.
