Archive

Monthly Archives: February 2021

Artefact Driven Delivery

February 24, 2021
Antimatter principle, Engineering, Familiar, Organisational effectiveness, Product development, Software development
3 Comments

Artefact Driven Delivery

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

  • Control Document
  • Articles of Understanding
  • Glossary of Terms
  • Statement of Purpose
  • Case for Action
  • Vision
  • Folks That Matter™ and their Needs
  • Risk Parade
  • Top Risks
  • Functional Requirements
  • Non-functional Requirements aka QQOs
  • Critical Success Factors
  • Feature Schedule
  • Quality Plan
  • Test Plan
  • Change Control
  • Cycle Plans
  • Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).

Javelin

For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

Management Monstrosities

February 21, 2021
General, Management, Organisational effectiveness, Rightshifting, Software development
2 Comments

Management Monstrosities

Michele Sollecito (@sollecitom) kindly responded to a recent tweet of mine with the following question: 

“Why do so many well intentioned founders and companies end up creating management monstrosities?”

The “management monstrosities” referred-to are the (dysfunctional, ineffective) tech organisations we find just about everywhere these days. My work on #Rightshifting illustrates just how ineffective is the average tech company, compared with how effective they could be (and how effective Rightshifted outliers are known to be).

But Michele’s question is: “Why?”

Over twenty years and more, I’ve seen dozens of organisations up close and personal.  In none of these organisations have the folks in charge appreciated the difference between collaborative knowledge work (Cf. Drucker) and other categories of work. We can call this a Category Error.

Category Error

Collaborative knowledge work is NOT like:

  • Factory Work
  • Manufacturing
  • Office work
  • Service work (e.g. Call centres, Help desks, etc.)
  • Individual knowledge work

Collaborative knowledge work is in a distinct category all its own, and demands a fundamentally different approach to the way the work works, if we’re to see effective working.

Attempting to manage collaborative knowledge work by means common to other categories of work will inevitably lead to ineffectiveness, and all the monstrous consequences that follow from that.

Assumptions and Beliefs

Put another way, organisations import or retread the assumptions and beliefs of the category of work they believe applies to software development. As the category they assign is (almost) never “collaborative knowledge work”, the prevailing assumptions and beliefs are similarly almost never aligned to effective working.

You may now be asking “Why is the category they assign almost never ‘collaborative knowledge work’?”. I’ll leave that question for another post (if there’s any demand for such a post).

– Bob

Grendels

February 10, 2021
Book Review, Community, General, Reflections
1 Comment

Grendels

I have of late been reading (well, listening-to via Audible) many of the science fiction classics from yesteryear, by authors I missed out on in my youth (in those days mainly reading Van Vogt, Moorcock, Herbert, Harrison and Heinlein).

The most recent of these books is The Legacy of Heorot by Larry Niven et al.

The book has been described as “reworking the Beowulf legend in science fiction”. Niven amplifies Beowulf’s antagonist, Grendel, into a whole species of pseudo-reptilian super-monsters. Without revealing the whole plot, suffice to say that these creatures are portrayed as solitary, voracious, cannibalistic, and murderously territorial.

Whilst reading (listening), I’ve been struck by the parallels between these “Grendels” and prominent figures in the software community (individual consultants, opinioneers, etc.):

Solitary

I see many such figures (including but not limited to folks in the Agile space) ploughing their own furrows, ignoring others of a similar ilk, minimising productive interactions and community.

Voracious

Niven’s grendels are forever eating, and looking to eat. Eating is their core driver. The folks I have in mind seem likewise voracious in their hunt for revenues and clients (prey).

Cannibalistic

I see many such figures taking the ideas of others, retreading them, and selling them on as original and even proprietary. Analagous to intellectual cannibalism.

Fiercely Territorial

The grendels in the book each assiduously guard their own stretch of water (being basically amphibian), murderouly opposing any intrusion into their territory, with the utmost prejudice. I see parallels with (some, most?) of the aforementioned members of the software thought-leaders and opinion-makers “community”.

Upshot

In the book, the human colonists eventually triumph over the grendels, through a combination of technology, self-sacrifice and strategic thinking. “They’re just animals” the colonists remark, by way of explaining their victory.

I’ve long sought to reach out and connect with our grendels, in an attempt to further the collective knowledge and impact of the software community at large. To little or no avail. Maybe our grendels’ fate is predicted by the fate of the grendels in the book – irrelevance and extinction.

– Bob