July 4, 2012
Agile, Coaching, Organisational effectiveness, Rightshifting, Software development
4 Comments

ScrumMaster or TaskMaster?

ScrumMaster or TaskMaster?

Linguistic Relativity

Maybe better-known until recently as the Sapir-Whorf hypothesis, the principle of linguistic relativity states that:

“the structure of a language affects the ways in which its speakers conceptualize their world, i.e. their world view, or otherwise influence their cognitive processes.”

Whether we realise it or not, software development has a language all its own, and Agile software development a variant of that again. Linguistic relativity suggests that the structural terms we choose to use affects the way we conceptualise our world.

One of the most pernicious and unexamined of these is the term “task”. The connotations implicit in this term include :

  • Activity
  • Work
  • Atomicity
  • Completion
  • Dependency

These connotations have unfortunate implications for developers and development teams everywhere. Put simply, by using the “task” as the atomic unit of work management and control, people automatically and pervasively assume that they have to do some work – e.g. spend some time and effort – to see the task completed.

Artefacts

In our work, we have long (since 1995) eschewed the “task” as the atomic unit of work, preferring instead to use the term “artefact”. Doing so has afforded us the following advantages:

  • Focus on outputs, rather than inputs
  • Focus on completion (90% of an artefact is no artefact at all)
  • Avoidance of unnecessary drudgery (work for the sake of working, busywork)
  • Closer fit with quantification of “quality attributes” (cf Gilb)
Put another way, by referring to e.g. a User Story or Use Case (and their component elements) as artefacts, we constantly remind ourselves that it’s the output that we want, not the work (activity) to produce it. In this way we encourage and remind ourselves to find means other than working to come up with the necessary artefact. For example, if the artefact in question is a source file for a particular class, we might think about producing it by searching for something suitable that exists already, or generating one somehow, rather than working on writing it from scratch. With a task-orientation, in contrast, we may overlook possibilities for creating the artefact by means other than writing (coding) it.
And we all know what it means to be a Task Master, don’t we?

Examine Your Language

How much longer are you going to allow the terms you use in your daily work to dictate the way you do that work – unexamined and unchallenged? What other terms in regular use are constraining your effectiveness and causing you unforeseen consequences?
– Bob

Further Reading

Competitive Engineering ~ Tom Gilb

4 comments

  1. The obvious one would be “resource”. “we need more QA resource”, “The middleware resource committed a bug”, “have we got enough resource for this task?” Companies have entire departments which perpetuate the idea of humans as ‘resources’. Your description of linguistic relativity explains the problem very nicely…..it’s more than just political correctness.

    Reply ↓

  2. I was thinking of the same. Referring to people as “resources” narrows down perception of their actual skills, people become numbers in spreadsheets, can be “allocated” to different projects/tasks and so on…

    Reply ↓
  3.  

    Pingback: Five Blogs – 5 July 2012 « 5blogs

  4. David said:

    Interesting – relativity clearly does rule, since I perceive the terms “artefact” and “task” entirely the opposite way around to your description! Some of the software processes I have encountered are full of defined mandatory “artefacts”, which don’t usually include “working software” and are often bureaucratic and tangential to actually delivering value. Whereas “task”, to me, means “achieve the stated outcome” or “deal with the stated problem”.

    Reply ↓

Leave a comment