This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

New approaches to software development can sometimes seem at odds with the needs of business customers. For instance, ardent practitioners of the agile development methodology continue to advocate for rapid response approaches and the need for constant iteration to solve complex problems. On the other hand, companies and customers are demanding a strategic approach that provides insight into process, timing, and costs.

So, which of these yin and yang scenarios should developers employ? The answer is “both.”

Enter scope-based software estimation, which I maintain can be a powerful tool to ensure that projects remain on course and on budget. It is possible for schedule and budget estimation to be achieved without sacrificing any of the things that make agile development so potent.

Not everyone feels the same. Some would argue that there’s simply no place for estimates in an agile development world; that estimates cannot coexist with agile or “lean” methodologies like Scrum, which encourage teamwork, speed, and communication without constraints.

I am a big sports fan and since I work for a software metrics company, I started thinking about the similarities in productivity measurement in both industries. From draft picks to game planning decisions, managers in sports measure their team’s productivity to help them make better decisions in the future. Software executives and product owners do the same thing; they measure productivity in order to make better planning decisions regarding upcoming projects.

To measure productivity in baseball, we look at measures like batting average, on-base percentage, slugging percentage, and earned run average. When measuring the productivity of agile software projects, we often look at the velocity, which takes into account the number of user stories completed in each sprint. This type of historical data helps us plan effectively at the detailed level.

As part of our work at QSM, we are often asked to provide plans at the release and portfolio level. To provide these plans reliably, we use a macro level, empirically-based productivity measure that encapsulates a number of project-related factors. This measure is called the Productivity Index, an integral part of the Putnam Model.  Also known as the SLIM Model, the Putnam Model was invented by Larry Putnam Sr. almost 40 years ago and is having a big impact on software measurement more than ever today.

Once we know the total number of user stories (or any size measure), the release level effort, and the duration, we can calculate the Productivity Index of a project. The Productivity Index also takes into account the project environment including: the experience level of the team, the complexity of the software, and the quality of the tools and methods being used on the project.

“No, we don’t have any historical project data collected” is the statement I hear with some frequency when speaking to organizations about their IT project estimating processes.  Ideally we use client history to calibrate and tune the project estimates we provide.  In my quest to spread the word about parametric estimating I often encounter this notion that organizations don’t believe they have historical data in a retrievable form.  In almost every case that I have been involved, it turned out that the historical data was present, just not in the form of a 1,000 rowed spreadsheet.  Often times the data is more available than the client is aware.

Our approach works at a macro level so we are seeking overall project metrics of cost, schedule, size, staffing and defects.  If the actual formal documentation of history is not available for these five core metrics, then it usually is available by leveraging various sources within the organization.  We have found it’s common to resurrect a project’s outcome by seeking feedback from the team that worked the project, however if that’s not possible due to attrition, re-org or other disrupting factors, we can usually find the project metrics through other means.  Those other means may be time and defect tracking tools, requirements analysis tools and accounting systems.  The data is almost always documented somewhere.   

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

As we move closer to the end of the year, many of us are in planning mode. We’re working hard to determine which development projects are going to get done next year, and which ones may have to wait their turn until 2018.

No one should go it alone, though. Business executives need input from IT managers to truly gauge the feasibility of developing the projects that are on their list. Likewise, IT managers need insight into the expectations of business executives so they can produce the products they need.

That’s what makes project portfolio planning so essential. It brings business stakeholders and IT managers together by allowing them to communicate with each other about needs and expectations, and to find common ground that leads to realistic project estimates that help shape the course of successful development for the next 12 months.

It also helps establish a clear product roadmap. It’s not uncommon for organizations to start out with a long list of “to-do’s” every year, but doing everything is simply unrealistic. Therefore, it’s important to identify and prioritize projects that will bring your company the best ROI and help it meet overall strategic goals over the course of the next year.

Software measurement by itself does not resolve budget, schedule or staffing issues for projects or portfolios, but it does provide a basis upon which informed decisions can be made. Here are examples of how to use metrics to determine present capabilities, assess whether plans are feasible, and explore trade-offs if they are not. This is the third article of a three part series by QSM's Don Beckett for Projects at Work. You can read the first article here and the second here.

Read the article!

This post was originally published on Linkedin. Join the QSM Linkedin Group and Company Page to stay up-to-date with more content like this.

The term “true original” is used to describe someone who is a trailblazer -- and it describes my father to a T. My dad was an early architect of software estimation, the process of predicting the time, effort, and manpower it takes to complete a software development project.

Thirty-five years ago, my father was a budget director for the Army’s computer programs. He had the unfortunate experience of having his funding significantly reduced when his IT team failed to properly articulate its software development goals in ways that were relatable to leaders. As a superior put it, “Whenever I talk to the IT guys, I hear about bits and bytes, programming languages, and bandwidth, but nothing that relates to time, effort, and cost.”

That comment sent my dad on a mission to develop a software estimation frameworkthat addressed the three points that his boss was most concerned about. He sought to expose what he called “a fundamental law of nature in our software production equation.”

When organizations base their decisions on desires instead of data, it usually backfires. Here are four important actions that executives, PMO directors and program leaders can take to improve the predictability and success rate of their software development and enhancement projects. This is the second article of a three part series by QSM's Don Beckett for Projects at Work. You can read the first article here.

Read the article!

Mike Harris at the Davis Consulting Group blog links to a 2014 list of 11 Essential Programming Languages from Baseline Magazine:

If you want to learn about the hottest programming languages today, don't miss this list from IEEE Spectrum. This respected organization, which has 400,000 members and is considered the world's largest association of technology professionals, enlisted the services of Nick Diakopoulos, a well-known computational journalist and assistant professor at the University of Maryland, to compile the language rankings. Diakopoulos proceeded by weighing and combining 12 metrics from 10 sources, including IEEE Xplore, Google and GitHub. The result is a compilation of languages that cover big data analytics, graphics, system administration, network programming and virtually every other tech-supported function.

IEEE’s interactive list, which you can explore here, generates customized rankings for various sectors (Web, embedded, enterprise). In evaluating the results, it makes sense to ask, “What makes a programming language, ‘essential’?” Language popularity can be measured several ways:

The modern enterprise is software dependent. Whether you develop software in house, commission custom software, or purchase and install commercial software products, software projects are an important cost component and must be well planned and executed. But top-tier business leaders are rarely involved in the day-to-day management of software projects. Their job is to make decisions that affect a firm's strategic direction, policies and profitability. Business leaders can, however, establish procedures and practices that help projects succeed. In this new series for Projects at Work, Don Beckett explores how. The first article outlines the five fundamental "laws" of software development that all executives (and teams) should understand and follow.

Read the article!