Chapter 2 of Agile Conversations by Douglas Squirrel and Jeffrey Fredrick is titled, Escaping The Software Factory. The idea that software development and maintenance fit a factory model in which people are fungible and that processes are deterministic is a thing in 2021 (as it was when this book was written). I have always been hard-pressed to buy the factory/manufacturing model. I have worked on an assembly line. One of the jobs I had was building tires for Firestone Tire and Rubber Company at their plant in Memphis. That job was one of the reasons I made sure I went to university. Whether the assembly line model was truly appropriate even for tire manufacturing would be interesting to debate (the plant is gone, no amount of scientific management could save it). At the very least, software development and maintenance are better served by team-based collaborative approaches. Words like team-based and collaboration require communication (something that did not happen on the assembly line, except when we had union meetings) so that rigid processes and micromanagement can be minimized.

There are several important points in the chapter. The first is that people are the core of knowledge work (probably anything that can’t or hasn’t been fully automated). People by definition are complex, messy systems (see the Cynefin sidebar at the end of the chapter), therefore deterministic models will fail. Not embracing the people and mindset side of agile, lean, and DevOps leads to failure. That is a hard lesson for those that have invested in learning and championing deterministic models or have been successful as micromanagers. 

The second area I want to highlight is based on the section on the emergence of DevOps. The authors highlight four areas that are a litmus test for whether what’s called DevOps really fits the right mindset.  They are:

  1. Respect,
  2. Trust,
  3. Healthy Attitude About Failure, and
  4. Blame Avoidance.

A colleague, Jeff Singleton, talks about the Kanban Mind (we have recently been co-teaching a Kanban Class). These four areas are not just a litmus test for DevOps but the health of any Lean, Agile, or DevOps approach. Simply put, without healthy doses of all four areas, human interactions are not conversations, but are more akin to commands, micromanagement, or finger-pointing. None of the later concepts are conducive to lasting change.

The final area I want to highlight this week is the author’s explanation of Cynefin at the end of the chapter sidebar (shouldn’t this have been an end bar? :)) Cynefin is a tool to help people understand that context affects approach. The same approach for decision-making makes no sense when cause and effect is well understood (obvious) compared to scenarios where cause and effect are understood after the fact (complex). Much of software development is complex (and sometimes chaotic), therefore expecting best practices and deterministic models to be more than part of any solution is not useful. For example, a request to add a person to an existing role in an HR system has an obvious solution. Using best practices (maybe even automation) makes sense.  Whereas, adding a new class of users to an HR system integrated with care management or scheduling is a complex set of decisions and actions (just consider the number of meetings and decisions made by humans that will be required).  Cynefin provides a framework for thinking about decision-making differently.

My experiment of the week:

I originally planned to begin experimenting with the ideas from Agile Conversations with Chapter 2; however, Chapter 1 reminded me of the need to take a mindset-centered approach to change and to incorporate the ideas from Cynefin. I will review my decisions this week to assess whether I am getting lazy and assuming that situations are more deterministic than complex,  and therefore not putting myself in the right place to collaborate.

Remember to buy a copy of Agile Conversations (Amazon Affiliate Link) and read along

Previous Installments

Week 1: Logistics and Introduction