Taking Vocabulary to Task

Yesterday I asked via Twitter:

“What might one call a Kanban or Scrum board if one is doing neither Kanban nor Scrum?”

Context is always a challenge in 140 chars, so to expand just a little: I was asking from the point of view of folks (like myself) who prefer to walk their own path apropos methods and practices, either evolving something from scratch or so adapting a Scrum or Kanban approach to point where the label no longer really applies.

My thanks to all the folks that responded with their answers:

• “Task board”
• “Information Radiator”
• “Activity Board”
• “Kanban board (generic)”
• “Task/activity board”
• “Process or progress board”
• “Visual planning board”
• “Value visualiser”
• “Story board”
• “A board”

I guess by their answers, my question lacked sufficient context for some folks:

• “A lie”
• “An impediment”
• “Pretty wall art”
• “Messy”
• “A Gantt chart”

Linguistic Relativity

I’ve mentioned the concept of Linguistic Relativity some number of times in previous posts.

For many years I have avoided using the term “task” (or its surrogate, “activity”) for one major reason: The way it sets folks up for being busy (active, working) rather than smart.

Let me explain.

What are we, fundamentally, doing in software development? Some options present themselves as answers:

• Delivering software (code and other artefacts)
• Delivering value (in the form of executable and other related artefacts)
• Delivering things (artefacts, services, etc). that meet the needs of our stakeholders
• Learning (acquiring the know-how to repeatably deliver something)
• Building capability (generally in parallel with the above)

in contrast, the idea of a task or activity implies DOING something (i.e. a focus on the activity, rather than on the output). Ideally, we’d like to be able to deliver everything wanted or needed by all the stakeholders, to the “planned” quality levels (cf Gilb, “Competitive Engineering“) with ZERO work (activity).

“Here’s the deal. The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. Right? The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write – right? So, the goal here is to eliminate 80% of the code that you have to write for your app.”

~ Steve Jobs

Aside: Jobs was talking about lines of code, but I posit the argument holds just as well for all the other artefacts involved in software development.

I have found, in practice, that using the term “artefact” or similar reminds folks – often on a subliminal level – that they can get creative and avoid doing much if any work, if they’re smart enough to seek and find ways to achieve the desired ends with little or no activity.

This is why, for many years, I have preferred the “unit of flow” or “unit of control” in software (and product) development to be the Artefact (many of which are interim and not “deliverable”; some fewer, deliverable). Most other folks seem to opt for the default: “Task”.

An Answer of a Sort

So, back to the original question. Absent the explanation laid out here, maybe “task board” would be the most natural choice. Perhaps you can now see why I passed on that.

And “Artefact board” seems weird and contrived, albeit more congruent. Maybe it could grow on me, given time. And it does point to the possibility of using cards for artefacts (or groups of artefacts), rather than e.g. use cases or stories/epics. I kind of like that idea.

But, for the moment, I guess I’d have to go with “control board”, or just maybe “flow board”.

My thanks again to all those who responded.

– Bob