Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.

“Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.

We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur.  Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.

In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.

Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.

The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.”

By Mike Griffiths

Characteristics of a high performing team:

• Collaborative / effective communicator
• Willing to cross boundaries
• Work side by side / discuss work out problems real time
• A lot of face to face communication required
• Humility – accept feedback
• Able to compromise / support team decisions
• Able to reflect back on events and provide insights (critical for retrospectives)
• Always looking to improve
• Think about things rather than blinding moving forward…..
• Pragmatic – Knows what “just” enough is, Do what it takes
• Adaptive / Flexible – Change direction as required
• Takes initiative / self motivated
• Willing to try new things (may be evident by a desire for continuous learning)
• Can figure out the most important thing to do next. Doesn’t need to be told what to do.
• Risk tolerant – able to make a decision and act based on the information known
• Able to work in fast pace / intense
• Willing to work in a team room – little privacy, very noisy, no prestige
• Can challenge ideas in a respectful manner
• Work incrementally – Willing to revisit work
• Accepting that the big picture will evolve over time

How to detect these characteristics:

• Behavioural descriptive questions – tell me a time when….give me an example of….
• Interests / desires may be evidence of the characteristics
• Informal references from prior projects / peers etc.
• Auditions – pairing on an activity
• Trial periods

Taken from Calgary APLN

Tip #1   Distinguish between estimates, targets, and commitments.

Tip #2   When you’re asked to provide an estimate, determine whether you’re supposed to be estimating or figuring out how to hit a target.

Tip #3   When you see a single-point “estimate,” ask whether the number is an estimate or whether it’s  really a target.

Tip #4   When you see a single-point estimate, that number’s probability is not 100%. Ask what the  probability of that number is.

Tip #5   Don’t provide “percentage confident” estimates (especially “90% confident”) unless you have a quantitatively derived basis for doing so.

Tip #6   Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t  misrepresent your confidence in your estimates.

Tip #7   If you are feeling pressure to make your ranges narrower, verify that the pressure actually is coming from an external source and not from yourself.

Tip #8   Don’t intentionally underestimate. The penalty for underestimation is more severe than the  penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

Tip #9   Recognize a mismatch between a project’s business target and a project’s estimate for what it is:  valuable risk information that the project might not be successful. Take corrective action early,  when it can do some good.

Tip #10   Many businesses value predictability more than development time, cost, or flexibility. Be sure  you understand what your business values the most.

Tip #11   Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone.

Tip #12   Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow by removing sources of variability from your project.

Tip #13   Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.

Tip #14   Account for the Cone of Uncertainty by having one person create the “how much” part of the estimate and a different person create the “how uncertain” part of the estimate.

Tip #15   Don’t expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can’t accurately estimate an out-of-control process.

Tip #16   To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.

Tip #17   Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements – that is, all requirements. Nothing can be built for free, and your estimates shouldn’t imply that it can.

Tip #18   Include all necessary software-development activities in your estimates, not just coding and testing.

Tip #19   On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.

Tip #20   Don’t reduce developer estimates – they’re probably too optimistic already.

Tip #21   Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of  better accuracy, they usually introduce subjectivity and degrade actual accuracy.

Tip #22   Don’t give off-the-cuff estimates. Even a 15-minute estimate will be more accurate.

Tip #23   Match the number of significant digits in your estimate (its precision) to your estimate’s accuracy.

Tip #24   Invest an appropriate amount of effort assessing the size of the software that will be built. The  size of the software is the single most significant contributor to project effort and schedule.

Tip #25   Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.

Tip #26   Use software estimation tools to compute the impact of diseconomies of scale.

Tip #27   If you’ve completed previous projects that are about the same size as the project you’re  estimating – defined as being within a factor of 3 from largest to smallest – you can safely use a ratio-based estimating approach, such as lines of code per staff month, to estimate your new project.

Tip #28   Factor the kind of software you develop into your estimate. The kind of software you’re developing is the second-most significant contributor to project effort and schedule.

Tip #29   When choosing estimation techniques, consider what you want to estimate, the size of the project, the development stage, the project’s development style, and what accuracy you need.

Tip #30   Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort.

Tip #31   Look for something you can count that is a meaningful measure of the scope of work in your environment.

Tip #32   Collect historical data that allows you to compute an estimate from a count.

Tip #33   Don’t discount the power of simple, coarse estimation models such as average effort per defect, average effort per Web page, average effort per story, and average effort per use case.

Tip #34   Avoid using expert judgment to tweak an estimate that has been derived through computation. Such “expert judgment” usually degrades the estimate’s accuracy.

Tip #35   Use historical data as the basis for your productivity assumptions. Unlike mutual fund disclosures, your organization’s past performance really is your best indicator of future performance.

Tip #36   Use historical data to help avoid politically charged estimation discussions arising from assumptions like “My team is below average.”

Tip #37   In collecting historical data to use for estimation, start small, be sure you understand what you’re collecting, and collect the data consistently.

Tip #38   Collect a project’s historical data as soon as possible after the end of the project.

Tip #39   As a project is underway, collect historical data on a periodic basis so that you can build a data-based profile of how your projects run.

Tip #40   Use data from your current project (project data) to create highly accurate estimates for the remainder of the project.

Tip #41   Use project data or historical data rather than industry-average data to calibrate your estimates whenever possible. In addition to making your estimates more accurate, historical data will reduce variability in your estimate arising from uncertainty in the productivity assumptions.

Tip #42   If you don’t currently have historical data, begin collecting it as soon as possible.

Tip #43   To create the task-level estimates, have the people who will actually do the work create the  estimates.

Tip #44   Create both Best Case and Worst Case estimates to stimulate thinking about the full range of  possible outcomes.

Tip #45   Use an estimation checklist to improve your individual estimates. Develop and maintain your own personal checklist to improve your estimation accuracy.

Tip #46   Compare actual performance to estimated performance so that you can improve your individual estimates over time.

Tip #47   Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree.

Tip #48   Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities.

Tip #49   Use the simple standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates for estimates containing 10 tasks or fewer.

Tip #50   Use the complex standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates when you have about 10 tasks or more.

Tip #51   Don’t divide the range from best case to worst case by 6 to obtain standard deviations for individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.

Tip #52   Focus on making your Expected Case estimates accurate. If the individual estimates are accurate, aggregation will not create problems. If the individual estimates are not accurate, aggregation will be problematic until you find a way to make them accurate.

Tip #53   Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.

Tip #54   Do not address estimation uncertainty by biasing the estimate. Address uncertainty by expressing the estimate in uncertain terms.

Tip #55   Use fuzzy logic to estimate program size in lines of code.

Tip #56   Consider using standard components as a low-effort technique to estimate size in a project’s early stages.

Tip #57   Use story points to obtain an early estimate of an iterative project’s effort and schedule that is based on data from the same project.

Tip #58   Exercise caution when calculating estimates that use numeric ratings scales. Be sure that the numeric categories in the scale actually work like numbers, not like verbal categories such as  small, medium, and large.

Tip #59   Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in the wide part of the Cone of Uncertainty.

Tip #60   Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and other quantities that are difficult to estimate directly.

Tip #61   Count whatever is easiest to count and provides the most accuracy in your environment, collect  calibration data on that, and then use that data to create estimates that are well-suited to your environment.

Tip #62   Use group reviews to improve estimation accuracy.

Tip #63   Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when several diverse disciplines will be involved in the project itself.

Tip #64   Use an estimation software tool to sanity-check estimates created by manual methods. Larger projects should rely more heavily on commercial estimation software.

Tip #65   Don’t treat the output of a software estimation tool as divine revelation. Sanity-check estimation tool outputs just as you would other estimates.

Tip #66   Use multiple estimation techniques, and look for convergence or spread among the results.

Tip #67   If different estimation techniques produce different results, try to find the factors that are making the results different. Continue reestimating until the different techniques produce results that converge to within about 5%.

Tip #68   If multiple estimates agree and the business target disagrees, trust the estimates.

Tip #69   Don’t debate the output of an estimate. Take the output as a given. Change the output only by changing the inputs and recomputing.

Tip #70   Focus on estimating size first. Then compute effort, schedule, cost, and features from the size estimate.

Tip #71   Reestimate.

Tip #72   Change from less accurate to more accurate estimation approaches as you work your way through a project.

Tip #73   When you are ready to hand out specific development task assignments, switch to bottom-up estimation.

Tip #74   When you reestimate in response to a missed deadline, base the new estimate on the project’s actual progress, not on the project’s planned progress.

Tip #75   Present your estimates in a way that allows you to tighten up your estimates as you move further into the project.

Tip #76   Communicate your plan to reestimate to other project stakeholders in advance.

Tip #77   Develop a Standardized Estimation Procedure at the organizational level; use it at the project level.

Tip #78   Coordinate your Standardized Estimation Procedure with your SDLC.

Tip #79   Review your projects’ estimates and estimation process so that you can improve the accuracy of  your estimates and minimize the effort required to create them.

Tip #80   Use lines of code to estimate size, but remember both the general limitations of simple measures and the specific hazards of the LOC  measure in.

Tip #81   Count function points to obtain an accurate early-in-the-project size estimate.

Tip #82   Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in the project.

Tip #83   Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of Uncertainty.

Tip #84   With better estimation methods, the size estimate becomes the foundation of all other estimates. The size of the system you’re building is the single largest cost driver. Use multiple size-estimation techniques to make your size estimate accurate.

Tip #85   Use software tools based on the science of estimation to most accurately compute effort estimates from your size estimates.

Tip #86   Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone of Uncertainty. For larger projects, remember that more powerful estimation techniques are easily cost-justified.

Tip #87   Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and look for convergence or spread among the different estimates.

Tip #88   Not all estimation methods are equal. When  looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results.

Tip #89   Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.

Tip #90   Use the Informal Comparison to Past Projects formula to estimate schedule early in a small-to-large project.

Tip #91   Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort) schedule estimate early in a project.

Tip #92   Do not shorten a schedule estimate without increasing the effort estimate.

Tip #93   Do not shorten a nominal schedule more than 25%. In other words, keep your estimates out of the Impossible Zone.

Tip #94   Reduce costs by lengthening the schedule and conducting the project with a smaller team.

Tip #95   For medium-sized business-systems projects (35,000 to 100,000 lines of code) avoid increasing the team size beyond 7 people.

Tip #96   Use schedule estimation to ensure your plans are plausible. Use detailed planning to produce the final schedule.

Tip #97   Remove the results of overly generic estimation techniques from your data set before you look  for convergence or spread among your estimates.

Tip #98   When allocating project effort across different activities, consider project size, project type, and the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.

Tip #99   Consider your project’s size, type, and development approach in allocating schedule to different  activities.

Tip #100   Use industry-average data or your historical data to estimate the number of defects your project will produce.

Tip #101   Use defect-removal-rate data to estimate the number of defects that your quality assurance practices will remove from your software before it is released.

Tip #102   Use your project’s total Risk Exposure (RE) as the starting point for buffer planning. Review the details of your project’s specific risks to understand whether you should ultimately plan for a buffer that’s larger or smaller than the total RE.

Tip #103   Planning and estimation are related, and planning is a much bigger topic than can be addressed in one chapter in a book that focuses on software estimation. Read the literature on  planning.

Tip #104   Document and communicate the assumptions embedded in your estimate.

Tip #105   Be sure you understand whether you’re presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment.

Tip #106   Don’t present project outcomes to other project stakeholders that are only remotely possible.

Tip #107   Consider graphic presentation of your estimate as an alternative to text presentation.

Tip #108   Use an estimate presentation style that reinforces the message you want to communicate about your estimate’s accuracy.

Tip #109   Don’t try to express a commitment as a range. A commitment needs to be specific.

Tip #110   Understand that executives are assertive by nature and by job description, and plan your estimation discussions accordingly.

Tip #111   Be aware of external influences on the target. Communicate that you understand the business  requirements and their importance.

Tip #112   You can negotiate the commitment, but don’t negotiate the estimate.

Tip #113   Educate nontechnical stakeholders about effective software estimation practices.

Tip #114   Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses.

Tip #115   Attack the problem, not the people.

Tip #116   Generate as many planning options as you can to support your organization’s goals.

Tip #117   As you foster an atmosphere of collaborative problem solving, don’t make any commitments based on off-the-cuff estimates.

Tip #118   Resolve discussion deadlocks by returning to the question of, “What will be best for our organization?”

From Software Estimation by Steve McConnell (Microsoft Press, 2006)

The following sanity check indicates how useful your current project estimate is likely to be in managing your project. For each Yes answer, give the estimate one point.

1. Was a standardized procedure used to create the estimate?

2. Was the estimation process free from pressure that would bias the results?

3. If the estimate was negotiated, were only the inputs to the estimate negotiated, not the outputs or  the estimation process itself?

4. Is the estimate expressed with precision that matches its accuracy? (For example, is the estimate expressed as a range or coarse number if it’s early in the project?)

5. Was the estimate created using multiple techniques that converged to similar results?

6. Is the productivity assumption underlying the estimate comparable to productivity actually  experienced on past projects of similar sizes?

7. Is the estimated schedule at least 2.0 x StaffMonths1/3? (That is, is the estimate outside of the  Impossible Zone?)

8. Were the people who are going to do the work involved in creating the estimate?

9. Has the estimate been reviewed by an expert estimator?

10. Does the estimate include a nonzero allowance for the impact that project risks will have on effort and schedule?

11. Is the estimate part of a series of estimates that will become more accurate as the project moves into the narrow part of the cone of uncertainty?

12. Are all elements of the project included in the estimate, including creation of setup program,  creation of data conversion utilities, cutover from old system to new system, etc.?

This Estimate Sanity Check is from Software Estimation by Steve McConnell (Microsoft Press, 2006)

Scores of 10-12 indicate estimates that should be highly accurate.

Scores of 7-9 indicate estimates that are good enough to provide project guidance but that are probably optimistic.

Scores of 6 or below indicate estimates that are subject to significant bias, optimism, or both, and are not accurate enough to provide meaningful guidance to managing a project.

Developers and managers sometimes worry that presenting an estimate that’s too high will cause the project to  be rejected. That’s OK. Executive management has both the responsibility and the right to decide that a project is not cost-justified. When technical staff low-balls a project estimate, it denies the executives important information they need to make effective decisions, effectively undermining the executive’s decision-making authority. This results in diverting company resources from projects that are cost-justified to projects that aren’t cost-justified. Good projects aren’t supported adequately, and bad projects are supported excessively. The whole scenario is incredibly unhealthy for the business, and it tends to end unpleasantly for the people involved in the projects that should not have been approved in the first place.

An essential practice in presenting an estimate is to document the assumptions embodied in the estimate.

Assumptions fall into several familiar categories:

• Which features are required
• Which features are not required
• How elaborate certain features need to be
• Availability of key resources
• Dependencies on third-party performance
• Major unknowns
• Major influences and sensitivities of the estimate
• How good the estimate is
• What the estimate can be used for

• Show the same demo twice to the same audience.

• Focus on the technologies, not the problems and scenarios.

• Fail to maximize return on investments; for example, developing proof−of−concept

prototypes is more effective than adding additional content to an existing prototype.

• Change project focus from the larger scale to the smaller scale.

• Don’t maintain consistency between releases.

• Isolate team efforts from other groups within an organization.

• Rewrite existing clients, servers, and applications.

• Change the purpose of the system, so that the models describe the wrong focus and

objects.

Nothing can breakdown a team more quickly than a leader that have disproportionate reactions or that give-up easily

Any Leader that uses is power against their subordinates is subject to lose his power

Intuitively, a perfectly accurate estimate forms the ideal planning foundation for a project. If the estimates are  accurate, work among different developers can be coordinated efficiently. Deliveries from one development  group to another can be planned to the day, hour, or minute. We know that accurate estimates are rare, so if we’re going to err, is it better to err on the side of overestimation or underestimation?

Arguments Against Overestimation

Managers and other project stakeholders sometimes fear that, if a project is overestimated, Parkinson’s Law  will kick in – the idea that work will expand to fill available time. If you give a developer 5 days to deliver a task  that could be completed in 4 days, the developer will find something to do with the extra day. If you give a project team 6 months to complete a project that could be completed in 4 months, the project team will find a  way to use up the extra 2 months. As a result, some managers consciously squeeze the estimates to try to  avoid Parkinson’s Law.

Another concern is Goldratt’s “Student Syndrome”. If developers are given too much time, they’ll procrastinate until late in the project, at which point they’ll rush to complete their work, and they probably won’t finish the project on time.

A related motivation for underestimation is the desire to instill a sense of urgency in the development team. The line of reason goes like this:

The developers say that this project will take 6 months. I think there’s some padding in their estimates and some fat that can be squeezed out of them. In addition, I’d like to have some schedule urgency on this project to force prioritizations among features. So I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will  deliver in the 6 months they originally estimated.

Are these arguments compelling? To determine that, we need to examine the arguments in favor of erring on the side of overestimation.

Arguments Against Underestimation

Underestimation creates numerous problems – some  obvious, some not so obvious.

Reduced effectiveness of project plans. Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work.

If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems. But numerous studies have found that software estimates are often inaccurate by 100% or more. When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.

Statistically reduced chance of on-time completion Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.

Poor technical foundation leads to worse-than-nominal results A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take longer than it would have taken with an accurate estimate.

Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project. Here are some examples:

• More status meetings with upper management to discuss how to get the project back on track.
• Frequent reestimation, late in the project, to determine just when the project will be completed.
• Apologizing to key customers for missing delivery dates (including attending eetings with those customers).
• Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready     on time, the software itself could be used, and no interim release would be necessary.
• More discussions about which requirements absolutely must be added because the project has been  underway so long.
• Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the     schedule pressure.

The important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals. These extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately.

Weighing   the  Arguments

Goldratt’s Student Syndrome can be a factor on software projects, but I’ve found that the most effective way to address Student Syndrome is through active task tracking and buffer management (that is, project control), similar to what Goldratt suggests, not through biasing the estimates.

I believe that Parkinson’s Law does apply to software projects. Work does expand to fill available time. But deliberately underestimating a project because of Parkinson’s Law makes sense only if the penalty for overestimation is worse than the penalty for underestimation. In software, the penalty for overestimation is linear and bounded -work will expand to fill available time, but it will not expand any further. But the penalty for underestimation is nonlinear and unbounded – planning errors, short changing upstream activities, and the creation of more defects cause more damage than overestimation does, and with little ability to predict the extent of the damage ahead of time.

Tip: Don’t intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets