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|
adj.
1. A look ahead
noun
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 - before starting a large Agile project

Question Backlog.jpg

In my classes, I often ask participants to create a question "backlog" of the things they would like to have addressed before the end of the class. The participants write questions, prioritize them, and decide when a question has been satisfactorily addressed. As the trainer, I determine whether a question is in or out of scope and facilitate discussion. Sometimes, toward the end of class, I'll ask the question's author to share with the class the answer they have learned.

In a recent class, a participant wrote, "What are the top 5 things that must be done in the 12 months before embarking on a large Agile project?" You may be thinking, "But Jim, you wrote '4 things...' in the title of this post. For those of you that have been reading these "4 things" posts, you know by now that I never stop at just 4. ;)

By the end of the second day of the class, without a specific, targeted discussion around this question, the question's author put together this poster from various related discussions that gave him insights for a possible answer.

Top 5 Activities.jpg

Top  5 activities to prepare for flagship Agile Product

  1. Educate the team/stakeholders of the benefits & expectations of the change
  2. Create a Meta team [a team to focus on the change initiative associated with the Agile adoption]
  3. Pilot 1 small product
  4. Create Product Backlog/Release Plan
  5. Choose the right Product Owner

 

 

Note that the list implies a faster start than 12 months with an experimental pilot to accelerate learning. Also, note the shift from an "project" to a "product".

Not a bad list. What would you include in your top 5?

Advice for Starting Your Agile Project

In their new book, Liftoff: Launching Agile Teams and Projects, Diana Larsen and Ainsley Nies partner to address an often neglected aspect of an Agile project — the start. Getting the start right is a critical step in enabling the overall success of the project. Diana and Ainsley share helpful insights on the elements of a successful launch including pragmatic guidance for planning, designing, running, and improving your launch process (the latter draws on lessons from Esther Derby and Diana Larsen’s excellent retrospectives book, Agile Retrospectives: Making Good Teams Great.)

In addition, a significant portion of the book addresses Agile Chartering. In fact, Diana and Ainsley debated writing a book exclusively on this topic as they deem it so critical to the success of Agile projects. Instead, they have integrated a chartering discussion and charting model into their Liftoff framework. Their decision makes for a better book, in my opinion.

While there are a lot of good examples, checklists, and stories, Diana and Ainsley emphasize the values and principles behind the ample practical advice they give throughout the book.  In this vein, they stay true to the Agile principle expressed in the Agile Manifesto, "Individuals and interactions over processes and tools."

Full disclosure: I’m a contributor to the book, so I may be a bit biased, but I think Diana and Ainsley’s contribution to the Agile canon will ultimately result in better agile projects and better business results. Anyone who is thinking about or getting ready to start an Agile project should check out Liftoff .

(And, if you get a chance, flip to pages 76-79 and give me some feedback on my story, “A Tale of Two Projects.”)