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?

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.

5 Hints to Being a Better ScrumMaster

Great ScrumMasters, like their teams, never stop getting better. How do they do it? Here are 5 things great ScrumMasters do:

  1. Listen - Great ScrumMasters listen and watch what is going on. Through observation, they are better informed to help their team. They "go to the gemba" to learn what their team needs.
  2. Container Hierarchy
  3. Focus - Great ScrumMasters use focus to create containers for action. The hierarchy of containers starts with vision, followed by strategy, and finally execution. Each level of container further constrains action. Containers serve to focus action on what matters most. It is within these containers that creativity thrives.
  4. Intersection of Vision and Acceptance
  5. Practice Pragmatism - Great ScrumMasters understand the intersection between vision and acceptance.  Through patience and persistence, they grow the intersection.
  6. Look Beyond the Team - Great ScrumMasters strive to optimize globally rather than locally. The team is only part of the value stream. Improving the team doesn't matter if the customer doesn't see a difference.
  7. Grow - Great ScrumMasters never stop growing and learning. They read, network and continuously build their skills.

The Virtue of Small



"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry One of the tricks that makes Agile work is keeping things small.  In practice, small may be the "secret sauce" in Agile.

Small releases, small iterations, small teams, small queues, small user stories (the "S" in the "INVEST" acronym) -- Small is good.  Small is beautiful.


One of the tricks to keeping things small is Pareto. Also known as the 80/20 rule, the Pareto Principle basically states that 80% of the effect comes from 20% of the cause.

To see how the Pareto Principle applies in Agile, consider a feature. Most of the value of a feature is in the happy path, the default scenario. The happy path is the scenario where everything works as intended with no missteps. The edge cases or exception paths carry different values, but none are likely to trump the happy path -- not by a long shot. Quality specifications inform the value of  edge cases, and quality specifications may dictate that some edge cases are essential for a production release. Regardless, the happy path is where most of the value lies.  Very likely the 80% value or "effect" is in the happy path.

Product Owners can break a complex user story into multiple smaller stories by separating the happy path and the exception cases into separate user stories with each story representing a unique and distinct path through the feature. The order of these stories in the product backlog would be the happy path first, followed by the next highest value exception path scenario, and so on.

Since product backlogs almost always contain more than one feature, the stories associated with one feature would almost always be interleaved with stories from other features. The Pareto Principle tells us that the value in the subsequent stories after the happy path story starts to fall off at a very rapid rate. The diminishing returns of these exception path stories means that, at some point, the value of the happy path of a "lower" value feature might exceed the value of the next "not yet started" exception path story of a "higher" value feature.

In this way, the Product Owner plays a value optimization game, sequencing the items in the product backlog by comparing exception paths of one story to happy paths of others. As stories are completed or "done," the Product Owner determines readiness for production by considering the appropriate level of quality required for the features to be deployed.

The Macro is in the Micro

The applicability of the Pareto Principle doesn't stop at a user stories and the product backlog. It applies equally well at the product portfolio level.  The Pareto Principle shows us how small is beautiful. In truth, less is more.

The Widening Gap

Basic Burndown

Basic Burndown

In "Minding the Gap," I wrote about a gap growing steadily over 3 sprints between the initial release plan and the reality that unfolds over those 3 sprints.  The first picture in that post is shown below.

In the "Minding the Gap" post, it may not have been readily evident how the gap was growing and how it would have been revealed in earlier versions of the release burnup.  In this post, I will show how the gap grows over the 3 sprints as revealed by the release burnup chart.  Here is the release burnup as it would have appeared at the end of sprint 1:

Release Plan Sprint 1

Release Plan Sprint 1

At this point the gap is tiny.  At the current velocity, the release plan falls short by only 5 points at sprint 5, the planned release date.  The barely perceptable gap is revealed most clearly in this chart by the position of the red triangle, representing the Projected Release Date, relative to the blue triangle, representing the Planned Release Date.  This tiny gap is the early warning that things are not going according to plan.  The next picture shows the release burnup at the end of sprint 2:

Release Plan Sprint 2

Release Plan Sprint 2

At the end of sprint 2, a lower velocity shifts the projection of completed points far to the right on the sprint timeline.  The gap has grown to 29 points.  Moving on to sprint 3:

Release Plan Sprint 3

Release Plan Sprint 3

By the end of sprint 3 the gap is greater still.  Despite a higher velocity in sprint 3, an increase in a number of total points planned for the release pushes the project release date even further to the left.  The gap between the release target and the projected number of completed points is now 34 points.  Unless a change is made to the plan or impediments stifling the team's velocity are removed, current reality will trump the plan.