I like my plans. I have several levels of plans: a year or so specifically for books and workshops, a 6-month roadmap so I stay on track or change my track, a one-month week-by-week proposed roadmap, and a weekly plan. I use a kanban board to manage my weekly plans. (See Why I Use a Paper Kanban Board for the series I wrote on the blog.)
I often change my weekly plans. I have the same problems as I've heard from many of you: interruptions I want to service more often than once a week. I also realize that I could stop after this deliverable and do more valuable work. That's one of the reasons I use flow-based roadmaps. (See Alternatives for Agile and Lean Roadmapping: Part 3, Flow-Based Roadmapping for the explanation and images.)
I find the planning valuable. The plans themselves? Not so much. That's because what's valuable at any given moment might change.
Trudy, an agile project manager, discovered the same thing. Her team was supposed to work in two-week iterations. By definition, they were supposed to _finish_ their work in the two-week timebox. They rarely did. Why? Because something more valuable came along during the iteration that the product owner, Cecile, wanted them to do.
Cecile didn't change the roadmaps—she changed the order of the work in the roadmaps. Trudy asked the team if they would consider flow instead of iterations, with the same two-week cadence of planning. The team was thrilled to be able to pull work instead of trying to commit. They decided to discuss stories more often to manage that change.
Cecile (with a little prompting from Trudy) decided to use a flow-based approach to the roadmapping. Cecile would work with the product manager on the plans. Trudy would work with the managers who wanted commitments and defined work.
That's when the real work started. The managers had not defined the value of each project (a given release of a product). The product manager had not thought about ending the projects to move to another product's project. The company had not considered how to make their strategic decisions about what they wanted to release and when.
Planning in the large can help you understand what your strategic intent is. You then create a project portfolio that implements your strategic intent.
Roadmapping, especially the longer roadmaps, can help you see when you might receive value from the different releases and when you might complete a project. Agile approaches might help you finish a project “early.” Not because it's less work, but because the value in this product's backlog is less than other project's backlogs.
Planning and the discussion around those big-picture plans is invaluable. The plans themselves? Not so much. The plans for the immediate future? Again invaluable. Those small plans help keep projects focused to deliver the promised value.
As you think about your plans, consider what plans help you with strategic intent and tactical progress towards that strategy. As Eisenhower said, “… plans are useless, but planning is indispensable.”
My new book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver is in beta. We are in the last stage of copyediting and layout. I wrote the book so you can decide about your agile approach, for your team and your context.
Look for writing and product owner workshops announcements in the next few weeks. I am busy recording the lessons so I can focus on working with you, not teaching in our meetings.
Are you new to the Pragmatic Manager newsletter? See previous issues.
Till next time,
Tags: Create Your Successful Agile Project, kanban, project management, roadmap, rolling wave planning