Agile

Agile

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.'slatest 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.

Software estimation is no longer a solitary activity - as more organizations continue to move away from silo-driven development methodologies, the role of collaboration becomes increasingly essential. Organizations may have estimation experts within their companies, but there’s now a huge push towards bringing all stakeholders together throughout the estimation process. This movement is largely due to an increasingly-apparent correlation between collaboration and successful estimation.

When estimation experts create an environment of continuous collaboration between all stakeholders - from the technical to business level - estimation accuracy improves and expectations overall are better aligned across every stage of the software development lifecycle. That being said, it is critical that organizations establish an effective system for collaboration that appeals to all stakeholders.

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.

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.

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.

QSM recently published the seventh and final article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. Participants had several questions about measuring effort and productivity, and whether there are special issues around how to define and collect these metrics in an agile environment. In this article, Andy Berner identifies best practices for measuring effort and productivity in agile and discusses how the two are related.

QSM recently published the sixth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. The previous two articles focused on determining size in a consistent enough manner across multiple products, projects, and agile teams in order to have good historical data on which to base an estimate. They looked at several possible units of measure for software size, including story points, function points, and source lines of code (SLOC). SLIM-Estimate and SLIM-Collaborate permit any of those units, as well as others, to be used for software sizing. In order to use a sizing unit other than SLOC in the SLIM tools, you must assign a gearing factor. For function points, gearing factors are discussed here. In this article, QSM's Andy Berner addresses ways of choosing a gearing factor for story points.

QSM recently published the fifth article in the QSM Agile Round Table series. The QSM Agile Round Table was formed to discuss the role of estimation in agile environments. QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. This article continues the focus from the previous article on determining size in a consistent enough manner across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate. QSM's Andy Berner looks at other sizing units besides story points, in particular function points and source lines of code.