Six Steps to Pass the Agile Test
--
I discussed the ‘Agile Test,’ my term for the opportunities we get to apply inspect-and-adapt to improve our processes and practices when faced with problems and impediments, in an earlier article (“Are You Failing the Agile Test?”). In this article I’ll provide a detailed approach to applying inspect-and-adapt to your problems, what I call ‘The Six Steps,’ and then show you how to utilize this approach with a real-life example.
A Six-Step Approach to Applying Inspect-and-Adapt to Process
We have to begin with the proper mindset. First, you must stop accepting problems as essential and unavoidable. Instead, assume that all problems are accidental and completely preventable, but only if you change your processes and practices to break the chain of events that leads to these problems.
Follow these Six Steps to find and fix your problems:
1. Create a Problem Statement Describing the Undesirable Effects
2. Find the Problem Using a Root-Cause Analysis Technique
3. Define the Problem Explicitly
4. Define the Solution and Success Criteria
5. Run the Experiment to Validate or Disprove the Results
6. Incorporate Your Learning
One of the reasons we fail the Agile Test is because we neglect to connect cause and effect. We devise a solution that does not address the problem, perhaps because we feel this solution is something we can do, something within our sphere of control. Or perhaps because we have heard that others have adopted this solution and seen some success. Too often, we don’t take the time to see if their solution is right for us and our environment. At the risk of pointing out the obvious, a solution to a problem that doesn’t solve the problem is not a solution. Instead, we need to step back and first perform some root cause analysis.
1. Create a Problem Statement Describing the Undesirable Effects
Note that most of the time, what we initially identify as a problem is really not the problem. It’s a rephrasing of a solution as the problem. Here’s an example: a team struggling to hit its sprint goals might say the following: “We failed to achieve our sprint goals because our stories are too big.” The solution to this problem statement is simple: make stories smaller. Is that the real solution? I’ve seen teams go down this road until they have a lot of very small stories, tasks, really, and yet they still don’t achieve their sprint goals.
Using UDEs
A better way to write problem statements, as popularized by Dr. Eliyahu Goldratt, the visionary who came up with the Theory of Constraints, is as Undesirable Effects, or UDEs. Think of UDEs as the pain we feel, the consequences of problems instead of the disguised solution. We might rephrase the problem statement above as, “We fail to achieve our sprint goals and thus cannot be confident of delivery dates.” As an aside, some in the Agile community might say that there’s no problem here, that it is impossible to set reasonable expectations around delivery dates in an uncertain world, so the solution is, just don’t do it. How well will that work within your organization? How would you accept hearing, “I don’t know how long it’s going to take or how much it will cost, or what I’ll even deliver,” from your auto mechanic or your kitchen remodeling contractor? In the hundreds of organizations I’ve engaged with, and in the organizations I worked and held leadership positions at, that simply wasn’t an acceptable answer.[1]
2. Find the Problem Using a Root-Cause Analysis Technique (The Five Whys)
Now we have a problem statement as a UDE it’s time for a little root cause analysis. I’m going to use a simple root cause analysis technique called The Five Whys. It’s a problem analysis technique invented by Sakichi Toyoda, a man known in Japan as “the King of Japanese Inventors” and the founder of what became the Toyota Group. Five Whys is based on the principle that the first answer is usually not the correct answer, that we must go deeper to discover the true problem. To demonstrate how I might use the Five Whys, I’m going to engage in a hypothetical dialog based upon a real customer, coach to team.
The first question to ask is always, “What problem are we trying to solve?” We already have an example with our hypothetical UDE, above. The second question to ask is, why?
Coach: “Why is the team not meeting their sprint goal?”
Team: “Because our stories are too large!”
Coach: “How do you know they’re too large?”
Team: “Because we’re not meeting our sprint goal.”
Coach: “That’s circular reasoning. Why are these stories preventing you from meeting your sprint goal?”
Team: “Because we couldn’t get the story tested by the end of the sprint. We finish coding our stories a couple of days before the end of the sprint and the testers are swamped and cannot get the tests written and finished in time.”
Coach: “Why couldn’t you get the stories ready to be tested before the end of the sprint?”
Team: “Because we always wait for code reviews before checking in our code to be tested, and these always seem to take a couple of days.”
Coach: “Why do code reviews take a couple of days? These should be shorter, right?”
Team: “Well, yes, the review itself takes about 30 minutes. But another developer has to perform the review. He’ll usually catch it the next day, find a few issues, send his review back to the original developer for fixing. Occasionally, there’s a disagreement and email goes back and forth until the issue is resolved and the code can be checked in. So, it’s at least a day and often up to two days.”
Coach: “Why does the code review not get picked up and started until the next day?”
Team: “Come on, John! Developers aren’t sitting there. They are working on their own tasks and will get to the review when they have time.”
Now we have some information, and none of it points to making stories smaller as an effective solution. Can you think of a solution? I want you to think about what we’ve learned in this discussion, what the problem might actually be, and what solution you might propose. Feel free to pause for a moment and write down what you think the problem might be, and how you might address it. Don’t worry about being detailed, just a sentence on what you think the problem is, another on what you think might be a viable solution, and a third sentence describing what success would look like… how you could tell your solution is effective. Then we’ll see if your problem, and your solution, is similar to mine.[2]
3. Define the Problem Explicitly
Let me describe the problem we’ve focused in on. Code reviews that should take no more than an hour are taking anywhere from one to two elapsed days, and as a result stories are finishing late in the sprint, which reduces the time available to fully test the code. This is one reason that the team is struggling to achieve its sprint goal; be mindful there may be others. Note that this problem statement provides an elapsed duration and an ideal time. What do I mean? Elapsed duration is how long something actually takes, while ideal time is how long something should take absent impediments. The team has acknowledged that the ideal time for a code review should be an hour, or under.[3] The team has also stated that the elapsed duration for code reviews ranges from more than one elapsed day to two elapsed days, and sometimes more. Something to note: any time there’s a large ratio between ideal time and elapsed duration, you can be sure that there’s a problem. This is an important concept, so feel free to take a few second to give yourself time to think about this, and to understand it.
4. Define the Solution and Success Criteria
Based upon our problem definition, any valid solution to the problem of excessive elapsed duration for code reviews must reduce the elapsed duration significantly, must reduce the ratio, ideally to where the elapsed duration is the ideal time. How can we do that? By using principles to derive policies as the foundation for a valid solution.
Using Principles to Help Design Solutions
I often bring in principles from Lean, the Kanban Method, and Theory of Constraints into my process consulting, and I’m going to do so here. One of the Kanban Method’s principles is to Manage Flow, to manage the flow of work across the value stream in order to provide the highest value as quickly as possible. We manage flow by implementing policies, rules that control the priority and order of work, based on Classes of Services, which is an attribute associating a work item with specific policy guidelines on how we prioritize and order work items. This is similar to how airlines board passengers, the work items in the boarding workflow, using policies; who gets to board and in what order based upon their class of service… elite status, ticket class, challenges or disabilities.
As you know, sprint backlog items have been prioritized by the product owner. If we have three items, A, B, and C, listed alphabetically as their order of priority, then that order communicates the product owner’s ranking of A as more important than B, and B than C. Accordingly, if we can only get any one of these three items completed during the sprint, it had better be A. Thus, we would show A at the top of our sprint backlog followed by B and then C. If we’re using a sprint board, whether it’s a physical board complete with sticky notes for items and subtasks, or a virtual board, the sprint board gives us a picture of our workflow with work moving from its initial state on the left to its final state on the right side of the board.
The ‘Topmost-Rightmost’ Principle
I’m going to use a principle that I call ‘topmost-rightmost’ to describe the order and priority of work in our sprint’s workflow. ‘Topmost-rightmost’ guides us to focus on the most important thing, and to do the work needed to push it to completion. We can use it to generate some helpful practices. For instance, if we have remaining work on A, then any developer with availability and sufficient technical knowledge should work on A instead of moving on to B or C, regardless of the type of task. Even if it’s a testing task, and there are coding tasks for B and C, the developer should perform the testing task on A if she possibly can. The same is true of a review; if a developer could review code for A or start coding on B, she should review code for A. Do you see how this approach will get A done as quickly as possible, perhaps at the expense of B, and B done as quickly as possible, perhaps at the expense of C? How, even if these are the same size, it’s better to get all of A done than one-third of A, B, and C by the end of the sprint, because 100% of one item always beats 33% of three items?
A Policy to Expedite Code Reviews Based On ‘Topmost-Rightmost’
We can take this policy and extend it in the case of code reviews. If we want to reduce the elapsed duration of code reviews by reducing the latency of the current approach, we must ensure reviews don’t linger. One way to do this is by having developers look for pending code reviews at the start of the day, and after they return from lunch. If there is a code review, it needs to start then. Also, any developer with code needing a review has to be standing by, ready to participate in the code review at the time the reviewer wants, either physically or virtually. Why these times? Because work has been naturally interrupted, and so there is little impact on the reviewer or the developer to perform reviews at this time. And, by having the reviewer and developer together, issues can be discussed and resolved in real time, without the latency of back-and-forth emails. Think about it… a simple policy change that drastically reduces elapsed durations of code reviews to no more than 4 work hours after the request was made. Without negative impacts to our people, adding resources, or delaying other work unnecessarily.
Define Success Criteria To Assess Effectiveness
We have a policy but we’re still not done. How do we determine whether this policy is successful? By stating the desired future state as success criteria: Code reviews take less than 4 elapsed hours in most cases, never more than 8 elapsed hours. Clear, objective, quantified, measurable.
5. Run the Experiment and Validate or Disprove the Results
This simple change might seem theoretical, but I first implemented it at my own organization well over a decade ago based upon a similar root cause analysis, and at numerous clients who had the same problem without any policies in place covering timeliness of code reviews, and it has made a significant difference, more so than the teams originally envisioned. Would it work in your environment if you have a similar problem? There’s only one way to find out, right?
6. Incorporate Your Learning
What if it works? Great! The process, policy, and/or practice changes you’ve made now become part of the way things are done henceforth. Make it so.
What if it doesn’t work? You’ll know because you won’t achieve your success criteria. Take heart, failure simply means that you haven’t fully identified the problem. This is another opportunity to learn! Go back through the process. Some things to validate:
· Did you hit on a valid problem definition (Step 3)?
· Does your solution actually address the problem you identified (Steps 4 and 5)?
· Is the problem you identified really what is stopping you from your initial goal?
Summary
We’ve brought up a lot of topics in this article… workflows, value streams, the Kanban Method, using principles to help derive effective practices, root cause analysis, problem statements… even how understanding the difference between utilization and productivity can drive focus and limit WIP so that we start less and finish more. These are all interesting and valuable topics that can and will be unpacked and discussed in detail in future articles or webcasts.
George Orwell wrote, “To see what is in front of one’s nose is a constant struggle.” That is the struggle of the Agile Test, to see what is in front of us, to ask why instead of accepting why not, to change what isn’t working instead of enduring it. Passing the Agile Test is simple, but not easy. It takes courage and integrity, and leadership. And it is essential for success. Remember the steps to pass:
1. Create a Problem Statement Describing the Undesirable Effects
2. Find the Problem Using a Root-Cause Analysis Technique
3. Define the Problem Explicitly
4. Define the Solution and Success Criteria
5. Run the Experiment to Validate or Disprove the Results
6. Incorporate Your Learning
What we’ve done is to map specific actions to the Deming Cycle: Plan (Steps 1–4), Do/Check (Step 5), Act (Step 6).
Go Forth and Prosper
Find it within you to pass your Agile Tests, and if you’re a leader, to encourage and support your teams and your people as they face their own Agile Tests. You really can’t do the wrong thing as long as you’re facing your problems, asking why, doing something differently for an understood reason, and then examining the results to learn and improve. This is really inspect and adapt at its core, the Scientific Method, empiricism in action, and all progress depends on it. Don’t settle for less than what you can achieve. Don’t fail the Agile Test. Adapt, improvise, overcome. You can do it.
_____
[1]We’ll talk about this concept of insisting that predictability is both impossible and useless for software development in a later article.
[2] This doesn’t mean my solution will be right, for you, or that yours is wrong. There are many different ways to solve this problem, some of which are equally valid. Such is the nature of stochastic work.
[3]We’re not going to worry about times that are less than an hour because that is an excessive level of detail indicating we’re getting into the weeds.
