Early in my career in the ’90s, I worked in a large grocery retail chain’s corporate office. This organization invested heavily in technology projects designed to reduce expenses and improve revenue. They believed quality and speed to market would improve if everyone followed a process for completing their projects.
They defined a process called system development life cycle (SDLC) based on traditional waterfall project management. Management gates were in place, so the documentation and metrics of each project were reviewable. Hundreds of projects running in parallel provided a phase status. People were part of a “resource pool” who would “roll-on” to a project, then “roll-off” after using their specialized skill. Project managers were process experts guiding everyone and everything using “out-of-the-box” enterprise tools to track and direct the projects through every step. The organization believed they had a well-tuned project delivery machine.
The truth, however, was much different. Over the years of use, as the organization observed defects or found exceptions, they added more until the process became the master, rather than the slave. They created a task force to find a way to remove the “bloat.” During the first meeting, the vice president of software development joined us with a token garbage bag, challenging us to remove unnecessary things.
The process of this organization is an example of a defined process control. Almost like an assembly line, they reasoned there was only one way to perform the necessary steps to build a product or deliver a project, so they documented them and required everyone to follow it.
Empirical process control
Later in my career, I learned about empirical process controls, which address complex problems. According to the dictionary, they are “based on, concerned with, or verifiable by observation or experience rather than theory or pure logic.”
Everyone uses empirical process controls, maybe even unknowingly. They’re natural and part of everyday activities like driving.
For example, when taking a trip in a car, you’ll observe and adapt based on experience. You’ll watch your speed, then adjust. You’ll watch the road, then adjust. Every 11 seconds or so, you’ll check your rear-view mirror, then adjust. You’ll notice the environment/weather, then acclimate. If there’s a road closure, you’ll take an alternate route. You’ll inspect and adapt throughout the entire trip. Even if you take this trip at night with a light that extends only 30 feet in front of you, careful observation and adaptation help you safely reach your destination.
Complex problems require a different approach
Think of the problems you solve every day. Which of them can be solved the same way every time? Are you dealing with the same inputs and the same desired outputs, believing the same process will get you there? (We call this defined process control.) Or do you have new problems to solve every day? Simple problems can follow a defined control approach. But how often are you solving simple problems?
Consider the construction of a larger “product,” such as a skyscraper. There are thousands of skyscrapers, yet each one is different. Building one may require some significant upfront design and planning. However, for each skyscraper, it’s the first time that a particular one is being built. It’s full of new problems to solve.
A certain flow to the work will need to be in place for it to stand strong. There’s a huge benefit in using the three pillars of empiricism, frequent inspection, and adaptation through transparency of progress, all along the way. Inspectors, architects, and builders fine-tune and amend to ensure the edifice meets code, specifications, and useability. LastPlanner is a tool for enabling empiricism in construction because of the transparency it provides for inspection and adaptation.
Transparency
With scrum, transparency means the team makes their progress, development process, events, artifacts, and product visible. They’re visible for everyone to see—the scrum team, stakeholders, and, in some cases, even customers.
Having someone ask, “What’s the status?” or “Who is working on what?” becomes unnecessary because of the team’s attention to providing full transparency. Transparency enables the team to make decisions on data, rather than fiction. With knowledge work or ideas (such as with product development), this can be particularly challenging since they’re invisible.
For this reason, aside from open invitations to their team events, scrum teams use information radiators. They display their sprint backlog, task board, and burndown chart in the center of their team room. Like a scoreboard at the center of a sports arena, the status of “winning” or “losing” is visible and inspected throughout the day, so teams can make adjustments. Other information radiators they’ll post include the product vision and roadmap, product backlog, definition of done, impediments log, and the list goes on. Even the product increment is made visible for inspection during the sprint review. Teams then make next day adjustments at sprint boundaries iteration after iteration.
The team understands that fear will cause the truth to be hidden. For this reason, psychologically safe teams value openness, respect, focus, commitment, and courage. They take these scrum values, especially openness and courage, and pull the invisible into the light. “No lying” is one of the team’s first working agreements. The second is to get “bad news early,” no matter how bad.
The expression “scrum is an exposure model” references its transparency. Facts are exposed, so they are addressable. They may have always existed, but at least with scrum, now they’re transparent, and you can take action.
Inspect and adapt
Scrum teams use inspection and adaptation frequently, too. During daily scrum, the team inspects their task board, burndown, and sprint goal, then adjusts. At sprint planning, the team inspects their sprint backlog, then adjusts based on their capacity.
Each day as the team works, they follow their definition of done, inspect through testing and product owner feedback, then adjust. During sprint reviews, stakeholders inspect the product increment, then help the team to adjust. During retrospectives, the team inspects their team and development process, then makes adjustments. Like a living organism combating a virus, they self-organize and self-manage using inspection and adaptation.
Some of the adjustments are good, and others are not so good. With trial and error, the team iteratively shifts and adjusts, seeking better customer-aligned product features, higher performance, innovation, and improved product quality. Short, transparent feedback cycles facilitate numerous opportunities for inspection and adaptation, which informs their decision-making.
Empirical process controls and agility
The agile value of “adapting to change over following a plan” and the following principles further validate how empirical process controls are central to agility:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Businesspeople and developers must work together daily throughout the project.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Complex problems benefit from empirical process controls
Taiichi Ohno, the father of the Toyota Production System, said, “Having no problems is the biggest problem of all.” In this context, he meant that an environment without full transparency has an even bigger problem of not being able to inspect or adapt.
Complex problems, such as new product development, benefit from empirical process controls. Products developed with frequent inspection, adaptation, and full transparency are certain to be successful or maybe even fail early. Agile product development fails early and often, purposefully, because of the opportunity it creates for learning. With minimal investment, they use their verifiable observations and experience to move their product from uncertainty to certainty, continually tackling the highest value, highest-risk features first.
Does your team need agile transformation support? We can help with assessments, recruiting, training, and coaching and mentoring. Explore our services today.
