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

Advertisements
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

 www.spamcast.net

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
http://www.qaiquest.org/2015/

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.

An archetypal user of dresses.

An archetypal user of dresses.

A persona represents an archetypical user that interacts with a system or product. Typically the first introduction a developer or product owner might have to the concept is when they are writing user stories in the form of <persona><goal><benefit>. If the concept of persona was just used in user stories they would be interesting, however personas have other uses. Other uses of personas include:

  1. Identifying requirements. Personas provide teams with a platform for developing scenarios that incorporate both who will use the system or product and how it will be used. Scenarios delineate purpose-driven interactions between a persona(s) and the product or system. The expectations, motivations and needs defined as part of a persona gives team members the information needed to playact solving problems as if they were an archetypical user. This allows the team to mirror real content and usage without tying the scenario to a specific system solution.
  2. Guiding decisions. As the development process moves from user story to delivered functionality, teams will make innumerable decisions. Personas help teams make better decisions by providing them with a tool to ground or justify a decision. I recently watched a team use a set of personas to make a decision about how they would structure a user survey. The team asked themselves how each persona would react to the design choice being considered. Several tweaks were adopted based on how the team felt the personas would react. The team in question keeps a copy of each persona on the wall in their team room and references the personas as a matter of course. A secondary impact of using a common set of personas to guide decisions is foe the team to align to the common goal of being user focused.
  3. Identifying releases.   While there are a wide variety of release strategies including continuous deployment and minimum viable products, teams and product owners often struggle with grouping functions and features for release. Personas can be used to identify which features and functions are related so that a release can used to solve a persona’s (or group of personas’) specific needs. I often use personas and the scenarios used to generate requirements to identify a minimum viable product.  Once a release candidate is identified I ask the team whether the group of functions being considered could be used by a specific persona and then whether the use would generate useful feedback. If the answer is yes for this part but no for another part, the release can be trimmed down to just the yes part. Alternately if the answer is no because we need something else, I generally start the campaign to increase the prioritization of that “something else.”
  4. Facilitating communication. All projects require well thought out communications. Personas provide the team with information needed to plan communications. Jo Ann Sweeney, author of the Explaining Change column on the Software Process and Measurement Cast strongly suggests that knowing your audience is a critical step in getting communications right (albeit she says it with a British accent). Personas are a tool to define your audience. The details of the persona’s needs, motivation and backstory provide a wealth of information needed to shape and develop a communication plan.

Personas are not just for user stories. Personas represent a lot of valuable information about who will use the system or product  the intrinsic benefit they expect. The information documented is useful across the entire development life cycle. A simple way of reminding a team that it really isn’t just about the system or product is to tape the personas to the project team room wall to create information radiators that remind the team that the users have an identity.

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 definitions of four critical words.  What do the words effectiveness, efficiency, frameworks and methodologies really mean?  These words get used ALL the time, however they really do have fairly specific meanings.  Meanings that, once understood and used to guide how we work, can help everyone to deliver more value and make our customers more satisfied!  The second column is from Jo Ann Sweeney with another of her stellar, Explaining Change columns.  In this segment, Jo Ann talks about content and a framework to guide the development of content.  Anchoring the Cast this week is Gene Hughson with another of his Forms Follows Function columns.  Gene extends his mini-series on microservices with a discussion of whether granularity is irrelevant.  Lots of content in this installment of the Software Process and Measurement Cast!

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