The Agile Projector

Imagine a software project as a pile of shared to-do lists. When the list is
created, each stakeholder dutifully fills out what they imagine their personal
to-dos on that list should be. The to-dos start and stop and start again. Some
complete. Some get paused for a while. To-dos are added and removed and
assigned by various individuals over time.

Every to-do owner, if they are the responsible type, also has their own list
which represents all their to-dos scattered across all the other lists. They
need to keep this list up to date with the priorities and status of each to-do,
including whether any given to-do is blocked by an external to-do or must be
done before any other to-do in their own list. As to-dos are added and
removed and completed and unblocked in the other lists, their reflections in
the personal list must get updated as well.

Shared Lists

To the individual, their reality is their own list, and the reflection is in the
shared lists:

Figure 1-1. Shared to-dos from the personal perspective

To the project, the reality is the shared lists, and the reflection is scattered
across all the individual lists. If the shared lists are not complete, the project
is not complete. While this is the  reality from the perspective of the project:

Figure 1-2. Shared to-dos from the project perspective

If you were the blocker, and you just finished your work, you would need to
know what you were blocking, who owns it, how to contact them, and that
you need to tell them you are done. If you were blocked, you would need to
have a way to be contacted, a way to know what to-do has gotten unblocked,
and where it should go on your personal pile of to-dos. You would also need
to tell the blocker that you received their message. If any message is not
acknowledged in either direction, the sender needs to know, track, and
remember to retry.

The message content itself needs to be unambiguous, as any ambiguity means
another round trip, or a shortcut – an assumption about what is meant by the
message – which may or may not be correct, and which likely will not get
communicated back to the sender.

Needless to say, this shared to-do list system is complicated and error prone.
It is very easy and indeed likely for the personal lists to get out of sync with
the shared lists.

Ownership

The common thread connecting each of these updates is about ownership. In
each case, someone either

• believed that they had handed something to another person,
• didn’t realize they were supposed to hand something to another person,
• didn’t realize they had received something,
• or made an assumption about what they were handed

In all cases, work stopped, or the wrong work was done. And lots of time was spent 
in meetings trying to get it untangled.

The shared to-do list is a classic example of the problem of shared ownership.

Because no one owns the shared list, synchronization errors have no
systematic way of being corrected. If there were an owner of the shared list,
that owner would be clearly responsible for tracking the state of each to-do
and ensuring that they were reflected correctly in the individual lists. The
owner would also be responsible for ensuring the integrity of each to-do in
the context of the purpose of the list – that is, does each to-do make sense to
be on the list, and is each to-do clearly fulfilling the reason the list exists?