Agile is all the rage today and companies are investing lots of capital to work within agile frameworks. Are these new methods the key to reducing project failure? When projects get behind schedule, a common reaction is still to add more people. Doug Putnam recently examined 390 contemporary applications of the same size, a significant portion of which used agile methods and tools, to see what matters more - staffing decisions or methodology. He discovered that while the additional staff reduced the schedule by approximately 30%, the project cost increased by 350%. The additional staff also created 500% more defects that had to be fixed during testing. Over the past 15 years, QSM has performed this same study in five-year increments and has found the same results -- staffing decisions have more of an impact on project success than any development methodology. In this article, Doug Putnam identifies a staffing "sweet spot" and outlines a step-by-step planning process  that uses predictive analysis and early estimation to more accurately account for staffing needs.

Read the article!

In many agile environments, the budget, team size, and schedule are fixed based on an organization’s predetermined targets for sprints or iterations. This leads many project managers to question if software estimation is even necessary. The problem is, without a reliable size estimate, the amount of functionality promised within the time and money constraints could be difficult to achieve and could cause the product delivery to be short on features, or late and over budget.

This is where scope-level estimation tools come into play. They can help evaluate whether targets are reasonable and, even if the schedule and budget are both set in stone, they can help figure out how much work can be delivered. This type of analysis helps set customer expectations and provides data driven leverage for negotiations.

The best estimation tools leverage empirically-based models, industry analytics, and historical data. They can even be used before iteration level planning takes place. They ensure that the overall goals are reasonable before detailed plans are developed. 

In the three views below, we see an estimate generated from a “Time Boxed” method. This is where the product manager was able to input the predetermined time, a productivity measure (PI), and a team size, to see how many story points could be completed within the set constraints. The analysis also includes a “sanity check” of the estimate, comparing it to an agile industry trend from the QSM Industry Database and their own agile historical data.

Scaled Agile (SAFe) is a methodology that applies Agile concepts to large complex environments.  QSM recently worked with an organization that had implemented SAFe to develop an estimation methodology specifically tailored to it.  This article discusses how it was implemented.

Software estimation typically addresses three concerns: staffing, cost/effort, and schedule.  In the SAFe environment, however, development is done in program increments (PI) that in this case were three months in duration with two-week sprints throughout.  Staffing was set at a predetermined level and varied very little during the PI.  Thus, the three variable elements that are normally estimated (staff, cost/effort, and schedule) had already been determined in advance.  So, our job was done, right?  Wrong!  What remained to be determined was capacity: the amount to be accomplished in a single PI.  And that was a very sore “pain point” for the organization. 

In a world trending away from traditional waterfall and toward agile development methodologies, it would be understandable to assume that there is no longer a need for software project estimation. Many agile practitioners feel there’s no value in estimation, since they are already working with smaller increments and sprints and grooming their backlogs.

However, that assumption would be wrong.

In a recent interview, Ken Schwaber and Jeff Sutherland, the founders of Scrum, were asked about the #NoEstimate movement. Schwaber believes a more appropriate term may be #NoMeaningfulCommitments. He feels that people often confuse estimation with commitments and that, in fact, estimates should be used in making commitments. Sutherland mentioned a recent Rally (now CA) survey that asked members of 70,000 scrum teams about the estimation techniques they used and then correlated those techniques with speed of delivery. They found that those that eschewed estimates altogether yielded some of the slowest delivery times, while those that employed scope-based estimation delivered the fastest results.

Larry Putnam, Jr.'s latest article for InfoQ explains why estimation is still a very valuable practice, even in organizations that are dependent upon agile development methodologies. He outlines several best practices that stakeholders can use to get their software estimation processes back on track toward adding value to their organizations. Software estimation does not have to be difficult, onerous, or ineffective. Done right, it can be a highly effective tool that can help project managers provide value to their organizations.

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.

Larry Putnam, Jr. was recently quoted in 'Framework and Standards Are the "Essence" of Agile at Scale,' an article published in SD Times. The article consulted other industry experts such as Ivar Jacobson, Matt Schenck, Dean Leffingwell, and Ken France on best practices for implementing agile at scale. Larry's advice below.

Agile estimation is the key to a successful SAFe implementation
With all of the benefits of SAFe, getting it right is key. Using agile estimation can help.

“For organizations that are implementing SAFe, they’re really trying to coordinate a lot of different stakeholders within the organization and the real benefit they’re looking to get out of it is a much more nimble delivery,” said Larry Putnam Jr., co-CEO of QSM. “To be able to do that, we’ve got all these different stakeholders that we have to coordinate. That becomes really complicated and estimation is kind of the communication vehicle for these different stakeholders.”

Putnam explains that the highest level of an organization is the business and its stakeholders. The stakeholders or senior managers within an organization need to ask in what direction the business needs to go and how software will support that. These needs are usually articulated at a high level, said Putnam.

“Those are going to get apportioned across different value streams, and they’re really looking at the whole portfolio of what’s going on within the enterprise,” Putnam said. “In order to implement all those capabilities the business wants, you’ve got all these different cross-functional teams that are working on different pieces of the system.”

It’s a story we hear a lot in the software business these days, especially with agile development. New functionality is needed within a certain amount of time and within a certain budget. 

Some might say, "no problem! We can figure it out as we go along." They might feel comfortable because each sprint has already been set in stone.  But there are business-related questions that need to be answered before sprint-level planning takes place and before we commit to goals that might not be achievable at the release and portfolio levels. Should we agree to do this project? Can we really get all of the work done within our constraints? Will the software be reliable at delivery? How does this project impact our annual and multi-year forecasts? 

This is where having reliable big picture numbers can be helpful. Wouldn’t it be great if senior management and the technical team were on the same page early? There are empirically-based estimation tools that can help. The naysayers might say that the technical requirements aren’t firm enough to come up with early estimates before the sprint planning takes place. But the fact is that some of these models (the good ones) allow for managing uncertainty and they do it based on historical data. The slide below shows a summary example of a release-level estimate for cost, duration, and reliability.

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.

Successful software execution has always been about having the most relevant data at your fingertips, but there are more ways to gain knowledge beyond graphs and charts. The sharing of best practices and information on the latest solutions, along with access to communities of like-minded individuals, can also be powerful tools for managers responsible for delivering development projects within budget and on-schedule.

At QSM, we strive to provide not just the tools, but also the information needed to help these individuals succeed. That’s why, as we look forward to 2018, we are excited to offer a wealth of resources that go well beyond our SLIM-Suite of estimation tools. These eight resources provide insight and knowledge into some of the most important components of software estimation, including agile development and project management, as well as information specifically for SLIM users.

Agile Development

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.

Successful product development involves aligning the three V’s of corporate success – vision, value, and velocity. Organizations must establish a product development visionthat will help them achieve their goals. Their agile development teams must show valueby delivering products that meet this vision. Finally, these teams must be able to accurately plan and estimate velocity – the amount of work completed during a “sprint,” or specified period of development time -- and factors that could impede that velocity.

Unfortunately, these three V’s exist on different spheres in many organizations. Enterprises tend to be built in silos, with development teams and product owners on a foundational level, product management and system engineers on the next, and enterprise architects and portfolio managers at the top.

Disconnect and misalignment within this hierarchy can lead to inefficiencies and undermine agile development efforts. The point of agile is to be able to iterate product development at a faster and more efficient pace, in turn allowing teams to deliver consistent and maximum business value. That requires communication and teamwork amongst everyone involved in the product development process, including portfolio managers, product owners, solution managers, and more. But scaling agile within organizations can be very challenging -- in large part due to the hierarchies that are especially prevalent in larger enterprises.

Enterprise IT teams have been searching for years for the Holy Grail of software development: the greatest possible efficiency, at the least possible cost, without sacrificing quality.

This endless search has taken many forms over the years. Twenty years ago, development teams turned to waterfall methodologies as a saving grace. Soon after, waterfall begat object-oriented incremental or spiral, Rational Unified Development (RUP) practices.

Today, it’s agile development’s turn in the spotlight. C-suite executives are investing huge sums of money to develop their organizations’ agile methodologies. They’re also committing significant resources to train employees to work within agile frameworks.

Yet many projects are still failing, clients remain unsatisfied, and IT departments are often unable to meet scheduling deadlines. Why?

It’s the staff, not the method.

Whenever a project falls behind schedule, the natural inclination is to add more staff. There’s a belief that doing so will accelerate development and, ultimately, help the team hit their deadlines.

That’s not always the case, however. In fact, throwing more people at a project often results in slowing things down even more. Sure, your team might get a little bit of a short-term boost, but in the long run, you’ll have more connection points to manage (which can increase the potential for mistakes or defects) and higher costs.