QSM has been collaborating with Forrester Research on a report focused on the current state of Agile development. Prior Forrester data shows an adoption rate of about 38% among developers in 2010 and continuous growth YoY in the last three years. However few have really scaled it to the enterprise level. Have you?

To get a better data representation, we encourage to participate in this survey. Tell us about your current and future Agile development plans. This survey will ask questions like: 

• What are the expected and achieved benefits of Agile?
• How is Agile being adopted?
• What is Agile actually improving in organizations and how are results being measured?
• Which Agile practices are the most commonly used? 

To participate in this survey, click here.

More Agile resources from QSM:

• Estimating Agile Projects Webinar 
• Beyond the Hype: Thoughts on Agile Development

Here's a risk question for you:

If today’s weather forecast predicts a 40% chance of rain and it actually rains, was that forecast “inaccurate”?  If the weather channel predicts a 40% chance of rain, but the sun shines all day, was the forecast “accurate”?

Software project estimates, like weather forecasts, should always be accompanied by some explicit attempt to quantify the risk that the actual outcome will differ significantly from the estimated outcome.  Estimates delivered without explicit risk assessment are more like targets: goals someone wants to achieve.

It turns out that whether it rains or not is actually a poor measure of forecasting accuracy.  A 40% chance of rain forecast is accurate if, on 100 days where the forecast said 40%, it rained on 40 days and didn’t rain on 60. Likewise, the accuracy of an individual software project estimate is not determined by whether the project actually achieves its committed estimate.  We can see this with a simple example: if SLIM-Estimate predicts only a 10% probability of achieving a schedule but the organization decides to commit to a plan with a 90% chance of failing, we could actually consider the estimate to be “more accurate” if the software project fails than if it is successful.

What most organizations are really looking for is not so much accurate estimates as accurate commitments, where the commitment is based on the estimate plus an appropriate level of risk resourcing.  But even with best contingency planning, there is always a finite chance of “failure”—it’s just a lot less than if we don’t resource risk. 

After being away from QSM and the software world for three years, I was blown away by SLIM v8.0's dynamic product integration. I knew it was coming, yet I was still impressed by the simplicity and power of analysis promoted by real-time data and tool links across the SLIM Suite that frees managers to focus on the important program issues.

SLIM-MasterPlan is the center of the SLIM Suite product integration.  It improves upon previously existing program management features of aggregating multiple SLIM-Estimate projects and ancillary tasks with two new capabilities: 

• Linking SLIM-Control workbooks to provide real-time project tracking and control at the program level 
• Performing What If analysis at this higher management view to consider a wider range of potential outcomes.

The What If analysis feature is what I want to highlight.

A good personal development coach knows the "power of the question."  Questions lead to discovery, innovation, and action that brings about positive change.  Better questions lead to better answers.  SLIM's power and distinction has always been fast and easy evaluation of the impact of change, and exploring the realm of possible outcomes.  That's what we are doing when we ask ourselves "What If…?" (or our boss asks us - and we better know the answer!).  SLIM's solution logs make it easy to compare estimates, plans, and forecasts to alternative solutions, QSM trends, and your historical project database.

Seen from an airplane window, the ground looks almost two dimensional.  Only the largest features: cities, rivers, and mountain ranges, stand out against the background.  The true complexity of the terrain only becomes apparent after we land and have to navigate through congested traffic, bad weather, and one-way streets.

Software projects are similar.  Staffing and budget plans are often based on high level requirements that tell us what needs to be done, but not how to accomplish it.  As business objectives are translated into the actions that need to be taken and the work products that must be produced, the size of the project, whether expressed in lines of code, function points, or RICEF objects, increases along with the time and effort required to create them.

This level of detail cannot be seen at the Requirements stage; it is invisible.  But, it can be accounted for and managed.  Software consultant, Capers Jones, has stated that software projects grow 1.5% per month.  A QSM study based on IT projects found that 90% of those projects were larger than they were initially estimated to be.  The average size growth was 15%.  This bias towards size growth was not the result of poor estimating.  At the time the initial estimates were done, the components that accounted for the size growth were simply not apparent.

During the webinar I recently presented, "Maximizing Value Using the Relationship between Software Size, Productivity, and Reliability," I received quite a few interesting questions. Here are the highlights:

Do you see the same behaviors in Agile projects as those you presented in this webinar?

In the work for my presentation, I did not look at Agile projects separately.  I was looking at overall trends, breaking things down by application type rather than by development methodology. 

However, Don Beckett recently made a conference presentation on Agile called “Beyond the Hype”.  Don looked at duration, effort, staff, productivity for Agile projects.  There is a nice table where he compared the performance of a typical agile project to a typical IT project. 

Don’s presentation summarizes it well.  The staff is a little higher on Agile projects, the duration and effort are a little lower, but the basic relationships between the metrics and size are similar.

Does the language an application development project is written in have any impact on the data? In other words, when looked at independently, do mainframe COBOL projects look different than .Net projects? 

On October 17 at 7:30 PM, Keith Ciocco will be presenting "Best Practices for Establishing a Successful Estimation Process" at the Gartner Symposium ITXpo. This presentation covers best practices for project estimation. Keith will summarize some key things to remember when setting up a successful estimation process at the organizational and project level, including the importance of calibrating to historical data and measuring size and productivity.

QSM will also be exhibiting at this conference. Stop by booth ET3 and enter to win an iPad 2!

Find more information about the Gartner Symposium ITXpo here and Symposium Session Agenda here.

A replay is now available for the webinar, "Maximizing Value Using the Relationship between Software Size, Productivity, and Reliability," presented by Paul Below.

Now, more than ever, software projects need to efficiently deliver reliable software. However, many development plans unintentionally guarantee a less than optimal result. This presentation describes how to maximize value by establishing minimum acceptable reliability and how to take advantage of the apparent paradox between software size and productivity through appropriate selection of team size and schedule duration.

Paul Below has over 25 years' experience in measurement technology, statistical analysis, estimating, forecasting, Lean Six Sigma, and data mining. He serves as a consultant for QSM, providing clients with statistical analysis of operational performance for process improvement and predictability. Mr. Below is a Certified Software Quality Analyst, a past Certified Function Point Specialist, and a Six Sigma Black Belt. He has been a course developer and instructor for Estimating, Lean Six Sigma, Metrics Analysis, Function Point Analysis, as well as statistical analysis in the Masters of Software Engineering program at Seattle University. He has one US patent and two patents pending.

View the webinar replay.

Have you ever found yourself wondering which SLIM tool to use for a task, or what interfacing features are available for various SLIM Suite applications? We've created a handy Quick Reference Guide that offers a concise, "at a glance" summary of the great features built into SLIM Suite! This one page table is chock full of useful information about import/export capabilities, major tool features, and interfaces to other SLIM tools or applications like Microsoft Project and IBM Rational Focal Point and Rational Team Concert.

Here's what you'll find:

• Tool descriptions and features
• Workbook extensions for each application
• API (Application Programmer's Interface) and third party integration availability by application
• Which settings and data can be imported into each tool
• Export options for charts, reports, and project data

Whether you've licensed one or two applications or the entire tool suite, we hope our Quick Reference Guide will be a helpful resource. 

You can find more resources in the QSM Support section of our website.

On Thursday, Oct. 6 at 1:00 PM EDT, QSM will host a webinar focused on the relationship and apparent paradox between software size, productivity, and reliability.

Now, more than ever, software projects need to efficiently deliver reliable software. However, many development plans unintentionally guarantee a less than optimal result. This presentation describes how to maximize value by establishing minimum acceptable reliability and how to take advantage of the apparent paradox between software size and productivity through appropriate selection of team size and schedule duration.

Paul Below has over 25 years' experience in measurement technology, statistical analysis, estimating, forecasting, Lean Six Sigma, and data mining. He serves as a consultant for QSM, providing clients with statistical analysis of operational performance for process improvement and predictability. Mr. Below is a Certified Software Quality Analyst, a past Certified Function Point Specialist, and a Six Sigma Black Belt. He has been a course developer and instructor for Estimating, Lean Six Sigma, Metrics Analysis, Function Point Analysis, as well as statistical analysis in the Masters of Software Engineering program at Seattle University. He has one US patent and two patents pending.

View the replay of this webinar.

We are pleased to announce that QSM has a new SLIM product tour. This online demo shows you how to quickly and easily use SLIM-Estimate to create an estimate validated by industry benchmarks or your own project history. The demo then demonstrates how to negotiate trade-offs and highlights some of the new features of the tool. The product tour also includes SLIM-MasterPlan, which allows you to roll-up multiple estimates and is ideal for iterative and non-iterative developments.

View the new SLIM demo here and tell us what you think!