Monday, December 29, 2008

Embrace Uncertainty

At CommuniTech, Jeff Patton gave a talk about agile software development. Jeff starts by giving an introduction to agile. He mentions that it is nothing new. Scrum (1986), Crystal (1997), FDD(1998), XP(2000) all lead to the agile manifesto was in 2001. Agile development describes a class of approaches and not just a single approach. It combines elements of Scrum, DSDM, Crystal, FDD and XP.

Jeff then gives a primer on Scrum. A product owner sets product goals and adds requirements or features to a product backlog, he then takes highest priority items and elaborate them into details and start a development cycle of 2 to 4 weeks. Team has a daily stand up meeting to follow progress. At the end of the iteration, they evaluate the working software and get feedback which might affect the product backlog and the next iteration.

Jeff shows how the picture of the scrum process looks like a snowman. The head is stories that get packaged into an iteration. Every iteration does not have to result in a releasable product. It’s a number of iterations that form a release, and a number of releases form the product. Each cycle feeds into planning. At the iteration level, feedback is used to better understand the problem and to reduce risk. At the release level, the feedback ensures proper planning for releasing value. At the product level, the feedback is to update the roadmap.

Next Jeff presents 3 very entertaining scenarios (using personas and music lyrics) which demonstrate some practices that might lead to problems when using an agile model. He concludes that iterate does not mean increment. In incrementing we are piecing things together and it calls for an early well formed idea. Iterate builds a rough version, validates it, and then slowly builds up quality. Quality here refers to look and feel, characteristics and features. The client needs to prioritize the goals that generate return on investment. The developer needs to know what the client wants but always keep in mind what the ultimate goal is. They also need to push decisions to the last responsible moment and build up feature quality iteration by iteration. Instead of writing stories about what to do, write stories about what it intends to accomplish. Have a goal, take action, evaluate the action, and then evaluate if the goal got accomplished. Push decisions to the last responsible moment. Each story has the following characteristics:

1. Necessity: The minimum needed to get working software.

2. Flexibility: what are some alternative ways of doing it, what additional data we want to capture.

3. Safety: better validation rule to avoid ugly error messages.

4. Comfort, luxury, and performance: more usable, sexier to look at (animation), hot keys.

Jeff recommends starting out with the necessities and then slowly build up the product.

This presentation is available on InfoQ at

Wednesday, December 17, 2008

Introduction to Project Estimation

At Devoxx08, Giovanni Asproni gave a talk on Project Estimation. He emphasized the need to distinguish estimate from targets and commitments. Estimates are approximate estimation of the value, number or quantity of something (2 to 4 days, 10 to 20 million). A target is a desirable business objective (Support x users, do not exceed 1 million dollars). Commitment is a promise to deliver functionality with a certain quality by a certain date (search functionality will be available in next release). These three are independent of each other, but you should set targets and commitments based on your estimates. The estimates are not negotiable. But the targets and commitments are. The estimates are used to determine if the targets and commitments are realistic. Usual estimates include size, effort, time, cost, risk. Given some constraints (time and cost), estimate the other.

Estimates should be accurate and not precise. This means use the correct measurement unit. If something will take years, do not estimate in days or hours. Hours will be more precise, but it will be less accurate than a more appropriate measurement unit like years.

The cone of uncertainty shows that your estimates are off by a margin of error at the beginning and gets more and more accurate as the project moves along. The cone is the same for sequential or iterative projects. Do not commit at the beginning of the cone, but at a later date after several iterations or at the product design specification.

People who do the work should create the estimates. All assumptions should be taken into account. All tasks should be included. Make sure to plan for leave/absence and side tasks such as phone, email, meeting, browsing.

There are several techniques for estimation:

1) Count, compute, judge: count if you can, compute if you can’t, judge as a last resort.

2) Mathematical (COCOMO): Tools available but based on “knobs” (inputs unknown/inaccurate).

3) Historical: Industry, company or project data. Can be accurate, avoids wishful thinking.

4) Analogy: Compare to similar projects, simple to implements but subjective and less accurate.

5) Proxy: Use proxy to effort like story points or t-shirt size. Can be highly accurate but require experience.

6) Decompose and recompose: Split into small chunks and aggregate. Can be accurate but be careful because sum of individual chucks will not equal whole.

7) Expert Judgment: Individual or group (Delphi, planning poker). Can be highly accurate, but need experts.

More than one can be used at the same time as a sanity check. Start with historical data if available. If not use, expert judgment, proxy, or analogy. Keep track of your data and use it to improve as you go along. Estimation is an ongoing activity. Refine the estimates as you go along and remember that estimates will always be wrong!

This presentation is available on Parleys at