This week, we take a detour thanks to Extraordinary Badass Agile Coaching. Over the past two chapters, the book has drilled us on recognizing and adapting to situational nuances as a crucial skill for effective coaching. I will admit that my first few years of coaching were formulaic. I did not spend the needed time to understand and address nuances of context or differences in individuals’ journeys through life. I do not remember when I learned that roles and situations change the trajectory of coaching, as does the starting point of the person or persons you are coaching. At some point, I got the point. In this chapter, diversity is an omnibus term used to describe inclusiveness across a range of different social and ethnic backgrounds and of different genders, sexual orientations, life experiences, and more. Galen-Personick focuses on four specific areas. Rather than recounting the four, what struck me during this read was the impact privilege has on both delivering and being coached. That’s what I discuss in today’s podcast. 

Jeremy Berriault brings his QA Corner to the podcast. This week we communicated on the topic of communication.  


Today marks the end of year 15 on the Software Process and Measurement Cast, and we are closing the year with pitchfork and torches. We discussed the world of knowledge work in 2022. Leadership, principles, value, and values take center stage. Panels like this make me want to do panels every week!

The panelists (other than myself) are:

Jeremy Berriault Web: 

Jon M Quigley Web:

Kevin Rush Twitter: @Kezrush

Chris Hurney Web: Twitter: chris_hurney

Participating in spirit (they were on part one last week)

Susan Parente Twitter: @TechRiskManager

Jeremy Willets   Blog: 


Book Cover

Today we tackle Chapter 8 of Crucial Conversations: Tools for Talking When Stakes Are High, Second Edition by Patterson, Grenny, McMillan, Switzler. Arguably the feel of this re-read to date has had a bit of book report feel. Since this is a first read of the book for me, consuming what I have read has tended to be a reflection of how I have been consuming the concepts. We have approximately 3 weeks left, do you have ideas for the next book?   (more…)


We are back with Chapter 8 of Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!). Chapter 8, titled The miniLab, focuses on overpromising and continues to layer on toxicity to the Theranos story. (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 503 features our essay “Culture: The Knife’s Edge of Change.”  I have often heard the line, culture eats change for breakfast. Culture, culture, culture – the success of every change that is considered or implemented balances on the knife edge of culture. Aligning cultures so that change is possible requires seeing the differences and then minimizing enough of those differences to allow change to happen.

We also have an installment of the Alpha and Omega of Product Development with Jon M Quigley.  In this installment of Jon’s wonderful column, we discuss the muda of underutilizing people. Muda, waste, is not just generated through process or transforming raw material.  

We conclude with a visit with Gene Hughson.  We discuss an entry from his Form Follows Function Blog titled: “When asked for the time, don’t explain how your watch works”. Communications between the user and technical domains is fraught with difficulties. A problem? As Gene always says,  “exactly!”

Re-Read Saturday News

We will complete our re-read of Turn The Ship Around next week with a few final thoughts.  The next book in the series will be The Checklist Manifesto  (use the link and buy a copy so you can read along) by Atul Gawande. Today we complete re-reading the chapters in  L. David Marquet’s Turn the Ship Around!  Chapter 28, 29 and Afterthoughts complete Marquet’s reflection on the leader-leader model and his journey of discovery.

Current Installment:

Week 18: A New Method of Resupplying and Ripples  – (more…)

Book Cover

In week ten of the re-read of L. David Marquet’s Turn the Ship Around! we add two more mechanisms for control and complete part two the book. This week the two chapters are A New Ship and We Have A Problem. (more…)

TDD is a life jacket for Quality.

TDD is a life jacket for quality.

Test Driven Development promises serious results for teams, organizations, and customers, including improved quality and faster delivery. The promises of TDD, or any of the other variants of test-first development techniques, are at least partially offset by costs and potentially tragic side effects when it is done poorly.

The positive impacts explored in earlier articles on TFD and TDD include: (more…)

Learning games are tool in learning empathy.

Learning games are tools for learning empathy.

A University of Virginia study in 2013 found that humans are hardwired for empathy. However, arguably we are not necessarily superb practitioners. Given that most software development, Agile or not, is done in a team, we need to find ways to hone the skill. An oft-quoted study from the University of Michigan published in 2010 found that students were less empathetic than in the 1980’s.  Why this fall in observed empathy has occurred is open to debate, but stress, distractions, isolation (think about that home office) and multi-tasking have been suggested as contributors. Regardless of why we have gotten worse at empathy, there are steps that can be taken to get better at empathy. Those steps include: (more…)

The Mythical Man-Month

The Mythical Man-Month

In the seventh essay of The Mythical Man-Month, Brooks returns to the topics of organization and communication using story of the Tower of Babel as a metaphor for many of the engineering fiascoes seen in software development. In the story of the Tower of Babel, when communication broke down, coordination failed and the project ground to a halt. As projects become larger and more complex, communication and organization always becomes more difficult and more critical.

The essay Why Did the Tower of Babel Fall? presents three mechanisms to facilitate communication.

  1. Informal Communication, which includes all of the telephone calls and conversations that occur in and among teams. Healthy teams and teams of teams talk, interact and share information and ideas.
  2. Meetings are more formal and include reviews, technical briefings, demonstrations, sprint planning and release planning events. Done well formal meetings, whether part of an Agile framework or not, can find problems and share information and knowledge.
  3. Project Workbooks are the repository of the evolving intellectual property that defines any significant endeavor.

Brooks goes into depth on the definition and structure of the project workbook. While the workbook that Brooks describes is a physical construct we should consider that the idea of workbook is less of a document then a structure for grouping information. All the project documents need to fit into the workbook and be part of the overall structure of project information so that it can be reused and inherited from. The ultimate goal of the workbook is ensure that everyone who needs information has access to the information and gets the information.

Workbook Mechanics: In order to meet the goal of ensuring of everyone access to the information they need, the workbook needs to be maintained and organized. For example, Brooks suggests ordering and numbering all project memorandums (we would call these emails now) so that people can look through the list and actually see if they need information. Brooks points out that as size of the effort, project or program goes up, the complexity of maintaining and indexing the project communications increases in a non-linear fashion. Today’s technical tools like wikis, SharePoint and hypertext markup make curating and sharing information easier than paper and microfiche (if microfiche is before your time, Google it). As a reminder, capturing and reusing IP is required in all types of work. As a coder, it is easy to fall prey to the idea that the code and a functional system is the only documentation required; however, this is false. For most large efforts, capturing decisions, designs, architectures and even the occasional user manual is an option that can be ignored only if you want to court a communication failure. Remember however that over-reliance on documentation is not the goal.

Brooks uses the formula (n2-n)/2, where n is the number of people working on an effort, to define the possible communication interfaces. As the number of people increase the number of interfaces increases very quickly. Organization is a tool to reduce the amount of interfaces. This is one of the reasons why small teams are more effective than large teams. Scaling Agile is often accomplished by assembling teams of small teams. We use the metaphor of trees or flowers are often to describe the visualizations of team of teams. Communications spreading from a central point can look like a tree or flower. Organizations leverage techniques like the specialization and division of labor to reduce the number of communication interfaces.

There is often push back on division of labor and specialization in Agile. This push back is often misplaced. Within a team the concept of T Shaped people, which eschews specialization, increases capabilities; however, teams often specialize thus becoming capability teams. Capability teams often tackle specific types of work more effectively and efficiently by reducing learning curves. Capability teams fit into Brooks’ ideas on organizing to reduce the communication overhead.

Brooks proposes that each grouping of work have six essential needs.

  1. A Mission,
  2. A Producer,
  3. A Technical Director or An Architect,
  4. A Schedule,
  5. A Division of Labor, and
  6. Interface Definitions Among the Parts.

Four of these essentials are easily understood; however, the roles of the producer and technical broke new ground and extended the ideas Brooks began in The Surgical Team. The role of the producer is to establish the team, establish the schedule and continually acquire the resources needed to deliver the project. The role of the producer includes many of the classic project and program management activities, but also much of the outside communication and coordination activities. When small effort with a single team the roles of the producer and technical director can be held by the same person. As efforts become larger and more complex the roles are generally held by separate people. The role of the producer in the Scaled Agile Framework (SAFe) is handled by the Release Train Engineer. The technical director focuses on the design and the technical components (inside focus). In SAFe this role is held by the System Architect.

Brooks leverages the metaphor of the Tower of Babel to focus on the need for communication and coordination. Projects, team and organizations need to take steps to ensure communication happens effectively. Techniques like meetings and project workbooks are merely tools to make sure information is available and organized. Once we have information organization provides a framework to ensure information is communicated effectively. Without communication any significant engineering effort will end up just like the Tower of Babel.

Are there other mechanisms for organization, communication and coordination that have worked for you? Please share and lets discuss!

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

The Mythical Man-Month

The Mythical Man-Month

In the sixth essay of The Mythical Man-Month, titled Passing the Word, Brooks tackles one of the largest problems any large project will have: communicating the architecture. Whether you have defined the architecture upfront or just as it is needed, passing the word is critical to ensuring everyone stays on the same page and what gets built works and is what is wanted. This essay provided Brooks’ take on how to ensure that a large number of people hear, understand and implement the architects’ decisions. He describes seven inter-locking techniques for passing the word; they are:

  1. Written specifications. Many developers value documentation on the same level as reality TV shows; however, as projects and products are scaled past one or two co-located teams documentation becomes a valuable tool. Written specifications define limits, appearance, UX and interfaces. In essence, the written specification is the primary output of the architect that provides everyone with the boundaries of the product and how the user will  interact with the product.  What the written spec, the product of the architects, doesn’t define how the guts of the product will work which is the purview of the developers.  Written specifications do not have to relate to large paper manuals; techniques like WIKI’s have been used to capture and transmit specifications and to solicit interaction.
  2. Formal definitions. Words are great, but imprecise. Even when everyone involved in an effort shares the same first language (which is less and less true as the metaphorical world shrinks). Formal languages and modeling techniques can be used to document the specification and to capture exceptions and explanations. Alternately, simulators and prototypes are mechanisms that can be used to capture and document the specifications.
    The problem with having two definitions of the same idea is what happens when they disagree. Brooks points out that the answer is to never have two communication methods.  Rather he points out you need a tool to break the tie if a disagreement occurs. Either have one method of communicating the spec or have three (think odd numbers).
  3. Direct incorporation. Direct incorporation builds a structure or framework for the product that cannot be changed by the implementer.  For example, a set of predefined objects or classes. Deviations and changes, when needed, require renaming and recompiling modules and interfaces. I view this as more of a control mechanism; however, the original structure acts as baseline to communicate the architectural vision.
  4. Conferences and courts. This category can be described at a high level in one word – meetings. Brooks suggests two types of meetings to control and communicate change. The first is the conference. A conference is a group meeting held on a periodic basis (weekly or monthly) that includes all architects and representatives from the hardware and software developers. Changes and refinements are reviewed and decisions are made. Consensus drives decisions; however, if consensus cannot be achieved the lead architect decides (appeals to overall project leader are allowed). This type of meeting might be recognized as a type of architectural change control board (CCB). The second type of meeting is the “court.” The court is more of a formal meeting of the architects, representatives of the implementers, management, marketing (if relevant) and other stakeholders to make decisions about any nagging issues on how the architectural specification is to be implemented. Courts are typically held annually or semi-annually.
  5. Multiple implementations. One possible solution to the issue of discrepancies between the specifications and what is implemented is to support multiple implementations. Alternate solutions can move forward and be evaluated. While sometimes possible, in general this solution can generate a significant drain on people and resources.
  6. The telephone log. Questions to the architects come up as implementers interact with the specification. In this technique you capture all questions and answers and publish them so everyone can benefit from the conversations. Wikis make a great tool for capturing and disseminating Q&A content.
  7. The product test. The independent test is a tool to identify discrepancies between the specification and the implementation. Some form of independence, whether as an independent test group or through test driven development, is needed to ensure a consistent translation of the vision into a product. Remember that the final arbiter is the customer/user and their product test will be merciless.

Communication is the single most prevalent problem any large group effort will encounter. In Passing the Word, Brooks provides seven possible mechanisms to ensure that everyone hears the same story and has the chance to develop a clear and consistent understanding of that story.

Do you have other solutions that you can suggest? Please share?

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect