🦖

Codosaurus 🦖

Appropriateness is always the most important aspect about a piece of software.  If we don’t have this, then nothing else matters.

So what does it mean, in ACRUMEN terms, for a piece of software to be “Appropriate”?

The short explanation is that it’s doing what the stakeholders need, or to put it even more briefly, it’s doing the right job.  (Contrast this with Correctness, which is about doing the job right.)

But what do I mean by stakeholders?  Most people might think something like:

• the users,
• the customers (if that’s not the same people),
• the “product owner” and maybe the “Scrum Master” (or equivalents under other processes),
• the development team’s manager and so on up the “chain of command”,
• and maybe another category or two.

But that’s not all.  I like the Project Management Institute’s definition, which is basically everybody involved in or otherwise affected by the project, including by its results, which in this case would be the software.  (Let’s leave aside for now their definition of “project”.)

To use the example of a Facebook game, that would include, in addition to the above:

• The developers, designers, testers, etc. themselves!
• The people responsible for deploying and otherwise operating the game.
• Facebook.
• If it’s anything like most Facebook apps, the people gathering, analyzing, and acting on the assorted data that the “game” is merrily slurping up about the players.
• And many more.

So how do we figure out what’s “the right job”?

• Ideally we’d have direct frequent face-to-face contact with each category of stakeholders, so we can ask them about it.  But in reality, that rarely happens.

• In huge companies, especially government contracting firms, we may get “requirements analysts”.  They’re helpful, but it means that the information is second-hand, and often restricted to a particular format such as a “requirements traceability matrix”.

• Usually, at best, we manage to get occasional indirect contact with a representative of, or stand-in for, some of the major stakeholders, such as a “product owner” in Scrum.  But even that isn’t terribly common.

• All too often, the PHB drops by with some vague mumblings about it needing to do something or other, and scuttles off before you can ask questions.

But all is not lost!  In addition to emails they won’t answer, or dry documents that they’ll skim and misunderstand, we can show them demos of what we have done, and prototypes of what we intend to do next.  Even easier than prototypes, though, we can propose concise tests.  In particular, I recommend the Given-When-Then format:

• Given some preconditions, such as data being in a particular state,
• When this happens, such as input from a user or another program,
• Then this is the result, such as something the user sees or data being in a new state.

This makes a great link between the business and technology sides, because the business people can understand it (assuming we write it reasonably clearly, in their language), and we can turn it into a runnable test.  For instance, when adding a search feature to a widget collection management system:

• Given I have three red widgets and two blue widgets;
• When I search for my widgets, specifying the color as red;
• Then I see all my red widgets and none of my blue ones.

We can show them these demos, prototypes, and tests, as often as practical, as a sort of continuous course-correction so we don’t go too far down the wrong rabbit-hole.