Do you feel your organization is immature when it comes to software development estimation? Software estimation process maturity isn’t all or nothing! And chances are you’re selling yourself short. Let me share one client’s journey to higher software estimation maturity and the lessons they learned along the way.
A Common Perception
Many organizations don’t feel mature enough to estimate their software development releases and portfolios using something other than a spreadsheet or expert judgement. That’s understandable to a degree, because spreadsheets are familiar, they are often introduced to us when we first learn about computers. There’s a comfort we feel in the spreadsheet world. And spreadsheets and expert judgement don’t typically incur any significant extra costs. The overall feeling that their processes are immature is due to the misconception that formal software process assessments are required to validate the good practices already in use.
Making small improvements relative to current practices increases your maturity. To get real value out of accurately estimating software projects — delivering quality features on time and within budget — consider using a software estimation tool that offers objective analytics and insights a spreadsheet cannot. You don’t have to be very mature to glean the benefits from an estimation tool and your maturity will grow with continued use.
Maturity, in the sense of this blog post, is defined as the level of sophistication, effectiveness, and consistency that a development team or organization has achieved in its software development practices. In the mid-1980’s through the mid 2000’s the Capability Maturity Model stood as the standard for software process maturity. Organizations would strive for level one, Initial, and some achieved the pinnacle of level 5 – Optimizing. Then Agile emerged with widespread adoption and its process light approach, vanquishing the CMM (later CMMI) to a corner of the room. Despite good intentions and valiant efforts, software process immaturity is as present today as it ever was, but I submit there are “shades” to maturity.
Organizations I’ve spoken with will often lament their perceived immaturity as an inevitable hurdle that “someday” will be overcome. A typical exchange goes something like this:
Me: Do you have a need or interest in estimating your software releases?
Program Manager: Yes, our estimates are often inaccurate in terms of cost, schedule and reliability.
Me: How do you currently estimate your software releases and programs?
Program Manager: Bob in Shared Services has been here forever and has experience with many past programs so he tells us how long it’ll take and how much it will cost.
Me: Have you considered using a tool to help automate that process and drive out the guess work, and, have a plan B for when Bob leaves?
Program Manager: Oh, we’re not mature enough to use a formal tool. We rely on Bob’s spreadsheets, but only Bob knows how they work. Maybe in several years we’ll be mature enough to take on a formal estimation tool when Bob leaves.
It's Easier Than You Think
In the above scenario I’ll check back several years down the road and often the answer remains the same – “we aren’t mature enough yet”. We at QSM have seen this scenario overcome with great success. When organizations tell me they are immature it’s often a blanket statement referencing process, personnel/management, and tools, among other areas. A couple questions later I learn the immaturity is specifically rooted in any one of these areas, and more:
- Ill-defined and/or weak processes
- Lack of experience
- Communication channels are poor
- Little support from leadership
- Little to no use of formal tools
However, we have provided a repeatable and simple solution to customers despite the lack of confidence in their own maturity. I once worked with a client that was convinced they were doomed to an eternal cycle of under and over estimating their software releases and portfolios. The initial pushback was their self-perceived process immaturity. Our kickoff discussion was like the example above with the Program Manager. They agreed that they’d like to head off the day when their “Bob” leaves them in a lurch when he departs and takes all the institutional knowledge with him. We offered a centralized, top-down software estimation method that required relatively few data inputs. At first, they were dubious, but we were fortunate to have their trust to at least try the path we suggested. Our method doesn’t need oodles of resources chasing dozens of data points from various departments while expending precious time away from other priorities. They were pleasantly surprised to learn that we simply needed 4-5 software project core metrics to build a template from which to estimate their next release.
Sounds too good to be true but it’s much more attainable than one may think. At a minimum we’re seeking some very basic outputs of previously completed releases/projects such as:
- Total size, in whatever sizing method was used. Could be epics, features, use cases, stories, SLOC or anything that’s countable.
- Duration – how long did it take to complete the release from concept to delivery?
- Staffing – how many people were on the team?
- Methodology - was it built in Agile, Waterfall, a hybrid?
- Effort – how many effort hours were spent?
Opposed to a bottoms-up approach that requires collecting data at the task level and rolling up to estimate, we have shown that a top-down approach requires less time, resources, and data to render an accurate estimate. So, our client presented us with multiple spreadsheets, each with many tabs of completed project data. Together we analyzed the spreadsheets and extracted sizing artifacts from various countable entities they were using like epics, features and stories. Additionally, we were able to assign complexity levels to each sizing artifact to create software size estimation techniques. For example, a medium complexity epic equals X number of stories. The number of staff was relatively easy to retrieve since we are looking at the entire team and can often get that from time tracking tools. Duration was another fairly easy metric to glean as start and delivery dates are typically available. By the end of our first meeting we were able to generate a few historical data points against which to calibrate and tune their next estimate. The client was pleasantly surprised at the accessibility of meaningful data tucked away in their spreadsheet. We then generated several estimates based on their history, while simultaneously building a process for future data collection.
Building Upon Small Wins
While their initial hesitation to work with us was rooted in their self-doubt about their maturity, they realized in the end that they were in fact capable of estimating their projects with a parametric tool. Their software estimation process maturity increased as we continued to work with them. The estimates they generated were well received, resulting in higher confidence in their abilities, which helped their estimation practice grow organically. As time passed their process became more refined, estimators gained experience, and senior leadership took notice of the increase in accurate estimates.
Maturing your software estimation process will have a ripple effect across the organization. Increased efficiency developing estimates equals time saved that can be applied to other priorities. Estimates will become more accurate, which leads to more successful projects. Also, you’ll be growing a legion of estimate consumers that are confident in your organization’s ability to provide accurate and defendable estimates.
Software development and project management maturity is formally defined via the CMM®, CMMI® and PMBOK®, which are all good and sound frameworks. Yet it is possible to become mature through a grass roots centralized approach to estimation. Start small, with just 1-2 people working toward manageable and attainable goals. A repeatable process falls into place. Once there are some organic “wins” (think accurate estimates generated with significantly less effort than previous methods) company-wide confidence kicks in to foster more improvement intiatives. I’ve tried to avoid oversimplifying the idea of growing maturity in your software estimation efforts, but I promise you it’s easier than you may think.