Agile and Lean, what’s the difference?

A schoolteacher friend asked recently whether I knew anything about Agile, and whether any of those agile or lean methods would work for helping to organise projects and people in an education environment.

I knew what my friend meant, but the lack of clarity about the difference between lean and agile made me go into full on explanation mode, and thus I wanted to write something about it. What I wrote was essentially this, and I was recommended to share it more widely.

Agile/Scrum/Kanban aren’t really the same thing at all, but they present with similar tools and visible markings, so they often get confused.

Agile is just a general handwaveyness for a collection of mostly software development methodologies that all focus on not doing project planning up front, what we now call waterfall style, or for modern practitioners the V-model of development. Agile methods all share a few common principles, essentially boiling down to saying that you wont know whether the software you are building is any good until someone sees it, tries it and gives you feedback. This means they focus on iteration, on delivering early versions of software and getting feedback and enabling teams to communicate etc.

Scrum is one agile methodology, it happens to be the most well known, but there are others. Scrum is primarily focused towards delivering a project, normally software, but it’s been reused for many other project types. The specific features you are looking for are:
* You can identify when you are done (or you will be done at some point and stop working)
* You have a team of people who need to collaborate on the project
* You can break down the intended deliverables into steps or small units of functionality.

This means that scrum works really well when your project has these attributes.

So a plan to divide up modules between teachers and teach them in concert might work well. You can subdivide the tasks as each module or unit, you can assign an owner to each tasks, and you’ll know when it’s done.

Kanban, or as I prefer to call it, Lean, comes from manufacturing originally. The Toyota Production System is the forbearer of Lean, and in fact migrating to lean manufacturing is still a thing that you see happening in factories today in the UK (well a decade ago, I’ve not worked in a factory in a while!).

Lean works on what should be a pull based system. Most manufacturing lines are viewed as pushed based. You grab a bunch of raw materials at one end, push them through a series of steps and get finished products at the other end.
The smart thing lean does is to invert that thinking and essentially say that a factory should only be producing as much as is ordered by customers. Anything more becomes surplus which costs money to store and tends to either decay or depreciate in value.
Each station on the manufacturing line wants to pull from the previous station the amount needed to do their job, and the pull should go back through the system to the raw ingredients.

Lean teams use a Kanban board to signal what they have on their radar and what they are working on, and this helps teams looking at the next board down, and so forth.

Lean/Kanban is therefore really good for problems that:
* Are continuous, where the process might be improved, but not changed, and you may never be “done”
* Where storing work in progress, or even worse, work stored between stages of a process is expensive or wasteful in some form
* Where you can easily measure and improve where changes in the process might be

Lean in particular focuses on a couple of main principles:
* Cycle time, that is time from beginning to end is bad
* Work in progress should be limited to ensure that you are pushing work up to the next stage faster than they can consume it
* Storing work in between processing stages is wasteful or difficult

I’d use lean for processes such as marking and validation processes, or any multi stage process. Each person or team is reliant on information from one or many other teams, and collates and coordinates the work to push on further.

The really interesting learning from Lean is that local optimisation can be totally useless. So if you’ve got a 5 stage process, and one stage can only process 10 items a day, then work to make another stage be able to process 25 items a day is entirely pointless unless you can also speed up the slow stage. That helps you focus where to make improvements. The Kanban term for this is Kaizen, which is to make small incremental improvements to the slowest, weakest, lowest quality (pick your metric) part of the chain, and then repeat next week/iteration.

In terms of how I’d organise admin work for teachers, it entirely depends on whether people are collaborating and how much they depend on one another. I know very little about how schoolwork is done, but my guess is that homework, course marking, and other things tend not to be collaborative. Other things I figure are one-off projects, so organising trips or new big projects, that kind of thing.

I suspect that for fixed scope projects, with multiple people collaborating, I’d probably go down the Scrum style route. Get people together, understand the scope of what you want to deliver and keep track of it using a big visible board, with post-its or index cards and move tasks over to done as they get done. You won’t be using true “scrum” but you will get some of the benefits of agile, such as visible feedback, estimating burn down (that’s time left to complete with estimates on when you’ll finish) and stuff like that.

It you are doing the same thing, but as a big process, such as passing papers or reports around a number of people, getting input or a change from each, and you do the same each term or year, then Lean/Kanban might fit you better.

Finally of course, if what you are doing is a project, where how you do it is well understood, and the output is known, then agile techniques are unlikely to help you at all, and you should instead use a traditional project management set of techniques instead.