January 21, 2015

We Need Planning; Do We Need Estimation?

By Johanna Rothman

As I write the program management book, I am struck by how difficult it is to estimate large chunks of work.

In Essays on Estimation and Manage It!, I recommend several approaches to estimation, each of which include showing that there is no one absolute date for a project or a program.

What can you do? Here are some options:

  1. Plan to replan. Decide how much to invest in the project or program for now. See (as in demo) the project/program progress. Decide how much longer you want to invest in the project or program.
  2. Work to a target date. A target date works best if you work iteratively and incrementally. If you have internal releases often, you can see project/program progress and replan. (If you use a waterfall approach, you are not likely to meet the target with all the features you want and defects you don’t want. If you work iteratively and incrementally, you refine the plan as you approach the target. Notice I said refine the plan, not the estimate.
  3. Provide a 3-point estimate: possible, likely, and worst case. This is PERT estimation.
  4. Provide a percentage confidence with your estimate. You think you can release near a certain date. What is your percentage confidence in that date? This works best with replanning, so you can update your percentage confidence.

Each of these shows your estimation audience you have uncertainty. The larger the project or program, the more you want to show uncertainty.

If you are agile, you may not need to estimate at all. I have managed many projects and programs over the years. No one asked me for a cost or schedule estimate. I received targets. Sometimes, those targets were so optimistic, I had to do a gross estimate to explain why we could not meet that date.

However, I am not convinced anything more than a gross estimate is useful. I am convinced an agile roadmap, building incrementally, seeing progress, and deciding what to do next are good ideas.

Agile Roadmap When you see this roadmap, you can see how we have planned for an internal release each month.

With internal releases, everyone can see the project or program progress.

In addition, we have a quarterly external release. Now, your project or program might not be able to release to your customers every quarter. But, that should be a business decision, not a decision you make because you can’t release. If you are not agile, you might not be able to meet a quarterly release. But, I’m assuming you are agile.

Agile Roadmap, One Quarter at a time In the one-quarter view, you can see the Minimum Viable Products.

You might need to replace MVPs with MIFS, Minimum Indispensable Feature Sets, especially at the beginning.

If you always make stories so small that you can count them, instead of estimate them, you will be close. You won’t spend time estimating instead of developing product, especially at the beginning.

You know the least about the risks and gotchas at the beginning of a project or program. You might not even know much about your MIFS or MVPs. However, if you can release something for customer consumption, you can get the feedback you need.

Feedback is what will tell you:

  • Are these stories too big to count? If so, any estimate you create will be wrong.
  • Are we delivering useful work? If so, the organization will continue to invest.
  • Are we working on the most valuable work, right now? What is valuable will change during the project/program. Sometimes, you realize this feature (set) is less useful than another. Sometimes you realize you’re done.
  • Are we ready to stop? If we met the release criteria early, that’s great. If we are not ready to release, what more do we have to do?

Here’s my experience with estimation. If you provide an estimate, managers won’t believe you. They pressure you to “do more with less,” or some such nonsense. They say things such as, “If we cut out testing, you can go faster, right?” (The answer to that question is, “NO. The less technical debt we have or create, the faster we can go.”)

However, you do need the planning of roadmaps and backlogs. If you don’t have a roadmap that shows people something like what they can expect when, they think you’re faking. You need to replan the roadmap, because what the teams deliver won’t be everything the product owner wanted. That’s okay. Getting feedback about what the teams can do early is great.

There are two questions you want to ask people who ask for estimates:

  1. How much would you like to invest in this project/program before we stop?
  2. How valuable is this project/program to you?

If you work on the most valuable project/program, why are you estimating it? You need to understand how much the organization wants to invest before you stop. If you’re not working on the most valuable project/program, you still want to know how much the organization wants to invest. Or, you need a target date. With a target date, you can release parts iteratively and incrementally until you meet the target.

This is risk management for estimation and replanning. Yes, I am a fan of #noestimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.

We need planning and replanning. I am not convinced we need detailed estimation if we use iterative and incremental approaches.

January 21, 2015 01:37 PM

January 19, 2015

Discovering Your Leadership Posted

By Johanna Rothman

I published a new Pragmatic Manager this past weekend. It’s called Discovering Your Leadership.

It has a pointer to the Influential Agile Leader event that Gil Broza and I are leading in San Francisco and then in London. You can still get early bird pricing, until Feb 15. Don’t miss this opportunity—we’re only leading it twice this year.

January 19, 2015 06:01 PM

January 13, 2015

Does Agile Apply to Your Project?

By Johanna Rothman

I have a new column posted at projectmanagement.com. It’s called Does Agile Apply to Your Project? (You might need a free registration.)

 

January 13, 2015 01:49 PM

January 12, 2015

Does Agile Work Because We are Optimistic?

By Johanna Rothman

I read the Business Week opening remarks, How Optimism Strengthens Economies.  See this quote at the end:

the group of people who turn out to be most accurate about predicting how long it will take to complete tasks—and how likely they are to succeed—are the clinically depressed. Optimists underestimate how difficult it will be to succeed. But that self-deception is precisely what makes them willing to take more risks and invest in a better future, while the pessimists slouch toward self-fulfilling failure. 

Pessimistic people are more accurate with their estimation. Optimists underestimate. Their optimism allows them to take more risks and innovate. Which kind of person are you? (I’m both, in different circumstances.)

That got me thinking about why agile works.

Agile and lean (I’m using agile as shorthand for both) help us make progress in small chunks. That creates hope and optimism in the project team. When the project team demos or releases to other people, they trust the team and a become hopeful and optimistic.

We know from The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work that the more we make progress with small wins, the better we feel and the more likely we are to make more progress. That leads to hope and optimism.

Is this why agile works? Because we can make progress daily?

It’s not the only reason. We also need feedback. When we provide demos to other people, as often as possible, we build trust. With trust comes the possibility of better connection and feedback.

We get feature-itis because we’re no longer in requirements hell. Other people can see that a project team can deliver. That leads to optimism and hope in the organization. (I’m differentiating the two, because they are different. See my review of Seligman’s book.) With hope, people can rise to many occasions. Without hope? I bet you’ve been there on a project. It isn’t pretty.

Agile is not for everyone. Agile approaches? Yes. Completing small chunks of work and showing it to other people? You can do that with deliverable-based planning, building incrementally, and iterative approaches to replanning. If you want a name for that approach, it’s called staged delivery or design to schedule.

If you’re doing agile well, you’re delivering new small features into the code base every day or every other day. That helps you feel as if you’re making progress. When you feel as if you’re making progress, you can be more optimistic or hopeful. That helps you see new possibilities.

I would rather work in a hopeful way, making progress on a project, than feel as if I’m dragging. What about you?

So, agile might increase optimism, which allows us to make more progress and innovate. Agile done well brings joy to our work.

People are always asking my why agile works, or to prove it works. I can’t prove anything.

I have said that in my experience, when people work in an agile way, they are more productive and more effective. Now I wonder if this is because they are optimistic and hopeful about their work.

January 12, 2015 01:50 PM