An argument for a look ahead

Photo by Andy Reynolds/DigitalVision / Getty Images

Retrospectives are great, no doubt about it. Retrospectives, along with the experiences that we are retrospecting, are the fuel for our future improvement. But what about when we are just starting out? Is there a place for a retrospective before we begin?

By definition, retrospectives are a look back. When we are just starting out, we don't have a back to look at. We only have our way forward. But which way forward... and how forward? Even with agile and its short iterations, we typically wait to retrospect until the end of a iteration. (I know we don't have to wait until the end, but that is the way it is normally played.)

What if we started with a something like a retrospective at the beginning? Only we couldn't call it a retrospective because it wouldn't be a look back now, would it? What if we started with a "prespective", a before look, a sort of "look before you leap" or "begin with the end in mind"? What difference might a prespective make?

Before diving into the possibilities, let's define prespective.

Prespective |prē'-spĕk'tĭv|
1. A look ahead
1. An forward-looking activity in which future possibilities are considered with intent to influence focus or direction

Sounds a bit like a kickoff or a launch doesn't it? However, kickoffs or launches tend to focus on the thing that we're creating rather than the process by which we will create it. Instead of looking at the what, a prespective would look exclusively at the how, and as we do with the what, we also ask the question "why?" In fact, the question "why" is at the root of both what and how, if you think about it.

Now, there might be an objection here that good kickoffs do include the consideration of how and why. But seriously, when was the last time you experienced a truly good kickoff?... and one where there was an intentional pause to consider improvements to current process before the start? This part is key. It must be intentional and a pause, not just lip service or a jumping on the bandwagon of the latest improvement fad.

We are talking about the gap between where you are and where you want to be with your process -- your how. The prespective is a serious consideration of the improvements that you wish to see and why those improvements are important.

Knowing why facilitates buy-in

Now, to what difference a prespective might make... if you know why the improvements are important, it becomes easier to get buy-in from stakeholders. Stakeholder buy-in to the reason for a change is key to successful change. 

Vision creates focus

Knowing the reason for a change also makes it possible to paint a vision of a better future that will result from the change. This vision creates focus for the team.

Defining success helps us to know when we’ve reached the goal

A vision also helps in defining success. The definition of success answers the question, "How will we know when we've got there?"

Metrics facilitate inspection

A definition of success also helps in identification of meaningful metrics to measure progress toward and ultimate realization of the vision.

At its core, a prespective simplifies the problem space. By identifying a strategic improvement target, the prespective narrows the possible solution sets. The constraints on the problem space actually makes it easier for the team to construct experiments for improvement. In other words, guided by the prespective, the team designs experiments intended to move the needle in the right direction.

Hypotheses can be wrong!

Now for a word of caution: always remember that a prespective results in a hypothesis based on a perceived improvement opportunity. The perception of the "right" improvement target is colored by past experience, beliefs, bias, preferences... after all, the hypothesis is created by people, who by their nature, are imperfect. If we were perfect, we would already have an optimal process. So, the hypothesis might be... wrong!

Learning loops enable new hypotheses

Given that we might have picked the wrong target, we now need to make sure our process includes a couple of learning loops — one that assesses the impact of our experiment in process improvement on the intended target... and a second loop to reconsider the validity of the target hypothesis. These looks at the results of our experiments?... yes, you've got it, these looks are what we call... retrospectives. And so we begin. Are you ready?

4 things - avoiding the Agile death march

4 things - avoiding the Agile death march

Agile initiatives can have a surprisingly short run. At first everything seems rosy, but as soon as the going gets tough, the experiment is history. In "Unintended Consequences -- the Agile death march" I told the sad story of a team demoralized and stricken with "delight withdrawal". It got so bad that team members were resigning. The abandonment of Agile by the organization was the next likely step. But did it need to be so? What might have been done differently to avoid such a messy outcome?...

Read More

Unintended Consequences - The Agile Death March

Unintended Consequences - The Agile Death March

In project management, the phrase "death march" refers to the demoralizing experience people assigned to a doomed project have just prior to and during its death throes. Agile teams generally avoid this type of death march by surfacing risk early and appropriately adjusting course. However, there is another type of death march that Agile teams can experience, and this Agile death march can prove equally if not more damaging to the organization than the type experienced by non-Agile teams...

Read More

Less is More

With sequestration and furloughs a reality and demand for services still high, organizations are dealing with the question of how to do more with less. I submit that how to do more with less may not be the right question. Instead of doing more with less, perhaps the right question is how to do less. In a world of tightening budgets and forced reduction in staff, we don't have the option to do more. Pushing more demand onto a smaller capacity only slows things down. Take, for example, road maintenance on a multi-lane highway that requires shutting down one or more lanes of traffic. The remaining lanes have to take on the amount of traffic that the previous larger number of lanes handled. Inevitably, traffic backs up. It takes longer for each vehicle to reach its destination. The backup happens even though no additional vehicles have been added to the road.

Now, add more vehicles. The backup gets even worse. Little's Law predicts this outcome. The only ways to eliminate the backup are to increase capacity, reduce the amount of time each vehicle spends on the constricted section of the road, or limit the arrival rate of vehicles.

Increasing capacity often requires an increased investment, for example, adding temporary lanes to replace the lanes taken out of service. In this road construction example, reducing the amount of time a vehicle spends on the constricted section of the road has limits constrained by physics and safety. Limiting the arrival rate could be manipulated by offering options, such as a detour around the affected section, or an informational campaign that encourages drivers to avoid the area during peak usage times.

Now, think of your projects as if they were vehicles approaching this construction zone. Though, instead of a construction zone, the projects are entering a delivery process that is constrained by budget cutbacks. Just like there are fewer lanes to support the vehicles in the construction zone, there are fewer people, teams, and infrastructure to support the arriving projects in your delivery system. The reduced capacity also impacts the projects that are already in process. If you don't want to increase cycle time, that is, the time it takes a project to be completed, you must do something. According to Little's Law, there are only 3 options: 1) Increase capacity, 2) Improve flow, or 3)Limit the arrival rate.

Given sequestration, increasing capacity may not be an option.¹ Improving flow can be achieved by adopting Agile practices that speed up the delivery process. This solution is analogous to reducing the amount of time a vehicle spends in the construction zone. If the cycle time increases to an unsatisfactory level despite flow improvements, the only remaining option is to limit the arrival rate of projects.

Which projects to do and which to delay or put off altogether is a portfolio management problem. Little's Law and Pareto are useful techniques for analyzing this problem, but the ultimate goal is to pick which projects generate the greatest return and focus on those.  Directing the limited capacity of the organization at a smaller set of high value work is not "doing more with less," but rather doing the right work, at the right time, within capacity constraints, which is, by the way, what we probably should have been doing all along. Sometimes it takes a crisis, like sequestration, to force the issue into action. So, this is an opportunity to do the right thing.  Don't waste it.

¹Depending the organization's business model it may be opportunistic to increase capacity at a time when others must cut back, but that is a topic for another day.

Succeeding with Scrum

It's been said that Scrum is "what we already do when our back is against the wall." That should make it easy, but reality is that it can be hard to admit that we're in a tough spot. Absent a "fight or flight" stimulus, it can be hard to get traction, and without traction, success may be just a mirage. A first step in getting started with Scrum successfully is the existence of a problem. The problem provides the fuel or energy that will sustain us when the going gets hard.

In addition to the problem, there needs to be someone who authentically owns the problem. Feeling responsible for solving the problem is not enough. The problem needs an authentic owner who cares about solving the problem.

When I'm brought in to coach a team in the use of Scrum, I start by asking 2 questions:

  • What is the problem you are trying to solve?
  • Who owns the problem?

The picture to the left shows a progressive model to discover answers to these questions. Starting at the bottom is the problem. Next, there's the admitting that the problem exists. This step is non-trivial. Too often, I find teams adopting Scrum as a solution in search of a problem. Have no doubt, Scrum will surface problems; but we want to start with the main problem we're trying to solve.

After admitting that there is a problem, further discussion and analysis may be required to identify the "real" problem. Often, the expressed problem is just a symptom, or worse, a solution dressed up as a problem. Some root cause analysis such as the five whys technique developed by Sakichi Toyoda can be helpful in uncovering the real problem.

Once the problem has been identified, the client decides if the problem is worth solving. There is always a cost with solving a problem. We want to make sure the benefit of solving the problem will outweigh its cost and that it is the right and timely thing to do.

Next, does the scope of the problem fall within the client's sphere of control or influence. Is the client empowered to solve the problem?

Finally, the key question:  Do you think we can solve the problem?  If we've progressed up this model and the answer to the last question is yes, then we proceed.  Along the way, we have built up trust and understanding, both of which will serve us well on the journey ahead.  Knowing the problem we are trying to solve and that we have the problem owner onboard are the first steps to success.