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.

Earlier this year in my MSMIT classes at UVa, we talked about software estimation techniques, which was a very interesting topic.

One thing we talked about was the “Cone of Uncertainty”, as described in Steve McConnell’s book “Rapid Development.”  You can read the full description of the cone of uncertainty on the Construx website.  Here is a drawing of it as depicted on that website.

The Cone of Uncertainty is a convenient way to think of how software estimation works.  When a project is first beginning, you know very little about it and so you should never give customers a single point estimate.  A single point estimate just means that you supply one number, like saying “this project will take 6 months.”

Giving estimates in ranges instead is much more valuable and realistic.  This more accurately conveys to your customer the uncertainty of an estimate, and therefore the risk.  For example, if I give you a wide estimate like “this will take 3-12 months”, that is a very clear way to communicate that we don’t know enough yet to give a firm estimate.

The Cone of Uncertainty shows that the more you know about a project, the more you can narrow that range.  So while I might initially think it’s 3-12 months, after spending time analyzing the project, I can revise that to a more narrow range, like 6-8 months perhaps, or 10-12 months.

But what about the end of a project?  The Cone of Uncertainty says that the closer you get to the end of a project, the more likely you are to know exactly when it ends.  That makes sense in theory, but is it realistic?

I would suggest that many times, there is a large amount of uncertainty at the end of a project, even if it’s well run.  Imagine that you are two weeks away launching a new site, and you are still working out some bugs that your testers have found.  You know you only have a few bugs left, so you confidently assert to your boss or customer that you’ll be ready to launch in two weeks.  Each day you are fixing bugs, but the testers keep finding new bugs.  Perhaps they are even finding new bugs faster than you are fixing them, or their rate of finding bugs is not decreasing.

When you had a short bug list in front of you, you felt very confident about two weeks, but now you are less certain.  How many more bugs will testing uncover?  Your confidence about the time left to launch is now decreasing, and you have to go back to your boss or client and ask for additional time.

The Cone of Uncertainty captures risk at the front end of a project very well, but it doesn’t capture the risk and uncertainty at the back end of a project.

There’s one other thing that also makes me feel like the Cone of Uncertainty is perhaps a bit simplistic.  In my classes, we discussed using the Cone of Uncertainty as a way to educate our bosses and clients about why estimates are inaccurate.  The idea was to sketch it out on a napkin or whiteboard, and use it to convince them why you can’t give them a set estimate up front (“6 months”), but instead need to estimate in a range (“3 – 9 months”).

However, I believe the problem is that the Cone of Uncertainty implies that you will converge on a middle point most of the time.   While that is not the intention of the cone, it still can appear that way because of the way the cone is drawn.  So if your boss wants to be tricky, he can play games with the numbers.  If you tell him that a project will take 3-9 months, then he may just translate that to mean 6 months (the midpoint of your range.)

But how often have your range estimates actually converged on the midpoint?  I would speculate that most of the time, they actually converge on something above the midpoint.  That’s because our initial reactions are almost always optimistic, so as we learn more about the project’s complexity which we had not originally anticipated, then we are likely to settle on a point higher in our initial range estimate.

So I would further suggest that it’s better to draw the cone as not converging on a midpoint.  At some point in time, your estimates are likely to converge on an estimate that is higher than your original midpoint.  This leads me to my humbly suggested variation of the cone of uncertainty, which I like to call “The Wormhole of Reality.”

Why the wormhole of reality?  When the cone is redrawn like I’ve done above, it just looks more like a wormhole than a cone. I’m referring to the wormholes of physics and astronomy, where it is a shortcut through space and time. There’s no correlation between the meanings of wormholes in space and my estimation wormhole, it’s just that they look similar.  Plus I think it’s a cool name.

But more importantly, how do we avoid getting sucked into “The Wormhole of Reality”? If the Cone of Uncertainty is ideally the way we want our estimates to work, then we want to avoid the “fuzzy back end” of a project.  As I already suggested, the fuzzy back end is driven by continual bug reports that seem like they may never end.  Here are some tips to try and close out your projects more predictably:

• Use test driven development to write your unit tests early.
• Use browser based automated testing tools like Selenium to automate user level testing.
• Keep your continuous integration server happy and well-fed with frequent code check ins, so it can feed you bug information earlier rather than later.
• Engage users in your system testing early on.  Make sure that you deliver incremental releases of your code, at least to internal users and testers, well before the final weeks of your project.
• Engage customers in those incremental releases too.  If your internal users are not an accurate representation of external users to your code, then identify some beta customers who would be willing to try out future versions of your product.
• Consider incorporating regular user-experience testing with beta releases of your product, on a feature by feature basis.  This is another way to get additional feedback about the code you are going to deploy.
• Use agile methodologies to drive all of the above recommendations.

While the “Cone of Uncertainty” is an easy way to explain to managers and clients how to estimate software development, too often we fall into development traps and end up in dangerous territory like “The Wormhole of Reality.”  But by following best practices, and clearly communicating to customers the risk at the front and back end of a project, you will be more likely to avoid these pitfalls and deliver your software on time, on scope, and on budget.

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.

Scott Ambler wrote a very interesting article for Dr Dobbs Journal recently entitled “RFPs the Agile Way — or — Fear and Loathing in the Procurement Department.”  I first came across the article when Deborah Hartman Preuss wrote an excellent commentary on InfoQ about Scott’s article, entitled “Using the RFP Process to Hire Agile”.

As Ambler points out, the use of a formal RFP often implies that the client uses a traditional development method like Waterfall.  Procurement writes an RFP, and then the consultant responds with a detailed proposal dictating timelines and cost estimates, and perhaps an up front design.  All before ever meeting with the client.

The RFP process is a necessary evil of the consulting world, particularly in government contracting.  But RFPs don’t lend themselves well to the very collaborative discussions you can have with a client when you are using an Agile process, or if you are securing the contract in person rather than electronically.

This topic relates somewhat to my upcoming presentation at Agile 2009, “How to sell a traditional client on an Agile project plan.”  Although a lot of the advice I give in that talk can be done in proposals, most of it works better in person.  And so I think that’s a real challenge to accurately respond (in an Agile way) to an RFP that assumes a waterfall development model.

At first I didn’t quite find the answers I was looking for in Ambler’s article.  I don’t say that as a knock against the article at all, because it is well worth the read and I think it frames very well the problems with RFP processes.  However, Ambler is mainly encouraging procurement people to change the way they structure RFP’s so that Agile people can respond to it better.

I’m not sure the procurement people are going to read his column or see the incentive to do so (which he acknowledges, and asks readers to send this article to procurement people they know).  And so while I believe my Agile 2009 talk offers some strategies for how to positively discuss Agile in a proposal, I’m still in search of the holy grail.  How exactly do you respond to an RFP “the Agile Way”?

But after reading Ambler’s article again, perhaps he does lay out some of the answers I’m looking for.  He just does it from the opposite perspective.  He suggests this advice for what procurement people should look for in an Agile response to an RFP:

(rather than lift all his text, I’ve just included the highlights below.  I suggest you read his article for the full explanation)

The supplier should provide resumes

Follow a reasonable set of rights and responsibilities for both the customer and the supplier to adhere to … how they will collaborate together.

Propose how they will work with the customer.

Produce potentially shippable software to the customer every X weeks.

Allow the customer to monitor their work and work products.

Follow the customer’s corporate development guidelines.

Do full regression testing throughout the lifecycle.

Provide a minimal set of deliverable documentation, particularly user documentation, operations documentation, support documentation, and high-level systems overview documentation. The customer should provide examples of such documentation if they’re available.

Shared-risk strategy [for payment] which is fair to both customer and supplier.

Indicate rough estimates and schedules, in the +/- 30% range.

That’s a great list of ideas for consultants to incorporate into proposals, even if the customer is not looking for them.  I’m glad to see that we already do many of them in our standard proposal template at OpenSource Connections.  In particular, we always talk about our “Open Approach” to projects, ie, the highly collaborative and open way that we work with our customers using Scrum.

This is all a sign of the increasing maturity and adoption of Agile processes, and if nothing else, that’s a good thing.  Perhaps the procurement people will sign on eventually after all.

I’m very pleased to be co-speaking with Wayne Graham at EdUI 2009 at the University of Virginia this September 22nd.  EdUI 2009 posted the full conference schedule today, which included the talk Wayne and I will give.  Here’s the description for our talk:

The Facebook API:  Thinking about UI in a social way

Building an application for the Facebook API is very different than your standard application. The basic concepts and flow of your application need to conform to underlying principles of social media in order for people to use your application and share it with their friends. We will discuss the development and implementation of Facebook applications based on our own experiences and drawing on the best practices of other projects. Wayne will discuss his implementation of the Facebook-Athenaeum project, and Arin will discuss his experiences building an application for fundraising on Facebook. The presentation will be a mixture of high level design concepts, details on the Facebook API, and code examples. 

We’ll be speaking on Day 2, September 22, from 2:15 – 3:00 pm.  I’m really looking forward to hearing all the great speakers at this conference, and I’m honored to have a chance to present with Wayne at EdUI!

Last Thursday I had a great opportunity to speak at AgileCville, and give a dry run of my upcoming presentation at Agile 2009.

Eric took this photo of me speaking.  It looks like I’m doing The Robot.  I’m not, but that would have been cool.

I’d like to thank all those who attended. I really enjoyed the chance to share my thoughts on “How to sell a traditional client on an Agile project plan.” I got a lot of great feedback from everybody. I’m flattered how much of it was positive, and I also got a lot of very helpful constructive feedback that I will definitely incorporate as I polish my slides for Agile 2009. Most notably perhaps, I’m going to take a crack at improving the quality and consistency of the graphics in the slides.

The slides are available online here. I also brought my voice recorder with me, and I’ve posted very roughly edited audio from the meeting here. The presentation was about 35 minutes long, and then we had a very interesting and valuable discussion session for about an hour after that. If you try to listen to the audio, be forewarned that not everyone’s voice comes through clear in the second half when we’re having our discussion.

I’m really looking forward to seeing everyone at Agile 2009!

I’ll be speaking to this Thursday’s #agilecville group meeting, about “How to sell a traditional client on an Agile project plan.” I have 11 strategies that I will go over for how to convince your clients that Agile methodologies are the way to go, and I think they cover a variety of different styles so there should be something for everyone.

When: Thursday July 16th, 6:00 PM

Where: Jefferson Room, 3rd Floor, Charlottesville Central Library (http://www.jmrl.org/li-meeting.htm)

More info and signups are on the AgileCville Google groups page.

This is all part of my lead up to speaking at Agile2009, and I’m really looking forward to tapping into the experiences and brilliance of my fellow Agile practitioners here in Charlottesville.  If you haven’t already, please take a moment to fill out my survey on how to sell Agile.  I’ll use the information I gather from this informal survey as part of my presentation.

I hope to see you there!  OpenSource Connections will provide pizza and soda!