Agile Project Kickoffs

I've led various project kickoffs over the years. Back in the closer-to-waterfall days, we had to introduce ourselves to each other. We could then move to the project purpose and release criteria. Now that agile teams stay together, we can change the kickoff to more project-specific work.

I wrote an article several years ago, Keys to Chartering an Agile Project. That article has the template I offered in Manage It!

In Create Your Successful Agile Project, I suggested a reframe for the charter. The question I asked was this:

How little can we do to satisfy our needs?

I don't want to do too little—in the project or in the kickoff—to be useful. I live the tension between helping the team deliver something valuable as quickly as possible vs. the ability to evolve the product as quickly as possible.

Many new-to-agile-thinking teams want everything defined upfront. I help them see we can use iterative and incremental thinking on everything for the project.

Here are my assumptions:

• The team has already created some working agreements in the past.
• The team uses those working agreements and knows how to change them, if necessary.

If the team has not worked together in the past, I offer a couple of options:

• Spend a one-hour timebox (or less) to draft working agreements and plan to revisit the agreements in a week or earlier.
• See how they work and perform little kaizens every day for about 15 minutes to refine how they work.

I'm not a big fan of creating working agreements before you do any work. I do like to revisit and refine (that inspect and adapt thing!) the working agreements when the team and the work changes.

Kickoff Activities

That said, here's how I've facilitated what I'll call “agile” kickoffs in the past:

• Write the project vision as a team so we know the purpose and where we're headed.
• Write the release criteria as a team so we know when we're done.
• Verify that we know the constraints, drivers, and floats for our project, so we know how to make tradeoffs.

These are all part of the project charter. I tend to timebox the charter to 60-90 minutes. We don't need to be perfect. We need to know who the product is for, what our first deliverables might be, and when we're done. We can iterate on this, too.

You might need more than that. I've also included these activities, again as a team. I tend to timebox these activities, too. Think 30-60 minutes for each of these:

• Create a risk list. I often ask this question, “What will we do when we realize we don't have enough test automation to know the state of the product after each build?”
• Start architecture thinking. I ask the team to create either several low-cost/small spikes/prototypes/experiments so we can learn, or start a paper vision of the architecture.

We now know where we're headed in terms of who our users are, what success looks like, and what done means. We might be done. We might need one more thing: the stories for the first backlog.

Write Stories as a Team

Some people advocate the PO generating the initial backlog of stories. I used to advocate that. I don't any longer.

I now recommend that as soon as the team has spent an hour or so in kickoff (maybe two hours if you do everything here), that they work as a team to create that first backlog of stories. How many stories? Six to ten.

If the team uses iterations, and they have a shot of finishing one story a day, ten stories is enough. If the team uses flow, they might only need six or seven stories.

When the team has to collaborate to define the working skeleton or the first valuable work, they learn a lot more about their working agreements and their possible risks than they could possibly learn by thinking about those agreements or risks.

Charter as a Team

When agile teams charter their work, they are more likely to create their successful agile project. The more collaborative the kickoff, the more likely the team will continue that way.

I have also seen teams succeed when the PO brought their product/project vision to the team and the team workshopped that vision for their project.

Do let me know if you have used other activities for your agile project kickoffs. I find the frame of “how little” thinking helps me a lot here.