• Search in book...
• Toggle Font Controls

EMPIRICISM

QUIZ

To set the stage for this chapter, try answering each of the following statements with Agree or Disagree. Answers appear at the end of the chapter.

 Statement Agree Disagree Agile practices are best suited for simpler products such as websites. If you have the right people and they take enough time to analyze a complex problem, they can accurately predict all the variables. The most efficient way to approach a simple problem is to continuously inspect and adapt. Taking risks is a good thing when working on complex problems. Each time a working Increment is developed and inspected, the complexity is reduced.

IT’SA COMPLEX PROBLEM

Assume you are responsible for keeping a conference room at a constant 70°F/21°C from 9 a.m. to 5 p.m. There is no thermostat in the room and no way for you to read and adjust the temperature throughout the day. The building manager insists that you provide all the variables that could possibly affect the temperature each morning by 9 a.m. These variables will then be entered into a master heating/cooling system to control the room’s temperature throughout the day.

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

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 transparencyinspectionadaptation 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.

CERTAINTY QUIZ

To measure the uncertainty of your environment, take the following quiz.

Our team . . .

 is very senior is very junior is stable, changing about once a year is constantly changing or is part time considers one another true friends “just” works together has the necessary technical skills to deliver successfully needs to acquire new technical skills to deliver successfully has complete control over infrastructure and tooling solutions has no control over tooling and infrastructure needs has built the same technical solution before is building a solution that nobody in the world has built before has access to industry leaders in our business domain is brand new to the domain and must come up with functionality on its own is working in an established domain that rarely changes is working in a volatile and emerging domain that changes constantly has a customer who knows exactly what she wants has a customer whose real needs become clearer as he sees the product progress

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.1

VISUALIZING COMPLEXITY

In the modified Stacey graph (see Figure 5-1),2 the x-axis displays the certainty about the technology you are planning to use. How certain are you that it will work as planned? Toward the left side, you are very certain, probably based on past experience. The more you move to the right, the less certain you become. The extreme right side could indicate that you need to develop new technology with many challenges along the way. It took Edison 3,000 different designs and two years to finally produce an incandescent light bulb.3 This invention had a tremendous degree of complexity.

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.

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-Performing4 phases? Does trust exist? One of the most important ingredients for high-performing teams is trust—without it, no effective team behavior will emerge.5

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.

CYNEFIN

Dave Snowden, a researcher on complexity theory and knowledge management, created the Cynefin6 framework in 1999 while working for IBM. Cynefin has five domains: obvious7 and complicated on the right-hand side, complex and chaos on the left-hand side. A fifth domain—disorder—is reserved for when the domain is unclear.

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.

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

 Categorization Model Sense-Making Model Framework precedes data.You need to find the fit for the data and therefore categorize into an existing framework. Data precedes framework.You collect data and learn whether you are operating in an ordered domain or in an unordered domain. In the unordered domain you need to identify the agents influencing the system so that you can steer.

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

OBVIOUS

Cooking is a perfect example for simple work. You decide what you would like to eat, and you shop, slice, dice, fry, and stir as described by the instructions. As long as you are capable of following the given set of instructions, you will be successful. Usually, the recipe tells you the preparation and cooking time upfront. You operate with known-knowns. The approach is sense-categorize-respond, which is repeatable for anyone who can follow the instructions. Therefore, in the obvious domain are best practices (see Figure 5-4).

COMPLICATED

Now let’s build a house, a two-story one-family home. You know how to do it; there are professions for this type of work: architects, structural engineers, civil engineers, to name a few.

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

Where I live in Switzerland, many houses are built on steep hillsides, requiring reinforced and anchored foundations. Before moving to Switzerland, I lived in Silicon Valley, where each of my rented houses was built for earthquakes.

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.

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.

COMPLEX

If building a house is complicated, what about building an airport? There are many airports in the world, but because of their magnitude and inconceivable number of dependencies, it is unrealistic to plan everything upfront in detail. Many situations unfold as progress is made, requiring changes to the plan as you go. A contracted company goes bankrupt, poured concrete has the wrong chemical composition requiring additional metal reinforcement which then blocks a chute. These changes often have a tremendous impact, requiring adaptation of the plan as you execute it. Complexity is best described as the domain with the unknown-unknowns, which calls for a probe-sense-respond approach (see Figure 5-5).

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.

I like to arrange four tables for the four domains and then have my team place each high-level requirement (often use cases) in each of those domains. I learned this exercise from Dave Snowden himself. Not everything we have to do will be complex. There will be simple, complicated, and complex items. The simple ones only mean work, nothing to worry about. The complicated ones, we need to make sure that we analyze them correctly. We could use pair work, reviews, or other practices. For all the complex ones, we need to figure out what to do first to gather enough information so that we can plan to do it.

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.

CHAOS

In chaos, the behavior is act-sense-respond without any relationship between cause and effect as there are no constraints. It is the unknowable-unknowables. Imagine a group of strangers thrown into a situation where they had no experience or skill to cope, like a natural disaster. Whatever they decide to do would be done once and likely never repeated. These are referred to as novel practices.

PUTTING IT ALL TOGETHER

There are essentially two approaches to “manage” a product. The approach you choose depends on the predictive nature of what you are producing. On one end of the spectrum is ordered (obvious and complicated) and on the other is unordered (complex and chaos).

Ordered

Imagine that you are an experienced contractor who has built hundreds of single-family homes.

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.

Unordered

Imagine you are organizing a team of doctors in an emergency room.

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.”8

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

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

TYPES OF COMPLEXITY

Complexity is your reality. Consider two types: essential complexity and accidental complexity.9

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.

From the Scrum Guide

Scrum is a framework for developing, delivering, and sustaining complex products.10

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.

MANAGING RISK

No product development endeavor will ever be without risks. Risks are interesting as they can be both good and bad.

I like to show a short TED talk by Tim Harford, “Trial, Error and the God Complex,” in my Management 3.0 classes. Tim explains the importance of taking risks and subsequent learning—what he calls making “good mistakes.”

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!”

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.”

If there’s no risk on your next project, do not do it.

—Tom de Marco

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:

PM-BOK (Project Management Body of Knowledge) defines risk as: “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” . . . PRINCE2, the UK government sponsored project management standard[,] defines risk as: “uncertainty of outcome.”11

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

 Dimension Total Frequency User 14 Requirements 17 Complexity 4 Planning and Control 27 Team 9 Organizational Environment 9 Total 80

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

 Risk Item Frequency 1. Misunderstanding of requirements (Requirements) 5 2. Lack of top management commitment and support (Organizational Environment) 5 3. Lack of adequate user involvement (User) 4 4. Failure to gain user commitment (User) 3 5. Failure to manage end user expectations (User) 3 6. Changes to requirements (Requirements) 3 7. Lack of an effective project management methodology (Planning and Control) 3

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.

A late change in requirements is a competitive advantage.

—Mary Poppendieck

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

 Risk Status Notes Probability Impact Contingency Mitigation High Risk Red Description High High Workaround plan How to make risk go away or bearable Medium Risk Amber ... High Middle ... ... Medium Risk Amber ... Middle High ... ... Low Risk Green ... Low High ... ... Low Risk Green ... High Low ... ...

Overall Risk = Probability × Impact

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.

QUIZ REVIEW

Compare your answers from the beginning of the chapter to the ones below. Now that you have read the chapter, would you change any of your answers? Do you agree with the answers below?

 Statement Agree Disagree Agile practices are best suited for simpler products such as websites. If you have the right people and they take enough time to analyze a complex problem, they can accurately predict all the variables. The most efficient way to approach a simple problem is to continuously inspect and adapt. Taking risks is a good thing when working on complex problems. Each time a working Increment is developed and inspected, the complexity is reduced.

____________________________

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

• No Comment
..................Content has been hidden....................