Six Best Practices to Better Agile Implementation

While Agile software development has become the dominant methodology adopted by software development groups, many companies - including some of the most innovative - are not using it to its fullest potential. 

An alternative to traditional project management, the Agile approach is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery and continuous improvement, and it encourages rapid and flexible response to change. 

The approach helps teams respond to unpredictability through work completed within functional increments known as “stories,” and iterative work cadences, known as “sprints.” 

Over the past several years, Agile has become the leading methodology across software companies and corporate IT. HP published a survey last year titled, “Agile is the New Normal.” In the survey, HP notes that two thirds of the organizations surveyed reported their company as either “Pure Agile” or “Leaning toward Agile.” 

While Agile methodologies were introduced approximately 15 years ago, they have seen broad adoption in the past five years. With this widespread, recent adoption, it’s interesting to look across organizations and see how effectively Agile is being adopted.

Many companies only implement Agile in a superficial way. This is partly because Agile has developed a brand recognition among leaders and many feel pressure to move to Agile or be seen as being behind the curve. This pressure to adopt Agile leads them to only implement parts of Agile or not really change their culture to adopt it in a way that drives business benefits. 

To follow are six best practice recommendations for how to get the most out of your adoption of an Agile approach:

It is key for your process to establish a clear definition of when a story can be worked on by a developer. By nailing down this crisp definition of the story, you guarantee that expectations are clear on how the finished product will work. 

Often, developers are pressed to commit to delivering a story that still isn't fully defined by the business and doesn’t have testable acceptance criteria. If developers take on a story that doesn’t have a clear definition of ready and done, they often find themselves working on something that will be changing mid-flight and doesn’t meet expectations when it is delivered. 

This will lead to an estimation process that becomes consistent over time. It is critical that the whole team generates estimates, not just a project manager and technical lead. It is also critical that the team does estimates in story points. Humans will always be terrible at estimating time, but after 3-5 sprints, the team will develop a rolling average to convert points into man-hours. 

This is so important, because as long as the team estimates consistently (in a good or bad way) on story points, the value of a story point will be consistent over time. It is also important to estimate with a progressing scale that's not linear so there's no temptation to point shave.

This is another key area that will lead to an estimation process that becomes consistent over time. Teams need to set a maximum point value for their stories to be allowed into the sprint (typically 5-8 points). The smaller the story, the more well understood the effort is, and the more accurate that value of a point will become. 

Smaller stories are critical for the burn-up chart to help predict when it's going to be done. The burn-up is based on evidence combined with estimation. The story point also takes into account the full cycle-time for a story to work its way through all the overhead of code-review, integration, deployment, testing, bug-fix and demo to the business.

This will enable the team to trust the data-driven approach inherent in the Agile process. One example of a habit to break is estimation, which is inherently inaccurate. Understanding and controlling scope, and measuring velocity to predict timing is a better approach. 

Another habit to break is to lose the expectation for reports to be clean and linear. The burn-down is supposed to help us identify when and where we have bottlenecks. Based on empirical data, the burn down chart will likely have some messiness to it. 

A third habit to break is asking individuals for "projections" and "estimates" for when they think they'll be done. Again, it's tempting to ask when something will be done, but using the data from story points and the team’s velocity will yield a much higher quality estimate of when it will be completed. 

A fourth habit to break is forcing scope into sprints, or allowing scope not reflected on the board into the sprint. It's important for all work to be tracked on the board. The new production issue that's super, super high priority, should get a card just like everything else and should be worked in priority order. If that's more important than something that's already in progress, then that is removed from the sprint and the new card is added.

This investment in quality will allow the team to continue to move quickly over many sprints. To make sure that there is time budgeted for quality, it is best to avoid "hard commit" sprints. In these sprints, larger stories are worked on for the first 70 percent of the sprint and dropped to QA late in the cycle. QA is scrambling to get things tested, and stories aren't able to be completed and demoed to the product owner. 

Developers and managers must commit to doing automated unit, integration and system tests. Unit tests have to be built in from the start. They have to be run with every build of the software, and their development has to be part of the value of a story point. That overhead is critical to take on through the duration of the project to allow the development and QA team to continue to go fast. 

Code without tests is legacy code. Even if it's being written from scratch in greenfield, no tests will lead to a maintenance headache, and increased cost of ownership

This will allow the team to move faster over time, with confidence that the quality is improving over time as well. Make everything repeatable, and automated when possible, including builds, deployments, unit tests, integration tests, regression tests, fail-over, etc. 

Every time someone has to do something manually is a wasted effort. Invest in DevOps to build infrastructure to support the development and quality environments to be both accessible to the development and quality teams to manage easily, but also to be staging the repeatable process for upper environments (user acceptance test, pre-production, and production). The idea here is that friction is constantly being removed from the process for promoting code through the various environments.

Following these six core recommendations will help your organization get the most out of your Agile approach. Once these adjustments are in place, the team should always continue the introspection of retrospectives and constantly look for the areas they can improve their overall process.