Today I attended a full day training session on ‘Scrum’ - part of the Agile development methodology. The training was organised by our development team, and we in PIU were keen to attend to understand where similarities in approach between Lean and Agile could be useful, and where differences that could trip us up might lie.
The training was engaging and interesting, and our trainer Tom Sedge had extensive knowledge of the subject. He explained that there were considerable similarities between Lean and Agile, and he was not wrong.
I want to focus here, not on what Lean and Scrum are, but on the similarities between the approaches.
First up - the common nature of the problems Lean and Agile are designed to solve. Training attendees (most of them working in development in one way or another) produced a list remarkably similar to the one we see in our process improvement projects.
The ‘Agile mindset’ maps more or less directly on to concepts in lean to do with the ‘servant-leader’, respect for people’s skills knowledge and experience, and making decisions about the work as near as possible to the place and people where the work happens, and seeking continuous improvement in small increments,
In terms of structure and process, similarities exist between the ‘Daily Scrum’ where progress is checked and problems highlighted, and the daily improvement meeting in lean - designed for the same purpose and running (usually) for no more than 15 minutes. The ‘Scrum Master’ for the scrum meeting, and for the general running of the ‘sprints’ which is where the productive work happens, is seen not as a manager, but as a ‘servant’ to the development team. Lean specifically recognises that managers are ‘unproductive’ and their role is to support those who are ‘doing the real work’.
For our projects, the Project co-ordinator fulfills a similar role, and is chosen not for their management position, but for their facilitative and organisational skills.
Each ‘sprint’, running for two to four weeks, corresponds to the lean notion of implementing change in small, achievable, chunks.
The visual nature of the control mechanisms in place in the scrum method - The Kanban board - has a direct parallel in the lean world, and indeed the name comes from a lean term. We’re really keen on visual management in PIU, and I was delighted to see a representative from a software training consultancy arguing strongly for a simple solution based on a whiteboard rather than complicated software! Importantly the concept of ‘pulling the work’ is being used, rather than the traditional management push on to potentially overloaded workers.
I also noted that only two ‘sprints’ (or work packages) are ideally ready to be worked on at one time. This means that the work necessary in specifying the real work is kept to a minimum, done only when necessary, and replenished when necessary, again using the pull principle. This has two benefits:
- It saves effort on development of work which may not be done in the near future (or ever if circumstances change)
- It allows for greater understanding of the necessary work before it is attempted
Again, this is the Lean ‘Just in Time’ principle at work.
There was a lot more to the training - the concept of sprint burndown seemed to me to be similar to the concept of takt time for example, and the notion of quick decision-making in an uncertain and imperfect environment.
We were asked at the end of the day what we will implement as a result of the training - a really useful training technique to encourage people to think actively - and I came away thinking that we should consider whether to tighten up our implementation plans so that they resemble more the ‘sprints’ of scrum. It seems to me that this would have benefits in concentrating teams’ minds, and in producing work packages that provided real benefits in a short time.
I also really like the ‘planning poker’ cards - not really planning or poker but used to quickly estimate the time to do a piece of work. I’m sure we could make use of these and there’s evidently a ready supply in the department already.
I have some research to do as well. The ‘Stacey Matrix’ is a useful prioritisation tool, and I need to find out more about the Agile Manifesto.