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

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.

This article expands on Reflective in a Concrete Reflective Tool. Tools that help us learn from their use give us tremendous opportunity for growth.

(This is part of the Introduction to CRT article, this expands on the nature and value of Reflective tools.)

Reflective

The definition of reflective I use is:

“Of, relating to, produced by, or resulting from reflection.”

Think of driving a car down the highway without being able to reflect on the current road and traffic conditions; that feedback is crucial to being able to successfully navigate. There are many names for this: Inspect and Adapt, Plan-Do-Check-Act, Feedback Cycles, Closed-Loop Control Systems.

In “Managing to Learn: Using the A3 Management Process”, by John Shook, there are two references to wanting the people in your organization to be “reflective problems solvers”. This strikes me as such an important concept that I wanted to mention here that this book prepared me to see “concrete reflective tools” at all during the Kanban conference.

Of course we want reflective, it’s obvious, right? Just having “reflective” alone though can be useless. I think there is a world of difference between an abstract reflective and concrete reflective system. The former requires the expert, the intuitive guide, that can draw conclusions “from the air”. The latter can bring everyone into the fold. Should the WIP limit be 4, or 5? We can reflect on the backlog that occurred last time we expanded the WIP limit and everyone on the team can participate in that conversation. No “black belt” needed.

This article expands on the Concrete in a Concrete Reflective Tool. Applying concrete tools is a good way to avoid alienating over half of your audience.

(This is part of the Introduction to CRT article, this expands on the nature and value of Concrete tools.)

Concrete

The definition of concrete I use is:

representing or applied to an actual substance or thing, as opposed to an abstract quality

The idea is to focus on actual things, empirical examples, quantitative measures and visual or tactile things.

Kanban is a Lean (Toyota Production System) tool being applied to software development. At the Lean Kanban conference in Miami last year I heard three separate people leading Kanban teams say “people who never contributed before started sharing ideas up at the board”. This is huge. Getting people engaged _is_ the big win with any process change.

Kanban has a visual board, like most Agile teams, but includes many more concrete “levers” that Agile visual boards don’t have. How many columns? 4, 5, or 12? How may classes of services? 1, 2, 4? How many Features should be concurrently waiting for Acceptance? 2, 4, 20?

These are extremely concrete questions and answers. Everyone can participate and articulate an opinion about 2, 4, or 20.

Why is concrete so important? Concrete processing is applicable to more of the population. From Myers-Briggs we think we can generally divide people into, among other things, those that are “Sensing” and those that are “iNtuitive”. Studies have shown the following ratio is applicable to the population at large:

S-vs-N: 73.2% is S, 26.8% is N

This means that presenting abstract ideas or conclusions will be less absorbed by most of the population. In the technology fields this ratio is apparently closer.

A related idea is visualization, an important way to make things concrete. See the Periodic Table of Visualization Methods for reference.