The Checklist Manifesto by Atul Gawande, Re-read Week 8 – The Test

In week 8 of re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along) we read about building a usable checklist. In this chapter, Dr. Gawande puts all of the lessons learned in chapter 6 into action and tests the result.

 

The Checklist Manifesto by Atul Gawande, Re-read Week 3 – The Checklist

It is week 3 of our re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). Chapter 2 continues building the case for checklists to deal with complex and complicated environments. This chapter firmly pins down the idea that checklists save time, money and lives.

 

The Checklist Manifesto by Atul Gawande, Re-read Week 2 – The Problem With Extreme Complexity

It is week 2 of our re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). Chapter 1 builds the case that the world we live in and the work that we do is very complex.  Complexity creates the possibility for errors, and checklists are a tool to help avoid error in complicated and complex environments.

 

Why Complexity Matters

Chips Pack Complexly!

Complexity introduces uncertainty. The operational definition of complexity is the interaction of components in which the outcome is not perfectly predictable based on the known or measured inputs.  The question posed in this discussion of the difference between complication and complexity is why we should care about complexity.  In the software centric part of IT departments, the simple answer is that complexity changes the behaviors of everyone involved in three major ways.

 

Complexity and Complicated Are Different

The Environment is Complex

Having been involved in the world of buying, building, maintaining, and testing software for many years, one of the longest running conversations between everyone involved with delivering value is the impact of complexity on cost, effort, quality and even on the ultimate solution to business problems.  The concept of complexity and the impact of complexity is unfortunately – complex.   The importance of developing an understanding of complexity is complicated by a lack of a crisp definition and a confusion of the topic with the concept of complicated.  The difference between complicated and complex is not a mere nuance; the distinction will affect the options we perceive are available to solve any specific problem.

 

Systems Thinking: Difficulties

Boundaries, like fences, are one potential difficulty.

Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options. Dan and Chip Heath indicate that options are a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.  The difficulties with using systems thinking fall into three categories.

• Boundaries
• Complexity
• Day-to-Day Pressures

Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.  Boundaries are a key tool for defining teams and providing a send of belonging; however, some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.  Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that, even if perfectly optimized, will not translate to the delivery of increased business value.  In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets, only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization.

 

Systems Thinking: Habits Of A Systems Thinker

Sometimes you have to seek a little harder to understand the big picture.

We should be guided by theory, not by numbers. – W.E. Deming

Many process improvement programs falter when, despite our best efforts, they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds; the impact overtaken by the inertia of the overall systems. Systems thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events.  Systems thinking is all about the big picture. Grasping the big picture is important when approaching any change program.  It becomes even more critical when the environment you are changing is complex and previous attempts at change have been less than successful. The world that professional developers operate within is complex, even though the goal of satisfying the projects stakeholders, on the surface, seems so simple. Every element of our work is part of a larger system that visibly and invisibly shapes our individual and organizational opportunities and risks.  The combination of complexity and the nagging issues that have dogged software-centric product development and maintenance suggest that real innovation will only come through systems thinking.

 

Metrics: Decisions Needed When Using A Cumulative Flow Diagrams

The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics  and in more complex versions provide a basis for interpreting the flow of work through a process. A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Learning to read a CFD will provide a powerful tool to spot issues that a team, teams or program may be facing. But to get the most value a practitioner needs to decide on granularity, a unit of measure, and time frame needed to make decisions.

 

Metrics: Adding Complexity to Cumulative Flow Diagrams

A waterfall is an example of a complex flow!

The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics introduces most of the concepts needed to read and use a CFD. However, software development, regardless of the size of the work or the method used, is more complicated.  CFDs adapt to the true complexity of software development. CFDs allow teams and managers to visualize the flow of work .

 

Splitting User Stories: Alternate Patterns

Too many things going on will lead to less attention to anyone subject.

Splitting user stories is an important tool to help teams in a number ways ranging from improving the flow of stories through the development process, to improving the teams understanding of what is required to deliver the story. In almost every case, smaller is better.   We have identified a number techniques for splitting user stories and a framework for evaluating those splits. Additional splitting techniques include:

1. And/Or Removal: User stories that include “and” or “or” typically reflects compound thoughts. This is an indication that the story is an epic, which will too large to be complete in a single sprint. Split the stories to eliminate instances of “and” and “or“. An example of a story with an “and / or” problem is: As a project manager I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing. Stories could be constructed separately for reviewing time accounting, approving time accounting, reviewing expenses and approving expenses. Simplicity reduces the potential for confusion.
2. Simple/Complex: Complexity makes a story harder to complete and therefore the story will take longer to deliver compared to a similarly-sized, simple story. Splitting can be used to isolate functionality that is more or less complex. Splitting based on complexity provides product owners the option of deciding on whether a strategy of doing the simple stories first. This approach could provide teams with insights that reduce the complexity of later stories.
3. Splitting Non-functional Requirements: Many user stories combine function and non-functional components. For example the story “As a home brewer, I want a conversion calculator that returns results in 40 point type display so that I can determine the alcohol level in the beer.” The story could be split to address the functional side of the story (conversion results) from the non-functional component (size of display). Splitting the story lets team to deliver the calculation before having to address how it is displayed.

These three patterns for splitting user stories (in addition to those noted in previous articles including workflow, business rules, data variations, elementary processes or syntheses of patterns) are just tools for teams. Teams split stories to help them understand what they are committing to deliver, to reduce the complexity of large stories (or at the very least to isolate the hard parts) and so they can enhance their ability to consistently deliver value. Splitting stories increases productivity and quality and reduces the amount of time the team spends scratching their collective heads trying to figure out what they will deliver and how they will deliver.