Subscribe via RSS Feed

Tag: "on-time"

The 3 Great Interrupters: Meetings, Management and Drive-Bys

interruptors-300x199Recently, we’ve introduced Commitment Based Estimation  to a couple of our software teams. Typically, this helps a team provide highly-accurate estimates. These teams go on to deliver successfully by meeting these estimates.

The Attitude of Estimation

The-Attitude-of-EstimationOver the past three or four blog posts, I tried to challenge our thinking on estimation by sharing some specific ideas on why padding an estimate is evil or how a SWAG can actually be fairly accurate.

Now I want to take a step back and share the biggest obstacle any organization has to getting consistent estimates. By that I mean estimates that drive confidence for the team and it’s stakeholders. That obstacle is our attitude towards estimates.

To clearly share what I mean by our attitude, let me share a typical estimation experience:

Experiencing the Attitudes of Estimation…

I am working with a new team and walking them through some standard use cases or agile stories. I present the first feature, the team evaluates it, and give me their initial estimates.

One person on our team, let’s call her Ann, quickly throws out “This should be about two days”.  Another senior member of the team, let’s call him Jerry, says: “I can’t imagine that taking more than a couple of hours”.

I ask Ann, “Why do you think this is two days”? She responds: “Well if I say a day and there are defects etc, it’s going to take longer. The truth is I don’t know whether this is one day or three days – but this is only an estimate. No matter what I say it’s going to be off, and you’ll be unhappy”.

After defending myself and saying “That’s not true, yada yada yada”, I then turn to Jerry asking why he thinks this is only a couple of hours. He responds, “How hard can this one be? It’s a straight forward screen. I just have to get a new table built with the reference codes and we are good to go. I don’t see any challenges”.

One of Jerry’s teammates asks: “Isn’t it going to take some time to download the reference codes, clean them up and get them in the table? And shouldn’t we create some quick automated tests to make sure this works?” Jerry pauses and says: “Well I guess. If you want to include all that then I need a full half day”.

Finally Ann jumps in and shares: “If you ask me, I think you should estimate a full day. We’re going to need the QA team to sign off and by the time you do any adjustments, it might take you all day”.

Jerry doesn’t necessarily agree, but the team agrees it’s better to be safe then be sorry.

Why These Attitudes Make Sense…

I regularly find both attitudes on the same team across companies, sectors and experience levels. I understand both approaches. I can defend them!

Ann is right. No matter what we estimate, it’s going to be wrong. That is why we are estimating and not “predicting”. In fact, I’d even argue “weather forecasting” should be called “weather estimating”. Forecasting suggests we are truly predicting. Estimation suggests based on what we know and the models we are using, here is our best guess.

And Jerry also isn’t wrong in saying he knows that it will take two hours. He genuinely believes for the feature at hand, he can get this out quickly. However, the team quickly reminds him that there are other “tasks” and “team members” that need to be included in his estimate.

Commitment Based Estimates

Having different attitudes and approaches to estimation is a clear obstacle to getting consistent estimates that can be managed and adjusted. To remove this obstacle, I suggest having a standard approach or attitude to estimation. I call this approach: Commitment Based Estimates.

When asking for estimates, I want the team to understand, I am not asking for the smallest, leanest, quickest estimate for each task. If I did, this optimistic plan would simply be impossible to deliver on. It won’t take one small thing into account: LIFE.

I also don’t want them to pad estimates and not be realistic.

So I ask them to think about it from the point of view of “commitments”. When can you commit that this feature will be “done/done/done”? When do you believe it will be ready for deployment to our integration test environment?

I then clarify: That means you have to take into consideration any “clarification” of requirements, obtaining resources such as a tables, test data, web services, tools, conversion scripts, documentation and so forth. It also means you have done your testing and are comfortable that this actually works. You are proud of the result.

In our previous example, the team compromised and said this would take a full day to finish our feature. I might test this by asking the team: “Would you bet your paycheck on this? In other words, are you truly committing to that one day estimate”?

In the real word, if we are working on something that we said takes a day, and it ends up taking an extra 45 minutes, we would typically do what it takes to get it done on schedule. That is the nature of development teams. We truly want to deliver on expectations if “we own them”.

I could write another page or two on Commitment Based Estimation, but I won’t (yay)! I will leave you with these other thoughts:

  • Never force an estimate on the team. If you are doing Commitment Based Estimation, the team needs to feel full ownership for the creation and development of their commitment.
  • I highly recommend all estimates be in ½ day increments. More specifically, NOT in hours. If I say I am going to be done in 6.5 hours, am I actually going to get another .5 or 1.5 hours worth of work on my next task done? Stick with ½ day, full day,  three days or five days etc…
  • If your estimate is longer than a week or so, I’d challenge the team to split the work into two tasks and estimate them separately. (There may be some exceptions to this one.)

The Goal: Consistency

Regardless of whether you agree with Commitment Based Estimates, it’s important to get the team to have a common attitude to estimating as much as a common approach. I hope you give Commitment Based Estimating a try. I have found a great deal of success with it.

I’d be very interested in hearing your experiences with “attitudes” towards estimation and why you believe this approach will or will not work with your team. Please leave your comments below!

As always, please feel free to share this post with anyone you think might benefit.

Beyond Complete: Success is Making a Lasting Positive Impact

What is “success” to you? Imagine yourself working on a project. The project is on-time and on-budget. All of the requirements have been met. But, how successful have you been with the project? Have you made a lasting impact with your customers? Are they eager to work with you on the next project? Are they recommending your work to others?

Reaching the Destination May Require an Unexpected Route

A customer engagement is not just about meeting the common standard measurements of success (on-time, on-budget, etc.), but is about partnering with your customers to predictably deliver what is needed for them to be successful in their business. It is about anticipating what the customer needs. It is about the courage to deliver a difficult message when you discover that the recommended solution is not going to deliver the desired results, even if you fear that you’ll be perceived as having made a mistake. And, it is about being flexible in your approach so you resolve issues instead of worrying about meeting a plan that you know is not working.

One of the most successful projects that I’ve worked on was neither “on-time” nor “on-budget” and the final delivered solution was significantly different than what was requested in the original requirements. Yet, the project was considered a success – the customer was extremely happy with the results and continued to engage with my company and team for additional work.

127385974_4c9b5e3acf_mFulfilling a True Need

What made this project successful?  Our team partnered with the customer to understand what the true needs of the project were. In the middle of the project, we determined that while we could deliver to the original commitments, the solution that the customer would have received would not have met the customer’s needs. Instead of continuing to deliver to the flawed plan, the team alerted the customer to the issues and worked with them to restructure the plan to deliver a solution that better met their needs.

Was the re-planning painful? Of course it was. As more information was uncovered, we actually restructured the project and the sub-teams twice during the project life cycle. So, in addition to keeping the client satisfied, there were also challenges in keeping the team focused and delivering quality. However, the end result was worth the pain in the middle of the project. The final solution delivered the value that the customer needed within the necessary time frame. The team was able to celebrate a successful delivery.

If we had stuck to the original plan, the team could have delivered the project on-time and on-budget. We would have met all the requirements of the project. It is even possible that we could have gotten future work from the customer. However, the customer’s perception of us would have been just another consulting company that they could use for work if needed.

Instead, by not delivering on-time or on-budget, but by predictably delivering value with “no surprises”, we became a trusted advisor to our customer and they became enthusiastic advocates of our company and our people.

What does “no surprises” mean to you? When have you changed the course resulting in a win for all?

Photo Credit: Olivier Bareau