This week we continue our re-read of Crucial Conversations: Tools for Talking When Stakes Are High, Second Edition by Patterson, Grenny, McMillan, Switzler with Chapter 2, titled Mastering Crucial Conversations: The Power of Dialogue. The chapter begins with a quote from Martin Luther King Jr. that highlights the problem with staying silent. “Our lives begin to end the day we become silent about things that matter.”  (more…)


Not a classic business story.

Jerry Owens reached out after we explored the six elements of stories to ask whether all of the elements were equally important for every type of business story.  The short answer is no. However, a more intricate explanation needs to include that even if an element is equally important, each element can be used either in a tactical (focused on an immediate or short-term time horizon) or strategic (focused on the long-term or overall perspective) manner depending on the type of story being told.



The Mountain is one example of a journey-based story structure.

Presentations are a story that the presenter is sharing with an audience, and any good story has a beginning, middle and an end. All too often the beginning is a slide that has an agenda, the middle is slide after slide of data and the end is a slide titled conclusion or questions.  Across that arc, the presenter seeks to inspire, informs or persuade. A better approach is to use one of the tried and true story structures. A story structure is often a useful tool to ensure the audience stays attentive and hears the specific points the presenter is trying to make. The presentation does not need to be the next The Lord of the Rings, but you could or should emulate those plot patterns.

The Monomyth or The Hero’s Journey is one of the most common story structures. The monomyth is cyclical story structure in which a hero team embarks on a journey and then returns when successful. It describes where the journey started, the trials along the way, the goal that was attained and the steps to move forward after the goal has been met. The hero’s journey was originally introduced by Joseph Campbell in The Hero with a Thousand Faces (1949). It is a broad narrative structure that can be used when the presenter is leveraging a journey metaphor, one of the most commonly used stories in business and conference presentations.  The journey is commonly used to describe process improvement, methodology adoptions or business transitions. I tend to leverage a version of the monomyth pattern described by Christopher Vogler that has twelve steps in order to provide a journey type of structure to relevant presentations. (You can view a recent example of how I applied the monomyth to a presentation in Discover The Quality of Your Testing Process). Reflect on every adventure movie you have ever seen and you will recognize the pattern. Even in a business environment, audiences are very comfortable with this approach because they have been trained to recognize the pattern.

Similar Journey Story Narratives:

Freytag’s Pyramid is a structure that follows a similar pattern of rising action climax, falling action followed by final release. This pattern is commonly used in commercials to hold attention (here is an example). In this pattern, the protagonist doesn’t need to return to complete the cycle, but the problem does need to be solved. I often use Freytag’s Pyramid as a guide to ensure short presentations have a plot.

The Mountain begins by describing a current state, showing how challenges are overcome as the story moves away from the current state towards a conclusion/climax, followed by falling action. The most significant difference between the Hero’s Journey and the Mountain is that in the Mountain the conclusion does not have to be positive. For example, the Harry Potter series would have been much less of a Hero’s Journey and more of a Mountain if Voldemort had won. Similarly, the mountain would be a good structure to use to describe an Agile adoption journey that ended in implementing a new waterfall methodology. 

It is easy to see how to use the journey story narratives to tell a story of great quest; however, in a business environment, journey story narratives have a wide range of uses.  Some of the typical business uses are:

  • Establish that change has happened in an organization.
  • Make sure that the audience understands that the progress made was not easy.
  • Show that taking a risk had benefits.
  • Identify the source of new information and knowledge.

 Story patterns like the Hero’s Journey, Freytag’s Pyramid or the Mountain can be used to guide how we deliver information. Story patterns are often useful because they help the audience consume the presentation’s message. Whether a presentation is developed to inspire, inform or persuade, if the presentation does not connect with the audience then the time and effort for all parties are wasted.

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…)

Listen Now

Subscribe on iTunes

I am on vacation for two weeks and could not leave you without some Monday morning mind candy, therefore, we are doing two very special shows this week and next.  This week I have included the responses to the “if you could fix any two (or sometimes just one) things” question I ask at the end every interview from the three most downloaded interviews of 2013.  The top three and one extra were::

SPaMCAST 224 featured Mike Burrows. Mike focused his wishes on:

  1. Changes agents need to take their role as change agents seriously.
  2. Delay is expensive.


SPaMCAST 246 featured Tobias Mayer. Tobias focused his wish on:

  1. People, not management or consultants, need to own scrum. (One wish was enough for Tobias)


SPaMCAST 270 featured Alan Shalloway.  Alan focused his two wishes on:

  1. Everyone needs to acknowledge there are laws of software development.
  2. Assuming that everyone involved in delivering software is highly motivated.


And just because I could . . . a bit of lagniappe, SPaMCAST 138 Featured Jo Ann Sweeney. Jo Ann focused her wishes on:

  1. Reminding the listeners that change often starts before IT starts a project there we need to listen carefully to the stakeholders.
  2. Project teams should care about end users.


If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week the best excerpts from 2014!

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

Listen Now

Subscribe on iTunes

In this episode of the Software Process and Measurement Cast we feature three columns!  The first is our essay on the Agile release plans.  Even after 12 years or more with Agile we are still asked what we will deliver, when a features will be delivered and how much the project will cost.  Agile release plans are a tool to answer those questions.  Our second column this week is from the Software Sensei, Kim Pries. Kim asks why is baselining so important. Kim posits that if we do not baseline, we cannot tell whether a change is negative, positive, or indifferent—we simply do NOT know. Finally Jo Ann Sweeney will complete the communication cycle in her Explaining Change column by discussing delivery with a special focus on social media.

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

QAI Quest 2015
April 20 -21 Atlanta, GA, USA
Scale Agile Testing Using the TMMi

DCG will also have a booth!

Next SPaMCast

The next Software Process and Measurement Cast will feature our interview with Stephen Parry.  Stephen is a returning interviewee.  We discussed adaptable organizations. Stephen recently wrote: “Organizations which are able to embrace and implement the principles of Lean Thinking are inevitably known for three things: vision, imagination and – most importantly of all – implicit trust in their own people.” We discussed why trust, vision and imagination have to be more than just words in a vision or mission statement to get value out of lean and Agile.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Next Page »