Agile and Lean are just toolkits, right?

Agile, Lean, Kanban, Scrum, SAFe, … plenty of tools to choose from, so why does ‘toolkit’ set my teeth on edge? Perhaps it puts me in mind of the journeyman worker who knows his tools but never really excels at anything.

To be more than a mere journeyman and to progress towards mastery, you need to know more than just the distinguishing features of each tool or body of knowledge. If I were looking for expert advice or inspiration I’d want to see:

Some respect for how these different schools came into being, the conditions prevailing at the time, the problems being solved
An understanding of the values and principles that explain their design choices and implementation strategies (and I don’t mean just being able to parrot them; values in isolation of practice are meaningless)
An ability to describe their ‘lessons’ – key takeaways that you can apply non-prescriptively, perhaps using alternative tools

Some examples of these lessons:

From Agile: the power of working collaboratively in carefully controlled chunks goes way beyond what you’d learn from studying psychology or queuing theory separately. It’s not magic (it’s easy enough to explain technically and it’s not hard to bring about) and there’s a positive reinforcement feedback loop there, one in which success breeds greater success.
From Lean Startup and Kanban (bedfellows almost from their respective beginnings): make the processes by which you learn about your customers, your product, and yourselves as visible as you can make them. You make rapid progress by continually testing your assumptions about all three.
From Scrum: don’t underestimate the value of rhythm. It’s not just the ritual and the predictability, it’s also the opportunities to achieve something meaningful in between (see lessons 1 and 2)

I’d love to see more of these. Can you describe a ‘lesson’ non-prescriptively?

Related:

6 thoughts on “Agile and Lean are just toolkits, right?”

Ha great insight Mike – I just wish as an industry we talked more about these ‘solutions’ in the way you describe in the post…….. a cliche now but comes back to ‘being agile’ rather than ‘doing’ as someone once famously said. As a coach I’m spending more and more time helping people unlearn a toolkit and learn the lessons as you put it

LikeLike

Reminds me of an exercise I ran at Agile2010 running a 5-whys on various agile practices:
https://availagility.co.uk/2010/10/04/a-root-cause-analysis-of-agile-practices/

LikeLike

From scaling frameworks (Scrum at Scale, SAFe, LeSS, Viable System Model): The ease and effectiveness of small teams with end-to-end responsibility depends on your capability to modularize the product.

LikeLike

Regarding “respect for how these different schools came into being” do you have any thoughts on how to do this? Besides being there at the creation or talking 1-1 with the creators what else is there? There is very little documentation… 🙂

LikeLike