Goal Mapping

A product backlog is a queue of work. And queues aren’t something we should aspire to, rather we should have the smallest queue (or no queue) so we can get our products out quickly.

Some thoughts on backlogs from Gabrielle. Read more

Ryan Shriver's Design Class Sticky Notes, posted on a desk.

The Black Art of Sticky Notes

Gabrielle writes about some handy tips for using Sticky Notes Read more

Evolve Beyond Meetups

A few months ago, we hosted our first Evolve Beyond Meetup in London. We had a number of guest speakers, who each delivered a compact and illuminating talk (not more than 10 minutes each) on a variety of topics, but all based around lean and agile product design and development. Read more

The Value of Innovation

I’ve been reading up on the value of innovation, in preparation for the Value seminar by Tom Gilb in London this week. One question for Agile teams is how to innovate within the constant pressure of “Sprinting” and barely having time to draw breath.

Read more

We Should Run Our Products Like a Trading Floor

Imagine an investment bank running with the following scenario:

Manager:

“Hi team, we are putting in place a new process for you to help us be more predictable and control our budget and schedules over the next year. By the end of December, we want you to hand in a plan that tells us:

  • Which trades you will execute over the next year
  • What date you can deliver each trade
  • The cost for each trade, and the cost for all of the yearly trades
  • The expected revenue you will make for the whole year.

To help you, we will be monitoring the progress every few months to ensure you have made the trades you committed to, on time and on budget.

If you find that a trade is no longer worth executing, please submit a change request form and get sign-off from your manager to remove the trade. If you would like to add a make a new trade that is not on your trading plan, please fill out a separate change request form and send it to your manager. When you are trading on behalf of external clients, please ensure you also get your legal counsel to make the changes to the contract and sign-off on it before executing any new trades not covered in your annual trading plan.

Please send any comments or questions to your manager and we will endeavor to answer them in a timely fashion.

While the scenario above is clearly insane due to changing market conditions and decisions that need to be made in microseconds rather than a year in advance, do they do exactly this with their product teams?

Read more

Flames against a black background

How the Traditional Contract Model Increases the Risk of Failure

In 2007 the UK Department for Communities and Local Government (the DCLG) entered into a contract with European Air and Defence Systems (EADS, now known as Cassidian) to deliver an IT system that would underpin the FiReControl project.

The FiReControl project aimed to improve the UK Fire and Rescue Service by replacing 46 local control rooms with a network of nine purpose-built regional control centres. The project was expected to be completed in October 2009, and the DCLG’s original estimate of the project costs was £120 million. By 2009, two years into the project, the expected duration of the project had doubled, and the anticipated total project costs had increased by more than 500% to £635 million. In 2010 the contract was terminated. The DCLG had wasted at least £469 million as a result of the failure of the project to deliver.

Read more

Post Agile – Outcome Generation

I get asked “What’s next? Exactly what is ‘Post-Agile’ “? I then hear that Kanban or Lean Startup are the answers to all of our problems, along with the 200 or so new scaling Agile frameworks that have appeared on the market.

There is a tendency to jump to solutions and answers before properly understanding the problems or identifying the desired outcomes. Imposing a new process won’t deliver the right results if you’re tackling the wrong problem.

Read more

Outcome Metrics – Measure What Matters

What do you currently measure? Most metrics efforts seem to focus on the throughput or output measures.

Throughput measures tend to cover how fast you get through the work. Examples from Agile teams are things like ‘number of items completed’ or ‘total story points’ completed during an iteration. Lean teams might use cycle time, or how long it takes a similar sized item to move from the beginning of the lifecycle to when it is launched.

Output would include Lines of Code, features or function points completed.

Throughput tells us how fast we go, output tells us how much we delivered. But why are we doing any of this work? What are the problems we are trying to solve? What are the business results we desire?

Read more