5

EMPIRICISM

It should be straightforward to calculate at which points throughout the day you need to heat or cool, right? Which information do you need? If you think about it for a little bit, you will likely come up with a list similar to this:

1. Number of people in the room: a human body when sitting is roughly a 100-watt heat source

2. Level of activity of the people in the room: the more active they are, the more heat they generate

3. Volume of the room: Length 3 Width 3 Height

4. Capacity of the HVAC: how fast the system can cool/heat a certain amount of volume

5. Start temperature at 8 a.m.: the starting point

6. Other heat sources: laptop, projector, food, etc.

7. Weather forecast: change in outside temperature during the day; clouds vs. sun

8. Insulation of the room: how the outside temperature changes affect the temperature in the room

9. Time of year: the position of the sun throughout the day

10. Windows and doors opened and closed: expected lost or gained temperature

11. Orientation of the room: north, south, penthouse, basement, etc.

Which of these remain constant throughout the day?

1. Number of people in the room

2. Level of activity of the people

3. Volume of the room

4. Capacity of the HVAC

5. Start temperature at 8 a.m.

6. Other heat sources

7. Weather forecast

8. Insulation of the room

9. Time of year

10. Windows and doors opened and closed

11. Orientation of the room

Quite a few are predictable, so you should be okay creating the plan for the day.

What happens if only half the people show up because of a traffic problem? What if the projector malfunctions and you work with flip charts? What if everyone uses a personal laptop? What if the weather forecast changes and the current heat wave is disrupted by a severe storm? What if someone opened the window for some fresh air?

Even if most parameters are predictable, the few unpredictable ones have the power to ruin the best plan. A minor change can have a huge impact on the final outcome. In fact, you may even find yourself trying to control the environment and people whenever they seem to veer from the initial plan: “You can’t open the door to go to the bathroom yet. A break isn’t scheduled for another 22 minutes.” Sound like any projects you’ve been on?

This obviously isn’t the way you keep rooms at a comfortable temperature. There is a simpler solution: a thermostat.

The thermostat compares current temperature with the target temperature. Every couple of minutes the thermostat calculates the delta and reacts accordingly. This feedback allows you to ignore all those unruly variables. It doesn’t matter if only half the people show up, the weather forecast is wrong, more heat sources are introduced. The thermostat just copes with the variability.

The thermostat is a beautiful metaphor. It decouples you from all the unknowns and instead introduces a feedback loop. It takes a transparent reading, inspects, then adapts. The shorter this loop, the more accurate the temperature.

Let’s bring this back to product development.

What variables do you need to consider now?

1. Number of people

2. Scope

3. Budget

4. Schedule

5. Technology

6. Infrastructure

7. Skills of the people working in the project

8. Dependencies to other systems or components

9. Quality

10. Vacations/sick days

11. Attrition

12. Marketplace changes

13. Regulations

14. Access to the right people

Which of these are constant or predictable?

Compare this list to the temperature variables. Which are more predictable? You have hopefully determined how difficult it would be to predict the variables for the temperature problem. So why do people continue to try in the world of product development?

You may already have a team, but people may quit, get sick, or take leave. The budget and schedule may be fixed at first, but both can certainly change over the course of the effort. Some core infrastructure and technology decisions are made early on, but how they are implemented varies quite a bit. And let’s not even waste any paper on whether scope is predictable.

Very quickly, you see how the world of product development is even more complex than the temperature problem. And just like the temperature problem, you need a simpler approach that introduces transparency → inspection → adaptation feedback loops. So, what is the product development industry’s version of a thermostat?

Scrum.

The more detailed mechanics of Scrum are addressed in Chapter 6. For now, let’s look at the theory behind Scrum and much of the agile movement.

Our team . . .

Answer: 9-13 → Obvious

      14-23 → Complicated

      24-35 → Complex

      36-45 → Chaos

Most product development initiatives fall into the complex domain. So what does “complex” mean?

Ralph Douglas Stacey created the Stacey Matrix in 2001 to visualize the complex reality of product development.¹

The y-axis displays the degree to which the requirements are agreed upon. Close to the origin there is agreement with exactly what is needed: no changes are expected. The further you move away from the origin, the less agreement there is. At the extreme, nobody agrees; they may not even agree on some high-level goals.

Figure 5-1 Modified Stacey graph

The third axis, added by Ken Schwaber, introduces the team dimension. How well are all the people working together? Does the Development Team have all the skills needed to deliver a “Done” (releasable) product Increment at the end of the Sprint? Do you even have a complete team yet? Has the team gone through the Forming-Storming-Norming-Performing⁴ phases? Does trust exist? One of the most important ingredients for high-performing teams is trust—without it, no effective team behavior will emerge.⁵

Considering the three axes, think about your current development effort (or just pick one from your past) and try to place it on the below graph. Are you in the simple, complicated, complex, or even chaos domain?

Usually, you will observe that technology and requirements are in the complicated area, and if you plot that point, the intersection is in the complex domain (see Figure 5-2), which completely changes the game.

Figure 5-2 The intersection of complicated dimensions is complex

Figure 5-3 shows the basic structure.

Cynefin is often considered as a categorization framework, whereas Snowden is adamant that it is a “sense-making” framework, constructed from people’s pasts, anticipating future experiences. Table 5-1 outlines the difference.

Figure 5-3 Cynefin basic structure: ordered vs. unordered domains

Table 5-1 Comparison of Categorization and Sense-Making Models

The goal of Cynefin is to answer this question: How do you approach problems differently, depending on the domain they belong to?

Depending on where the home is being built, you need to consider certain general conditions.

Certain problems need to be analyzed correctly. If not, bad things might happen. You operate with known-unknowns, and the approach is to sense-analyze-respond.

For an expert, the complicated domain repeats itself from project to project, therefore good practices are established over time. This is unlike the obvious domain where the same steps (best practices) are always applicable.

Figure 5-4 With Cynefin, simple and complicated are ordered domains.

These two domains are ordered; there is a clear relationship between cause and effect. Because of this repeatability, a defined linear approach can be used.

To be successful, it is essential that the applied process makes the unknown-unknowns visible. By making them visible, you can address them accordingly. You get a chance to analyze them.

In the obvious domain, you have tight constraints because you can rely on the established best practices. You know how long a certain job will take and how much it will cost. In the complicated domain, you work with governing constraints. You review certain calculations and have an agency oversee your work to make sure you do not deviate and that you analyze correctly. However, in the complex domain, you need enabling constraints that will help you understand the problem at hand so that you can tackle it. Has a team ever told you they cannot estimate a certain feature because they have absolutely no idea what technology to use or how to design it?

You have likely already used enabling constraints like proof of concepts, prototypes, or technical “spikes” that allow you to understand the problem you’re facing. This knowledge allows you to inspect and adapt the plan as you go with emerging practices along the way.

Figure 5-5 With Cynefin, complex is an unordered domain.

Now the problem you often face, is that companies expect a date and cost estimate before you start the project as it needs to be budgeted well ahead. Later in the release planning chapter (Chapter 8), you will be provided with ways around this, such as two-phased budgeting.

Scrum is an empirical management framework for complex initiatives. It appreciates the uncertainty and complexity with the resulting inability to plan everything upfront in product development.

Would you prefer your team to be made up of cross-functional individuals or specialists?

Would you like to increase opportunities for communication and learning or limit them?

Would you want the team to self-organize or have a manager assign their tasks?

Who should make the decisions? The team members or their manager?

What kind of activities would you like a job site manager to do?

A good contractor will put together an upfront plan based on industry best practices and on what he learned from previous projects. He will bring in specialists like carpenters, plumbers, and masons who focus only on their own jobs with no obligation to understand the overarching vision. Learning on the job is likely not an option. Communication should mostly happen through the plan or the site manager.

Would you prefer your team to be made up of cross-functional individuals or specialists?

Would you like to increase opportunities for communication and learning or limit them?

Would you want the team to self-organize or have a manager assign their tasks?

Who should make the decisions? The team members or their manager?

What kind of activities would you like an ER manager to do?

Your answers are likely quite different from the home construction scenario. A team of doctors in an emergency room need to be cross-functional rather than specialists as they cannot predict what’s coming through the door next. They need to keep communication at a high level and allow extra slack time to help and learn from each other. They need a manager who essentially gets out of their way so that they can do their jobs. An ideal manager would act as a servant leader and help wherever she can by removing obstacles and setting up a cadence of inspection and adaptation of their processes. She would ask questions like “How did that day go? How can we improve tomorrow? How can I help?”

Both examples are of well-established industries and are perfectly reasonable strategies. It comes down to the predictive nature of what they are building that changes the way the teams are put together and managed. When there is a mismatch between management style and the type of complexity of the product, you will see problems.

With product development, most of what you build resides in the complex domain. These products are typically far too difficult to analyze upfront, often leading to “analysis paralysis.”⁸

By breaking out a piece of the complex pie, Scrum allows you to analyze just that piece for the upcoming Sprint and make it plannable. This is done through continuous refinement, preparing just enough of the Product Backlog for Sprint Planning. In Sprint Planning, a plan for the next Sprint is created—the Sprint Backlog, which the Development Team tracks closely throughout the Sprint.

By doing this, you establish a circular current between the complex and complicated domains. The product is complex, the plan for the Sprint is complicated. At the end of the Sprint, the Scrum Team and stakeholders reflect by reviewing the new product Increment in the context of the whole and update the complex Product Backlog accordingly. However, the product will always remain complex; you are never completely safe from the unknown-unknowns. Strange things can and will happen along the way, possibly causing short interludes with chaos (see Figure 5-6).

Figure 5-6 Complex to complicated and back, creating a continuous learning flow with an interlude with chaos

Scrum helps you cope with complex problems by implementing empirical process control.

Essential complexity is complexity inherent to the problem and cannot be removed.

Accidental complexity is the entanglement of components/ideas that is not necessary for solving the problem. This complexity is accidental because it emerges based on our own decisions.

Doing Scrum well means that you can sustain the product by being “Done” at the end of each Sprint, which requires sound engineering. When problems arise over time, making your product harder to release, think about these obstacles as accidental complexities. Scrum addresses essential complexity (the product) by minimizing accidental complexity (the process)—and therefore minimizes risks.

What is a good mistake? A good mistake is when you try to solve a problem that belongs in the realm of essential complexity. If you tackle a specific feature or technological challenge first, then you gain an advantage over your competition. You may fail, but you will also learn and possibly come up with another potential solution. Therefore, you have made a good mistake. Without mistakes, you do not take enough good risks and will disappear into the sea of mediocrity.

In Lewis Carroll’s Through the Looking-Glass, the Red Queen and Alice are constantly running but not making any progress.

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else—if you run very fast for a long time, as we’ve been doing.”

“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”

Figure 5-7 Alice in Wonderland learning about pace

As the allegory in Figure 5-7 suggests, to stay relevant in business, you must outcompete and outpace the competition by tackling essential risks faster than they do. These risks could be feature or technical risks that you address as part of the Product Backlog. In general, it is a good practice to have high-risk Product Backlog items higher up in the Product Backlog to enable quick learning and allow enough time to find an alternative solution or even to cancel the product without having lost too much money. Other ongoing, product-specific essential risks can be addressed through the definition of “Done.”

You need to take risks and keep them in your sights until they are handled. Eessential risks emerging from essential complexity are good and can lead to a competitive advantage.

What about accidental complexity and accidental risks?

Tharwon Arnuphaptrairog’s meta study on software project risks defines “risk” several ways:

The PRINCE2 definition is more suitable here as it closely relates to the complexity of product development.

Arnuphaptrairog’s work analyzed 12 studies to identify similarities. Important categories were “risk frequency by dimension” (see Table 5-2) and “risk items by frequency” (see Table 5-3).

Table 5-2 Software Risk Frequency by Dimension

User

User dimension included points such as lack of adequate user involvement, failure to gain user commitment, lack of cooperation from users, failure to manage end user expectations.

Requirements

Requirements dimension included misunderstanding of the requirements, continuous requirements changes, unclear system requirements, too narrow a focus on the IT project issues, and overlooking the impact on the business in general.

Complexity

Complexity dimension included inadequate security features built into the system, use of new technology, performance shortfalls, strained science capabilities.

Planning and Control

Planning and control dimension included unrealistic time and cost estimates, gold plating, change not managed properly, unclear/misunderstood scope/objectives, changing scope, artificial deadlines, project ambiguity, lack of effective project management methodology, inadequate estimation of required resources, project progress not monitored closely enough.

Team

Team dimension included personnel shortfalls, lack of required knowledge/skill in the project personnel, lack of people skill in project leadership, changes to membership on the project team

Organizational Environment

Organizational Environment dimension included lack of top management commitment to the project and lack of support, corporate politics with negative effect on project.

Table 5-3 Software Risk Item by Frequency

Let’s look at how the empiricism of Scrum helps address each of these points:

1. Misunderstanding of requirements

The ongoing refinement done by the Scrum Team, fostering crucial conversations between the Product Owner and the Development Team, helps to paint a cohesive picture and understanding of the product under development. Only “Ready” Product Backlog items are being brought into a Sprint. The resulting review of the “Done” Increment closes the feedback loop of the product. You see a working product, not only documentation.

2. Lack of top management commitment and support

The key to getting support from management is building trust. In many ways, Scrum becomes a trust generation framework by delivering results each Sprint and by providing transparency.

3. Lack of adequate user involvement

Change is good, the more the better. The more the users get a chance to influence the product under development, the better the product and the higher the resulting value will be. Providing users with the chance to inspect a working product is crucial.

4. Failure to gain user commitment

See point 3 above. Allowing a user to see and understand that the product under development can be molded, even while it is being developed, creates more engagement and confidence.

5. Failure to manage end user expectations

See points 3 and 4 above. When end users see working software every Sprint and can provide valuable feedback, they will not be disappointed.

6. Changes to requirements

See points 3, 4, and 5 above. Change is good; embrace it.

7. Lack of an effective project management methodology

Scrum is not a methodology by design. Scrum helps teams create their own adaptable process for navigating the rough waters of complexity in an empirical way where a linear and defined methodology is bound to fail. We discuss this in more detail in the next chapter.

The good news is that Scrum allows you to address most of the essential and accidental risks directly. The remaining ones can be put into a classic risk matrix (Table 5-4) and addressed at least once a Sprint.

Table 5-4 Example of a Risk Matrix

The overall risk is the combination of probability and impact. You must either make sure the risk cannot happen or is of no consequence if it does happen. Either option is described in the contingency and mitigation column. Once you can set probability or impact to zero, the risk is managed.

____________________________

1. “The Stacey Matrix,” gp-training.net, accessed February 23, 2018, http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm.

2. Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Upper Saddle River, NJ: Prentice Hall, 2002), 93.

3. Elizabeth Palermo, “Who Invented the Light Bulb?,” Live Science, August 16, 2017, http://www.livescience.com/43424-who-invented-the-light-bulb.html.

4. Bruce W. Tuckman, “Developmental Sequence in Small Groups,” Psychological Bulletin 63, no. 6 (1965): 384–99.

5. Patrick Lencioni, The Five Dysfunctions of a Team (San Francisco: Jossey-Bass, 2002).

6. David J. Snowden and Mary E. Boone, Mary E., “A Leader’s Framework for Decision Making,” Harvard Business Review, November 2007, 69–76.

7. It was called simple until January 2015.

8. Oxford Dictionaries (American English), s.v. “analysis paralysis,” accessed March 5, 2018 (“Inability to respond effectively to a situation due to an over-analytical approach or to an excess of available information.”).

9. Ben Moseley and Peter Marks, “Out of the Tar Pit” (Feb. 6, 2006), https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf (referencing Frederick P. Brooks, Jr., “No Silver Bullet—Essence and Accident in Software Engineering” [1986], http://worrydream.com/refs/Brooks-NoSilverBullet.pdf).

10. Ken Schwaber and Jeff Sutherland, The Scrum Guide (Nov. 2017), 3.

11. Tharwon Arnuphaptrairong, “Top Ten Lists of Software Project Risks: Evidence from the Literature Survey,” in Proceedings of the International MultiConference of Engineers and Computer Scientists (Hong Kong: IAENG, 2011).