Boundaries, like fences are one potential difficulty.

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. (more…)

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

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. (more…)


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.


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 . (more…)

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

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.

Overall project size influences variability.

Overall project size influences variability.

Risk is reflection of possibilities, stuff that could happen if the stars align. Therefore projects are highly influenced by variability. There are many factors that influence variability including complexity, process discipline, people and the size of the work. The impact of the size can be felt in two separate but equally important manners. The first is the size of the overall project and second is the size any particular unit of work.

Overall project size influences variability by increasing the sheer number of moving parts that have to relate to each other. As an example, the assembly of an automobile is a large endeavor and is the culmination of a number of relatively large subprojects. Any significant variance in how the subprojects are assembled along the path of building the automobile will cause problems in the final deliverable. Large software projects require extra coordination, testing, integration to ensure that all of the pieces fit together, deliver the functionality customers and stakeholders expect and act properly. All of these extra steps increase the possibility of variance.

Similarly large pieces of work, user stories in Agile, cause similar problems as noted for large projects, but at the team level. For example, when any piece of work enters a sprint the first step in the process of transforming that story into value is planning. Large pieces of work are more difficult to plan, if for no other reason that they take longer to break down into tasks increasing the likelihood that something will not be considered generating a “gotcha” later in the sprint.

Whether at a project or sprint level, smaller is generally simpler, and simpler generates less variability. There are a number of techniques for managing size.

  1. Short, complete sprints or iterations. The impact of time boxing on reducing project size has been discussed and understood in mainstream since the 1990’s (see Hammer and Champy, Reengineering the Corporation). Breaking a project into smaller parts reduces the overhead of coordination and provides faster feedback and more synchronization points, which reduces the variability. Duration of a sprint acts as constraint to the amount of work that can be taken and into a sprint and reasonably be completed.
  2. Team sizes of 5 to 9 are large enough to tackle real work while maintaining the stabile team relationships needed to coordinate the development and integration of functionality that can potentially be shipped at the end of each sprint. Team size constrains the amount of work that can enter a sprint and be completed.
  3. Splitting user stories is a mechanism to reduce the size of a specific piece of work so that it can be complete faster with fewer potential complications that cause variability. The process of splitting user stories breaks stories down into smaller independent pieces (INVEST) that be developed and tested faster. Smaller stories are less likely to block the entire team if anything goes wrong. This reduces variability and generates feedback more quickly, thereby reducing the potential for large batches of rework if the solution does not meet stakeholder needs. Small stories increases flow through the development processes reducing variability.

I learned many years ago that supersizing fries at the local fast food establishment was a bad idea in that it increased the variability in my caloric intake (and waistline). Similarly, large projects are subject to increased variability. There are just too many moving parts, which leads to variability and risk. Large user stories have exactly the same issues as large project just on a smaller scale. Agile techniques of short sprints and small team size provide constraints so that teams can control the size of work they are considering at any point in time. Teams need to take the additional step of breaking down stories into smaller pieces to continue to minimize the potential impact of variability.

Does the raft have a peak load?

Software development is inherently complex and therefore risky. Historically there have been many techniques leveraged to identify and manage risk. As noted in Agile and Risk Management, much of the risk in projects can be put at the feet of variability. Complexity is one of the factors that drives complexity. Spikes, prioritization and fast feedback are important techniques for recognizing and reducing the impact of complexity.

  1. Spikes provide a tool to develop an understanding of an unknown within a time box. Spikes are a simple tool used to answer a question, gather information, perform a specific piece of basic research, address project risks or break a large story down. Spikes generate knowledge, which both reduces the complexity intrinsic in unknowns and provides information that can be used to simplify the problem being studied in the spike.
  2. Prioritization is a tool used to order the project or release backlog. Prioritization is also a powerful tool of reducing the impact of variability. It generally easier to adapt to a negative surprise in a project earlier in the lifecycle. Teams can allocate part of their capacity to the most difficult stories early in the project using complexity as a criterion for prioritization.
  3. Fast feedback is the single most effective means of reducing complexity (short of avoidance). Core to the DNA of Agile and lean frameworks is the “inspect and adapt” cycle. Deming’s Plan-Do-Check-Act cycle is one representation of “inspect and adapt” as are retrospectives, pair-programming and peer reviews. Short iterative cycles provide a platform to effectively apply the model of “inspect and adapt” to reduce complexity based on feedback. When teams experience complexity they have a wide range of tool to share and seek feedback ranging from daily stand-up meetings to demonstrations and retrospectives.
    Two notes on feedback:

    1. While powerful, feedback only works if it is heard.
    2. The more complex (or important) a piece of work is, the shorter the feedback cycle should be.

Spikes, prioritization and feedback are common Agile and lean techniques. The fact that they are common has led some Agile practitioners to feel that frameworks like Scrum has negated the need to deal specifically with risks at the team level. These are powerful tools for identifying and reducing complexity and the variability complexity generates however they need to be combined with other tools and techniques to manage the risk that is part of all projects and releases.