Practical Software Measurement
In agile development, getting the backlog ready and grooming it take serious consideration and work. You need to plan, budget for, and track this work. In a recent interview with Cameron Philipp-Edmonds of StickyMinds, Andy Berner talks about his upcoming presentation for Agile Development Conference East, the importance of keeping a well-groomed backlog, the pitfalls of the impossible zone, and why it's vital that you and your team keep your tools serving you and not the other way around.
Client organizations who are considering investing in SLIM® (a top-down, scope-based, parametric software estimation tool) often ask us for return on investment (ROI) case study examples which we gladly provide to help them with their business case. However, one question that has never been asked but I have always wondered is: does ROI accelerate with increased investment or does it follow the law of diminishing returns?
To answer this question, we looked at seven software estimation ROI case studies that included a variety of small, medium and large clients, from a single seat of SLIM all the way up to an enterprise Estimation Center of Excellence (ECoE).
This case study for Agile Connection by QSM's Taylor Putnam serves as an example of how adopting agile can be extremely beneficial to an organization, as long as situational factors are considered. Adopting a new development method is a strategic, long-term investment rather than a quick fix. As this article shows, making deliberate, fully formed decisions will ultimately lead to better outcomes.
Software process improvement efforts often fail because we try to accomplish too much too soon. Aside from the cultural and organizational obstacles to change, people need time to learn and assimilate new ideas and skills. “Human memory and comprehension are limited, and it is easy to design processes that are beyond peoples’ capacities,” says Watts Humphrey (Humphrey, 1989). This is true in any situation, but I think it is compounded in the software world because time is always a scarce resource. The pressure is high in every organization to justify process improvement dollars and increase cap
I am a professional software project estimator. While not blessed with genius, I have put in sufficient time that by Malcolm Gladwell’s 10,000 hour rule, I have paid my dues to be competent. In the past 19 years I have estimated over 2,000 different software projects. For many of these, the critical inputs were provided and all I had to do was the modeling. Other times, I did all of the leg work, too: estimating software size, determining critical constraints, and gathering organizational history to benchmark against. One observation I have taken from years of experience is that there is overwhelming pressure to be more precise with our estimates than can be supported by the data.
A recent article in the New York Times about farm robotics, of all things, made me think about process improvement. In the article, dairy farms in New York are beginning to use robotic milkers to feed and milk cows without the use of farm hands. The solution was born out of several issues for dairy farmers, first, manual labor was hard to come by, and second, dairy prices were soaring.
Enough already with Healthcare.gov and the many (many) other high-profile IT project failures; let’s talk about government software projects that actually worked. Successful software projects are no accident. Best-in-class government IT projects share common traits that agencies can use to ensure success. In a recent article for Government Computer News, QSM's Larry Putnam, Jr. leverages data from from the QSM Database to identify best practices for successful government projects.
Television has done a fine job of glamorizing the job of an investigator. Whether you fancy the classic Sherlock Holmes, the affable Colombo, or even perhaps enjoy the suspense associated with cracking the case on television shows like “The First 48,” Hollywood has tried to make us believe the search for clues is always exciting. However, those who have searched thousand row spreadsheets for software data collection efforts, may beg to differ with that sentiment. The needle in a haystack analogy may seem more fitting, if only the haystack was bi