Notes on "Making Work Visible" by Dominica DeGrandis

"A bad system will beat a good person every time"

Denning, Edward

TLDR

Five features of a good workflow system:

1. makes work visibile
2. limits WIP
3. measures and manages the flow of work
4. prioritises effectively
5. adjusts based on learnings from feedback & metrics

Five Thieves of Time

1. Too much WIP
2. Unknown Dependencies
3. Unplanned Work
4. Conflicting Priorities
5. Neglected Work

Carry on for the ramblefest 🙂

I enjoyed reading it because it was reflective in tone, posited original and practical approaches to combatting familiar problems, and was very concisely written with regular, helpful “key takeaway” summaries interspersed throughout. DeGrandis is also very adept at using clear, colourful illustrations and graphics to express key ideas and compliment her writing. I’m going to highlight a few of the main ideas DeGrandis explores and share some of my thoughts.

DeGrandis adopts a really humble and reflective tone when she corrects some of her own points (about not second guessing work once it has started) from the first edition and challenges some of her assertions even in this edition. I really liked this and feel like it says a lot about the open mindedness, willingness to change mind and grow ideas. Straight away it settled me into a really relaxed, open, questioning state of mind as I read. She makes valid points about the importance of psychological safety and open communication, suggesting “cameras on by default” in video calls which are very common in the remote-first world of work many of us now inhabit. DeGrandis’s closing point in the preface about being doubtful of the notion of *******best practice*********** and urging for a more considered approach where we use our knowledge and experience to try and experiment with different tools we have available to us as situations and teams change.

Tonianne DeMaria highlights some unoriginal but important principles in the foreword that do accent the rest of the book well:

1. Time is your most valuable resource so losing, wasting, or misspending it is bad. She asks when was last time you completed quality work well in advance of deadline was which I think will strike home for many

2. Mental overload creates unhelpful stress and so visualising work can help create conditions of understanding the work-scape. I’ve definitely found this regarding my use of the Eisenhower Matrix as detailed in my last blog post.

3. Obsession with productivity, as opposed to focusing on effectiveness, is unhealthy. Effectiveness can allow us the time for focus on other enriching pursuits “for it is in working well that we can live well”. Reminded me of Bertrand Russel’s pin factory example.

The Thieves

DeGrandis posits five “thieves” of time:

1. Too much WIP (work in progress)

   There are all sorts of reasons we accept extra work from above or say “yes” to well meaning, earnest colleagues (or even grumpy colleagues to be honest) but it can often work in opposition to many of the things we want to emphasise in team dynamics: all work is slowed, context switching decrease effectiveness and increases cognitive load, priority items sit idle among while higher priority items are picked up in the hustle and bustle, quality suffers, team relationships and mutual expectations are strained.

2. Unknown dependencies

   Unknown dependencies tend to arise from either tightly coupled architecture, single or rare repositories of expertise and knowledge (either people or resources), or unrecognised activities that need to be completed before activity X can successfully occur. The measures to reduce the likelihood of these dependencies arising may seem self evident: desigining both systems and organisations to create opposing circumstances to the ones described in those three points: design loosely coupled technical and organisation architectures, well formed teams (see Team Topologies), building for resiliency, sharing and documenting information effectively (good “knowledge management”), making pairing and mobbing on work of all kinds common practice to avoid expertise building up too much in one area or with only one person.

   I can personally see how team / group decision records (particularly in the area of architecture) could help mitigate some of the effects described here. If teams come together to discuss, argue, test ideas, and document their concluding decisions about architecture or anything else, the result is a continual evolving repository of shared knowledge - effectively a story to share understanding and (hopefully) result in measured moves to reduce complexity and coupling. DeGrandis makes a great point about how there is often a trade off to acknowledge when designing organisations that have independent loosely coupled teams - that is can have a resulting decrease in the speed and flexibility of organisation-wide moves.

3. Unplanned work

   DeGrandis’s best point about unplanned work is bound up with the technique of factoring in slack time and not planning for 100% capacity use. Life always happens at which point if there is no slack in the system, everything is disrupted and delayed. She references queue theory that formalises the idea that once queue handling gets past 80% capacity utilisation “queue size begins to increase almost exponentially” leading to drastic drop in progress and productivity. The associated delays in completing work has a financial and personal cost to both businesses and teams respectively. Keeping batch sizes optimal for individual teams alongside not planning for 100% capacity utilisation helps improve effective flow,.

4. Conflicting priorities

   There is always one most important thing. I really liked the clear reiteration of this simple truth. It isn’t that there aren’t lots of important things, but there **will** be a most important, critical priority. DeGrandis describes how when this single thing is not clear and understood by a team, they are understandably far more prone to prioritise other work, create work which does not contribute towards the most important thing, or champion other things closer to them to be the main priority. All of this can block flow, increase the amount of partially completed work, and slow down WIP.

5. Neglected work

   Neglected work is a time thief that I’ve found myself in interesting discussions with product side before - usually because I advocate for a “go slow to go fast” approach where corners are not cut in the interests of a perceived speed of delivery. Rushed work leads to a higher probability of lower quality. The corollary is that technical debt occurs which then leads to to slower, less effective work thereafter. DeGrandis highlights that neglected work usually becomes “emergent in the form of technical debt that accrues while teams are focused on short term priorities”.

Various Thoughts on Revealing the Thieves

I really like DeGrandis’s visualisation of visibility against value (p.41). It would be good to be able to tag work items accordingly to enable constantly being able to make such things visible alongside a kanban board.

Visualising (and documenting) interruptions using the grawlix string (#8%@!)* : every time you are interrupted, you add one grawlix string to the respective work item. The longer the grawlix, the longer the leadtime. Documenting this much further could potentially disrupt communication and relationships (who wants to be classified as an “interruption”?)

Beware the two most common pain points: Too many interruptions & conflicting priorities (where everything is top or high priority).

Highlight team pain when it is fresh via async retro notes.

Discovering work categories (a maximum of 3-7) should come from the team and not from one person in a top down fashion to encourage ownership and understanding. Example of categories might be: unplanned work, maintenance, business requests, team improvements.

Following on from this, consider categorising work by who requested it: internal, external, leadership, etc. After also reading Radical Enterprise, this made me think that perhaps some part of the internal / leadership part of this could be exploded in a ‘radical enterprise’ way? Within a team, if everyone is involved or close to discovery (a la Continous Discovery) then the “who requested it” should usually be the customer as it should arise from an uncovered customer problem?

Learn the usual ratio of unplanned to planned work. This helps plan workload capacity because the team can set WIP limits accordingly to accommodate important, unexpected, urgent work. So for example, if every week has 25-50% unplanned work then allocate 25-50% of WIP for potential unplanned work

Calculation: ratio of planned versus unplanned = unplanned work items / total number of items