This article expands on Tools in a Concrete Reflective Tool. We can start learning tools, but there must be a path to the principles that underly them.
(This is part of the Introduction to CRT article, this expands on the nature and value of tools.)
Tools get a bad rap, but frankly some of them deserve it. The Agile Manifesto put them in their place:
Individuals and interactions over processes and tools
We need tools though. Really! Tools allow us to spend our time on better things. An electric starter for a car, a spreadsheet, and an IPhone are all tools I’d rather have. We need tools that augment our individuals and interactions. Shu Ha Ri and the Dreyfus Model both describe progressions from practices to mastery.
There is this debate: to teach the ideas(principles) first, or teach the practices(tools) first. I’ve decided that I like to start with the practices, but the ideas must be made available for people to pull in when ready. Some people, those abstract/intuitive ones, will jump to the ideas right away, that’s fine.
Tools must be backed by principles. Kanban is a tool that is backed by Lean’s principals of Flow and Pull. Given the principles behind a tool an individual can learn how to better use the tool, when to use the tool, and even when not to!
Our use of tools that don’t have principles to back them up, or our ignorance of the principles that do exist, prevent us from learning and applying judgement to the use of a tool. Or worse, we make errors of correlation and mandate certain uses of a tool causing serious harm because we’re ignorant of the changing context.
An example of a tool applied without principles is a bug tracking system. What’s a bug or a feature? Should categories be horizontal or vertical? How granular should the bugs be? How many is too many? How often to cull the list?
Most teams never get past arbitrary guessing at these questions. The answers get hard written into process or simply ignored.