I discovered early on that the player who learned the fundamentals of basketball is going to have a much better chance of succeeding and rising through the levels of competition than the player who was content to do things his own way. A player should be interested in learning why things are done a certain way. The reasons behind the teaching often go a long way to helping develop the skill. — John Wooden
John Wooden is regarded as one of the greatest college basketball coaches. He believed that after talent, courage, and character, fundamentals built successful teams. Successful software projects result from knowing and practicing fundamentals as well, and it begins with estimation.
I thought it would be fun to see if Coach Wooden, by way of noted quotes, could help simplify a few SLIM core concepts.
John Wooden | SLIM Core Concepts |
"Don't let what you cannot do interfere with what you can do." | Estimates are uncertain. The accuracy of your estimate depends on the detail and relevance of the data upon which it is derived. Do not succumb to “paralysis by analysis.” You cannot commit to a detailed estimate early in the life cycle because you simply do not have the data to support it. What you can do is generate a reasonable expected result within a range of potential outcomes based upon industry data or your past performance. The estimate will be good enough to allow data-driven decisions and negotiations. You can improve the estimate as soon as more detailed information is available. |
"Never mistake activity for achievement." | Estimate the entire product, not the to-dos. SLIM employs a macro-level, top-down approach. Focus on the product and value the customer is asking for, and calculate the total effort, cost and duration required to create it. You will have to give some thought to what tasks will be performed, when, and by whom. However, diving into too much detail about this is planning, not estimating. Task-based estimates take time, and analyzing different scenarios can be difficult. Keep perspective on what is achievable. How many features can you deliver within the next six months, or next year's budget? How long will it take to implement the top 10 stories on the product backlog? Focus on these questions to guide your planning and validate your bottoms-up estimates. |
"Don't measure yourself by what you have accomplished, but what you should have accomplished with your ability." | Estimate based on known capabilities. Every project team wants to please the boss and the customer. You want to be as good as, if not better, than the competition. Resist the temptation to commit to project targets you cannot meet. Conversely, do not let what may appear to be poor performance blind you to the reality that complex systems require more time and effort. Do the last project's schedule and cost overruns lessen your achievements, or was the initial estimate too ambitious? Just four metrics (size, start date, end date, effort) from a handful of completed projects are enough to compute your productivity (no guessing). Then you can base estimates upon known capabilities. Use the QSM database until you can gather your own historical data. You will know what a typical project should be able to accomplish. |
"If you don't have time to do it right, when will you have time to do it over?" | More time leads to higher quality and lower costs. Time constraints are the norm for software and system development projects. Some deadlines are hard limits, but many are negotiable once defensible estimate data shows the risk outweighs the return. Often lengthening the schedule by only a few weeks allows you to use a smaller team and deliver all of the requested functionality. Increasing the effort to shorten the schedule will increase defects. If you do not allow for this, the product quality will suffer and you may be doing it over. SLIM will help you plan quality assurance efforts by predicting the total defects and product reliability as a function of time. |
"Be prepared and be honest." "Whatever you do in life surround yourself with smart people who'll argue with you." | Explore alternative solutions. Anticipate the questions stakeholders will have about the estimate, and prepare solutions to answer them. Explore the boundaries of possibilities and the tradeoffs required to meet them. If a team of 8 cannot complete the project in 6 months, how many people will it take? What productivity is required to meet the project goals, and how does that compare to history? How much functionality can the team produce in 6 months? Ask team members what they think of your estimate. Exercise due diligence in acquiring the best data to support the estimate, and let the data speak. Focusing on the facts reduces the tendency to make emotional rather than data-driven decisions. |
There are good reasons things are done a certain way. Practice these fundamentals as part of your estimation process and see if your game doesn’t improve.
As always, your comments are welcome.