Contents
The Folly of Pulling on Multiple Threads
As repeated throughout this site, once and as long as the Agile Performance Standards are being met, everything in FuSca™ is open to change. However, there are smart and not-so-smart ways to customize any business process. It’s one thing to implement a proven system of interrelated changes, and quite another to venture into the unknown by customizing that system.
Think of it as pulling a thread sticking out of a sweater. It might be loose. If not, the sweater may unravel. Even if the specific changes you want to make have been done in your company before—your exact environment, that is—they may not have been done in the specific combination you are trying, or in your team’s circumstances. So the changes may not have the same results that occurred before.
Now imagine you have several loose threads. Nobody would yank them all at once, yet I often see businesses make several independent changes at once to the same environment (as opposed, again, to adopting a system of changes—changing sweaters, so to speak). When that happens, if you get positive results, it is impossible to know which of those changes gave you that result. Worse, it is possible one of the changes had a negative result, but you don’t know that, because the positive change had a greater impact. The net change is positive, yet the results would have been better if you had only made the positive change.
A fundamental truth underlying the advance of science (and often repeated on business programs like Marketplace) is that “correlation is not causation”: The fact that measurement A moves in ways that seem reflected by measurement B does not prove that A caused B. It is possible B caused A (perhaps by starting first in ways people didn’t notice)… or another factor, C, caused both A and B… or a factor D has to be present for A to cause B… or A can only cause B in specific situation F… or specific environment G… or that the A-B link was a simple coincidence! Many managers have wasted thousands or millions of dollars because they incorrectly thought a change they tried or read about caused an effect they wanted, or that it applies to all situations. Only upon trying the change again and seeing it fail do they realize their mistake, if then.
My favorite (or saddest) example is the move back to open workspaces from cubicles. Agile pioneers recognized the value of a team-shared space to help with coordination. Unfortunately, most companies skipped right past the acknowledgement that most people also need quiet spaces for maximum productivity. In every instance of this move that I have witnessed or read about, the negative impact to individual productivity caused by the move was hidden because the company made other organizational or process changes that supported better group productivity. Because positive results occur, the company thinks the open workspaces are good. However, higher overall results would have been seen if only the org or process changes had been made. (For a detailed discussion with citations, see “The Recycled Myth of the Open Office.”)
A Surprisingly Familiar Fix
Fortunately, there is a reliable system for making incremental changes, in a way that proves them effective or not and isolates their impacts. Best of all, you already use it, whether you know that or not: It is called “the scientific method!”
Science Buddies, a site for young students, explains, “Scientists use the scientific method to search for cause and effect relationships in nature.” There are many versions of the method, but I’ll go with their simple one:
- “Ask a Question”
- “Do Background Research”
- “Construct a Hypothesis” (a possible answer to the question)
- “Test Your Hypothesis by Doing an Experiment”
- “Analyze Your Data and Draw a Conclusion”
- “Communicate Your Results”
Think about an improvement you made in the way you do your job. I bet your approach followed this method. You questioned how you could do that part of your job better or overcome a problem (#1 in the list). You probably at least poked around on the Web for a solution, or read a book, and maybe asked colleagues for suggestions (#2). You decided to try a specific change (#3) and tried it a few times (#4). You thought about whether the change worked as you hoped, and either kept the change or didn’t depending on your results (#5). Hopefully you then told somebody about the change (#6), be it a colleague who could use it—or your boss to get some credit!
Applying the Method
To be clear, under FuSca you can change processes not specified by FuSca all you want—that is part of “self-organizing.” I strongly recommend using the scientific method in those cases, too. This section illustrates how, using the scenario of customizing a FuSca practice.
Upon meeting the Agile Performance Standards, if there are things you don’t like about FuSca, decide in a Retro to change one of them. Try the change for a few sprints and see what impact that has. Want to drop estimating task hours, for example? Go for it, but only it, for at least three sprints—the minimum required to establish a mathematical trend. Now if members like the move, keep it, assuming that:
- You’re still delivering all your stories,
- Defect rates aren’t rising, and
- The change hasn’t generated more complaints than the previous approach did!
On the other hand, if problems arise, you need to go back to estimating hours. Either way, now you can experiment with one other part of FuSca.
A team need not discuss internal changes with any other team. How your team maintains the Standards is up to it, once attained.
However, changes that could possibly impact other teams or stakeholders need to be discussed with them prior to making the change. An example is dropping the three-part story statement in some cases. I have worked with teams that did just fine without all the parts, especially on technical-requirement stories. However, any story types that are requested by, shared with, or provide deliverables for other Scrum teams will probably need to retain the format unless those teams agree on forgoing it.
Certainly any changes to the program’s release planning process need to be approved by representatives of every team in the program. The Release Retrospective is the obvious forum for proposing those. A more urgent issue can be added as an agenda item in a regular release planning meeting, or you can hold an additional ad hoc meeting during the release if necessary. The ARM runs it, and TGs and Facilitators participate or send substitutes. For changes that could impact the architects, Agile Liaisons, and/or Customer, invite them, too. In most cases you could probably wait until the next Release Retro to evaluate the change and decide its future, or again, add the follow-up as an agenda item in a regular planning meeting.
I started to say you would only hurt yourself if you did not take a disciplined approach to change. The truth is, you could easily hurt your customers, managers, and stakeholders. Change FuSca the same way you implemented it, step by step, and you will continuously improve with less pain… until FuSca has evolved into your very own scaled Agile system.
⇒ Steps: Customize FuSca
↑ System | ← Initiate Agile Programs | → Agile Management