I know it’s a bit harsh to insult you in the title of this post, but the odds are, you really stink at estimation. Even if you know you’re bad at it, you’re probably even worse than you think.

Don’t take it so personally – I’m certainly not saying I’m perfect at it either! But you’re among friends here, so let’s have an honest discussion.

While you will never be perfect at estimation (it is after little more than prediction of the future), you can get better at building and communicating estimates if you remember a few key reasons why you’re so bad at it. You’re still human after all, and so I guarantee you will fall into some of these traps.

Reason #1: You’re doing it alone

Too often, estimates are done alone. Typical scenarios include one person (such as the team lead) estimating an entire project, or a project manager going to a specific developer and asking them for an estimate. One person giving an estimate by themselves is one of the most unreliable ways to give an estimate, because there is no one to check you against common biases. And since all initial estimates tend to be very optimistic, you are almost guaranteed to set unrealistic expectations.

Reason #2: You’re doing it for others

When the team lead gives an estimate on behalf of their team, several problems ensue. First, you are relying solely on the judgment of one person (the team lead), and no matter how smart that person thinks they are, they are susceptible to biases when they go it alone. Second, when the rest of the team is told what the estimate for the project is, they had no voice in it, and therefore, they have no sense of ownership in that estimate. A lack of ownership means they will have no sense of accountability, and they will not go the extra mile to stick to the estimate.

Reason #3: You’re being way too optimistic

Very few of us give pessimistic estimates. For one reason, we want to please the customer. When they say they want something in two weeks, we make mental leaps in how we will build the software to try and get them what they want. Or we discount the likelihood of obstacles, and hope for the best case scenario.

Reason #4: You think you’re an expert

There’s a great chapter in the book “The Black Swan” about the problems with predictions, and one problem described is “the expert problem.” Studies have shown that experts tend to underestimate their own margins of error on predictions, because they are overconfident in their expert status. As software developers, we fall into this trap regularly when we say things like “oh yeah, that will be easy, I’ve done something similar before.” When we do remember that task last time was not as easy as we thought it would be, we often discount those obstacles we encountered as outliers. We assume that “now that we know how to do it”, we won’t encounter those obstacles again, and no other obstacles will arise. We are usually wrong.

Reason #5: You’re using single point estimates

Using single point estimates makes all of these previous reasons worse. Single point estimates encourage you to go with your gut and the first number you think of, or the number that the customer wants to hear. Think how ridiculous it would be someone asked you “How long does it take to get to your house?”, and you answered “Oh, about 25.6735 minutes”. By including all those extra decimal points, you are creating a false impression of accuracy. Single point estimates are the same idea. If I say “it takes 25 minutes to get home”, then you will expect to be there in exactly 25 minutes. But what about traffic, or other variables? A more accurate answer is to say that it takes “25-30 minutes, depending on traffic.”

A solution to estimation biases: Range estimation in Scrum Poker

Using a range instead offers a lot of benefits. By saying “that will take me 2-5 days” instead of “I can get that to you in two days”, you are communicating the uncertainty that is inherent in all software development. The size of the range you provide communicates risk. And it prepares the customer for a more realistic schedule, instead of setting you up for failure when they expect completion on the most optimistic schedule possible.

Combining range estimation with the Agile practices of team estimation is doubly effective. In Agile teams we often play “Scrum Poker.” I’ll avoid the long description of it here, but in short, each team member gets a deck of cards. When you are estimating a story or a task, each team member privately chooses a card (or range of cards) from their deck. When everyone has chosen, they all show their cards at the same time.

Showing the cards at the same time combats a number of the reasons I list above, because you get a true sense of the variety of estimates across the team without introducing the biases of the team lead or architect. Those who picked the lowest or highest estimates are not discounted as outliers, but encouraged to describe to the team why they chose that number. This encourages the team to discuss the idea until they have reached a common vision for the complexity of that story or task.

Agile team estimation is great, but one big problem I still have with it is the reliance on single point estimates. That’s why we use range estimation in our Scrum Poker at OpenSource Connections, and we find it to be more effective. By holding two cards instead of one, each team member is indicating a range estimate and communicating lot more about the risk and complexity that they see in that project.

Next Tuesday (August 10th, from 11am-noon in room Asia5) I’ll be presenting at the Agile 2010 conference on “Building a More Accurate Burndown: Using Range Estimation in Scrum”. If you’re going to be in Orlando, I hope you’ll stop by to hear more! You can also see my slides on slideshare.

Arin Sime is a Senior Consultant with OpenSource Connections, specializing in Agile process consulting, Solr search, and development consulting. You can follow Arin’s tweets at ArinSime

I’m looking forward to speaking next Tuesday night at AgileCville about range estimation in Scrum. It’s been a while since I’ve been able to attend AgileCville meetings regularly, so I’m excited to reconnect with everyone. I hope to see you there!

AgileCville
Date: Tuesday, June 15th, 2010
Time: 6 PM to 7:30 PM
Venue: OpenSpace
455 Second Street SE, Suite 100
Charlottesville, VA 22902

Everybody loves employees and consultants who can get stuff done. Especially if you’ve made a commitment to a client or your boss, it can be very difficult to ask for an extension to that timeline. It’s much easier to ask your team to put in the extra hours to get the job done, even if that means the job won’t be done well. Sometimes leaders will even resort to claiming the product is “done”, when it was never truly done at all, and needs a lot more work.

Your development team will likely respond to your calls with heroic effort. And you might actually make the deadline. But if you do it regularly, your reputation as a leader may actually suffer, and your team will probably burn out unless you can pour on enough accolades and spot-bonuses.

At some point, almost all IT leaders, including myself, have done it. That is unfortunately not much of a secret and it’s why IT teams often develop a bad reputation. The bigger secret is that a lot of developers not only regularly take on the hero role, they actually like it.

This creates a dangerous situation, where IT leaders ask for heroic efforts because it is the path of least resistance. And the development teams respond with grumbles and late nights, but also with the misconception of job security and the expectation that they will receive a lot of praise when they come in on Monday bleary-eyed (but with at least part of the job done).

Why is there so much danger in encouraging your developers to be heroes? Do a google search on “cowboy coders” or “programmer heroes” and you’ll see other blog posts that describe the whys and the pitfalls of reliance on hero development. In short, you’ll get inconsistent and buggy code that may not fit your architecture, won’t meet the customer’s needs, is not very flexible, creates technical debt you will complain about for years, and will probably need to be reworked eventually.

So how do you avoid heroes? As a CIO or technical lead, the tools of Agile offer many solutions:

• Sprint planning – restricting the work that is done to the current sprint helps discourage sudden changes of priority. Most tasks can in reality wait until the next sprint to be added, especially if the customer understands that it means the current sprint has to be put on hold or canceled.
• Daily standups and regular customer interaction – Chronic hero programmers often like to hideaway on their work, and so they can be more easily detected when you are interacting with the customer each day. There is less opportunity for the developer to hide away and not give status updates, and the standups provide the customer more immediate feedback on everything that is being held up because they sent the hero on a distracting quest.
• Team estimation – When the team estimates tasks for a sprint together, before they are assigned to people, that encourages open discussion and debate on how long something will take.
• Continuous Integration – Maintaining rules about daily code check-ins and regular integration and unit testing prevents the hero from going too far away from the mainstream code base, and gives visible signs of progress. When done properly, it also helps to reduce the bugs delivered in the rushed code.

In addition, in our OpenApproach implementation of Agile and Scrum, we use range estimation of tasks. Asking people to give you a single-point estimate of how long something will take encourages them to be overly optimistic. “Oh, I can get that done in about 2 hours.”

Really? What if it’s not as simple as you or the developer thought? Then the only solution is to put in a heroic effort if the timeline must be met.

A simple range estimate will provide a much more realistic view, and encourages a more thorough thought process: “It should only take about 2 hours of actual coding, but I’ll have to switch projects and get that site running again on my machine. Plus, sometimes those java script issues can be really though to debug, so it could take as long as 8 hours of work.”

As an Agile CIO, it’s your job to not only be understanding of your developers when they give you a range estimate, but encourage it. Don’t settle for the heroic answer of “I’ll just put in some extra time this weekend.” Get to the root cause of the problems, and make sure the customer or your boss is aware of the delays earlier rather than later. It will make all of your lives easier, and help you to avoid the pitfalls of programmer heroes.

The Agile CIO is a series of blog posts advising IT leaders on how best to incorporate Agile techniques into their organizations. For more information about OpenSource Connections’ Agile process consulting services, please contact the author at ASime@OpenSourceConnections.com.

I am looking forward to presenting at Agile 2010 this year, and I was very pleased to find out that my session proposal on Range Estimation in Scrum has been accepted. Here is info about the session, and I hope to see you at the conference in August!

Building a More Accurate Burndown: Using Range Estimation in Scrum

Traditional Scrum burndowns are based on single point estimates of how long a task will take. However, single point estimates are inherently faulty and inaccurate, and they encourage underestimation. Learn how to incorporate range based estimation techniques into your Scrum burndown, and better communicate to your boss or clients what a project is really going to take. Arin will back up this thesis with academic and industry research, real world examples, and an engaging presentation style. Participants will leave with concrete tips & templates for using range estimates in their projects.

Process/Mechanics

The first part of the session will focus on the pitfalls of traditional estimation techniques, in particular single point estimates. This will involve audience interaction as well as citing industry and academic research. Next the session will move into a discussion of range estimation and how that leads to better accuracy. Then I will present specific advice for how to use range estimates in common Scrum practices like Scrum poker and the burndown. Along the way I will show examples of how our company has been using this practice with clients over the last year, and some best practices that have come out of it. The techniques will be fairly simple and easy to adopt, but provide power results in estimating more accurately and better communication with managers and clients.

Potential pitfalls and best practices of range estimation will also be discussed. For example, some managers are reluctant to accept range estimates, but they can be convinced when a demonstration is made to them of how it better communicates risk and allows them to make better financial decisions on the viability of a project.

This topic started for me with a paper I wrote in my Masters in Management of IT program in 2009 at the University of Virginia, and now has become regular practice at OpenSource Connections. I am also pursuing further research on the topic with two professors from the University of Virginia (Professors Ryan Nelson and Mike Morris of the McIntire School of Commerce). Any preliminary findings or papers from that research will also be woven into the presentation.

I have proposed this as a 60 minute talk, but it could also be made into a 90 minute Tutorial with relative ease. In that scenario, I would bring more hands on activities to encourage participants to really see the value of range estimation in their projects. I have experience with those types of sessions from helping to teach corporate education classes at Virginia Commonwealth University, and I would use that experience to make sure things are kept interesting.

It’s my intention for this session to take the relatively easy-to-use but underutilized practice of range estimation, and make it so compelling that participants will want to apply it right away on their projects. This will be done through a combination of good research, real world examples, engaging presentation style, and practical tips.

Learning outcomes

* Why single point estimates lead to underestimation
* Why range estimation reduces natural biases
* How range estimates better communicate a project’s impact
* How to use range estimation in Scrum Poker
* How to incorporate range estimates into a Scrum burndown
* How range estimates impact project decision making

For those registered on the Agile 2010 site, you can also see this session here.

This past Monday, OSC had a company hackathon day. It is not our first, but we have been trying to make this sort of activity a more regular thing for us. Unlike our previous hackathons, this one was more flexible on the rules. Previously we had the entire team work on the same technology or goal whereas this time was more free form. We each had the opportunity to work on either a new or old technology (by new and old I mean something we’ve worked with before or not), on new or old projects and to collaborate or work individually.

The day featured work on things like Google App Engine and the Android application platform. I took this chance to get myself out of the PHP world I’ve been stuck in for about a year now and get back into some Rails development. I had a little tool in mind that I wanted to develop which would help us internally do some things a bit more efficiently. I used that as an excuse to try out some of the Rails plugins or gems that I have wanted to use for a while, which are:

• Mocha (http://github.com/mislav/rspec-rails-mocha http://mocha.rubyforge.org/)
• Factory Girl (http://github.com/thoughtbot/factory_girl)
• GChart (http://github.com/jbarnette/gchart)
• Open Flash Chart (http://github.com/pullmonkey/open_flash_chart)

I have to say, the buzz around Mocha and Factory Girl is very old and I wish I had the opportunity to use these tools before now. New things come out everyday and it is tough to keep up with everything. My advise to you is to dedicate a “playing time” often for you to try out the newest and greatest thing that comes out. Do this in groups where each one can be working on a different things and share your findings at the end of the day. Even though I didn’t work on the Android app, I did get a feel for it from Arin through his experience with it. One of the things that helped take this experience further is our presence all together in one conference room feeding out of each other.

Looking forward to the next OSC hackathon.

Why do we need to sell Agile?

For those of us who know and love Agile, the benefits of Agile seem obvious.  It can be frustrating when someone doesn’t inherently see those benefits, and we sometimes forget that we need to sell our clients or our managers on our process.

For some perspective on the gut reaction many people have to Agile, consider the following quote.  John Zachman penned a famous paper on software architecture design in the 1980′s, where he said:

“Some kind of structure (or architecture) is imperative because decentralization without structure is chaos.” – J.A. Zachman, 1987, “A framework for information systems architecture”

As practitioners of Agile, we need to remember that someone’s first reaction may be that we are engaging in chaos, and so we need to consider beforehands the needs of our client or manager and how we can convince them to follow a better process.

In this post, I will briefly present 12 techniques for selling a traditional client on an Agile project plan.  This post is based on a talk I gave at Agile 2009 and to a number of other user groups, and which you can see on Slideshare here.

As part of preparing this presentation, I created a survey of fellow grad students in UVa’s MSMIT program and other colleagues in the field.  I asked them how they have sold Agile or been sold on Agile.  Not everyone who answered the survey was a fan of agile and many of their quotes are interesting.

You can see the survey yourself here, and add your own feedback to it:
http://www.tinyurl.com/SellingAgileSurvey/

Those who answered the survey are all experienced IT veterans who have worked for a wide range of organizations, including Booz Allen Hamilton, SAIC, Capitol One, the International Monetary Fund, Fannie Mae, Freddie Mac, and more.

First, a couple of general comments from the survey that I found interesting:

“Agile seems to carry the connotation of ‘codelike-hell’ or just, ‘work faster’.”

“I am skeptical of any methods that that could be interpreted as ‘cutting corners’”

These are common first impressions of Agile, and I hope the following 12 techniques will give you ideas how to convince your clients or managers that Agile is the way to go and their first impressions are not accurate.  These techniques are based on a survey of current literature, my own consulting experiences at OpenSource Connections, and the feedback I received from the survey mentioned above.

1. Trial by Sprint

“You need to show a success to get adoption.”

Consider giving your boss an option.  Ask them to give you a sprint or two to try Agile out, and if they don’t like it, then you will go back to the old ways of doing things.  Make sure that you pick tasks for those trial sprints which can be successfully accomplished, and will show your boss the value of the incremental delivery of Agile.  You should also encourage your boss to play a role in the daily standups and see how communication in your team improves.

2.  Case Studies in Success

Do some research on similar companies to yours, and what methodologies they are using.  By googling around online, you should be able to find some case studies on Agile success and present those to your boss.

3.  Client Testimonials

For consultants, make sure you go back to your clients after a project and interview them.  Ask them how your process worked, and gather some quotes you can use in future proposals or client discussions.  I did this for one of our recent projects, and the customer gave us some great feedback like:

“Certainly one of the most successful projects ever here … Scrum eliminated my biases of what developers could do by letting them self-select.”

4. Find a Champion

One approach is to let others do the selling for you.  This is particularly useful for consultants who already have a relationship with a client, and you can let some of the clients’ employees talk about how they want you to use Scrum.  Or, as one of my classmates did, he became the internal champion for Agile:

“I highlighted the benefits to the Project Manager: higher productivity and less team management stuff since the team will take care of lots of team-management and updating (burn charts) instead of PM’s managing those details.”

Basically, identify a stakeholder in the project who is most in need of the benefits of Agile, and enlist their support to help you sell management on the use of Agile.

5. Use Metrics of Success

Many traditional clients like their current methods because they provide metrics that they can graph and look at.  They don’t always immediately understand how they can measure a project using methodology without a lot of documents.

But Agile has its own metrics too, and perhaps you can use those to sway the client.  Consider presenting them with information on velocity, story points completed vs waiting, test coverage, unit test success, etc.  Some Agile tools will provide these in pretty reports, but you can also fashion them yourself.  And don’t forget to show them the benefits of the burndown chart if you’re using Scrum, and emphasize how this gives them a real time view into the health of a sprint without encumbering the developers with lots of reporting.

6. Show how Agile combats common IT failures

One of my professors, Ryan Nelson, has been running a study of project retrospectives over the last 10 years, and has published articles in MIS Quarterly Executive detailing the Top Classic Mistakes in IT projects.  The top 3 are consistently:  Poor estimation and scheduling, Ineffective Stakeholder Management, and Insufficient Risk Management.  Agile can be used to address all those classic mistakes.

Consider why projects normally fail in your organization, and present the ways that Agile combats those common failures.

7. Examples of government/industry leaders using Agile

As one of my classmates pointed out:

“Clients, especially the military, are wary of catch phrases and sometimes unwilling to change their habits.”

If your client or boss fits that description, then you need to convince them they are not the first to try Agile, and that it has been used elsewhere successfully.  Try to find examples of their peers in industry or government using Agile, and point to them as an example.

One example you can use is my previous blog post about the CIA using Agile and Scrum.

8. Comparison to other methodologies

Compare how Agile/Scrum work compared to areas that your client or boss is already familiar with.  Try to point out both the similarities and the differences.  For example, one of my classmates took the following approach:

“I gave an overview of the Scrum process and highlighted the ease of transition since iterative/incremental development has been in practice for a long time (in other forms such as a spiral approach)”

9.  Listen to their needs and address them.

“I am always skeptical of anything that promises it is the ‘only’ or the ‘best’ [methodology].” – Comment from a development manager

Instead of going into the meeting and kicking off the discussion with your rant on why Agile is the best development methodology, take time to listen to your client or manager first.

Ask them how their projects have been going, what challenges they face, and take notes on their common problems.  Then suggest how Agile will address some of these issues.

The key here is to spend most of your time listening, and only then talk up the benefits of Agile.  This will assure your audience that you have heard their concerns, and that you are trying to present positive solutions to their problems.  This can be much more effective than trying to force a methodology on them.

10.  Sneak it in

This is a very common approach, and one that I have done before too.  One of my classmates is a technology program manager, and they commented that:

“I make sure I utilize agile practices where ever I can – I just don’t use the agile terminology.”

The point here is not to be deceptive, it’s just that sometimes you don’t need the sign off from the boss to do something.  After you successfully conclude your project, you can then point out to your boss that “by the way, all that stuff we did that really impressed you – that was Agile.”  Now that they have a positive impression and have witnessed some success, you can work on letting them formally adopt the process.

Note that doing this might require you to temporarily also fill out the same reports or status updates your current process requires, but hopefully you can get those dropped after having showed the benefits of Agile.

11.  Compromise

An agile purist may not like the idea of compromising, but I found the following sentiment to be pretty common:

“The methodology that has worked in my experience has been to incrementally introduce Agile … Start using a limited set of the practices and gradually start bringing in more.”

Similar to the “Sneak it in” approach, this can be done with or without your boss’s knowledge.

12.  Agile Project Management Office

One other thought to consider is setting up an Agile Project Management Office, or PMO.  A traditional PMO is a very document and regulation intense group, but some Agile practitioners have started to promote the idea of a lighter weight PMO.  An Agile PMO focuses less on micro managing teams, and more on providing an interface to traditional processes.  The Agile PMO can help Agile development teams by taking ownership of any burdensome compliance requirements which go against Agile processes.  This allows the developers to concentrate on developing code how they want, and not filling out checklists of documents.

They can also serve as an educator and coach to the client.

Conclusion

There are many variants on the above ideas, but I hope this quick list has given you some direction on different strategies you can use for convincing people to adopt Agile.  Keep in mind that each of these strategies has pros and cons, and you should consider the needs of your situation before adopting any particular strategy.

If you have other suggestions, please leave a comment and I look forward to hearing your feedback!

I’m very pleased to be speaking to Richmond SPIN (Software Process Improvement Network) next Wednesday October 14th, at 6:00 pm at Anthem BCBS in Richmond.  The address is 2015 Staples Mill Road in Richmond.  You can find more details and register online at:

http://www.richmondspin.org/home22222

Here’s the brief on my talk, which is based on my recent talk at Agile 2009.  I hope to see you there!

“Strategies for Persuasion on Adopting Agile”
By Arin Sime, Senior Consultant with OpenSource Connections

Do you want to know why Agile is sometimes a preferred methodology over a Waterfall method?  Arin will present 12 different methods for convincing a “traditional client” to use an Agile project plan. Based upon his own experiences with a wide variety of project styles, he will also present several definitions of each of the environments, well as results gathered from a survey on how to sell Agile. Some stories and best practices from other sources will also be covered.

Arin Sime’s presentation last week at Agile 2009 on how to sell a traditional client on an agile plan made a good impression, apparently.  First, his presentation was featured on the front page of SlideShare.

Now, he’s received an excellent writeup from Adam Goucher (we were pointed to Adam’s writeup from here).  Many thanks to Adam for the kind words about Arin’s writeup!

Arin’s next speaking engagement is at the University of Virginia’s EdUI conference on September 22, covering the Facebook API.  He’d love to see you there!