Agile has become the most prevalent software development methodology, with 95% of companies noting they use Agile in some form, according to the latest State of Agile report. As Agile enters its third decade, it is not a question of whether to use Agile, but which flavor of Agile to use. 

In our work with companies of all sizes over the years, we have found that while many organizations purport to “do Agile,” they do not necessarily deliver the higher quality, appropriately prioritized software that Agile promises.

Cultural barriers and organizational misalignment often get in the way of realizing the true value of Agile. Indeed, respondents to the survey above cited resistance to change, lack of leadership participation, and organizational culture at odds with Agile values among the top challenges to adopting Agile practices.

In this article, we will provide a brief overview of the Agile methodology and discuss five characteristics that have helped leaders address common challenges and realize greater value from their Agile implementations. 

Why Agile?

Agile methodology prioritizes delivering software in an incremental and iterative way. The way we define Agile today has its roots in 2001, when a group of software practitioners formulated the Agile Manifesto. Unlike prior approaches, in which software was developed in silos with little input from customers or business partners, Agile methodology prioritized an iterative development process that emphasized collaboration and adaptability.  

Why do so many organizations choose Agile? Those familiar with linear “waterfall” software development lifecycles will remember how slow, counterintuitive, and frustrating it could be to complete a project. Project managers spent most of their time making plans and adjusting them daily, while engineers found themselves torn between actually developing software and re-estimating months of work based on changing requirements. Users were rarely happy with the end product, and despite lots of negotiation it rarely felt like anyone was “winning.” 

While waterfall development has a role to play in some IT projects, much of the corporate world has embraced Agile to jump-start software development and delivery efforts. When implemented well, Agile can lead to high-quality software delivered frequently and built with the end-user in mind. 

In our work with Agile teams across large companies, we have observed the following five characteristics of successful implementations:

1. Executive buy-in and commitment

Any organization that wants to start on an Agile path or improve its existing Agile practice must begin with a real commitment from executive leadership. For an Agile initiative to be successful, leaders need to possess the Agile mindset and be determined to lead and support their employees through the transition. 

Most organizations that fail at their Agile initiatives miss this first step. We frequently see that leaders fall at two extreme ends of the spectrum: they are either micromanagers or they are absent. The best Agile leaders, on the other hand, give teams the autonomy to do their work while removing roadblocks and acting as a guide to ensure that goals are clear and the work contributes to the broader vision. Effective Agile leaders allow their employees to fail while creating mechanisms to learn from failures so that they are not repeated. 

We see most successful implementations of Agile in organizations where leaders guide and inspire, establish the right framework, and empower their teams to do their best work. Leaders do this best by listening to their teams and trusting their judgement in the way they do their work.

2. Choosing the right process

As mentioned earlier, these days it is not a matter of whether to use Agile, but rather what flavor of Agile to use. Below are a few common approaches your teams might choose: 

Scrum is the most commonly used Agile methodology for organizations that want to develop products incrementally in short iterations, with more than 75% of respondents to the Agile survey noting they use some version of it. Scrum is frequently used interchangeably with Agile, and most Agile teams today will use basic pillars of Scrum such as Sprint Planning and Daily Standups. Those whose projects involve high levels of uncertainty may select Scrum because it allows teams to share progress frequently and pivot as needed.

Many mature Agile teams favor Kanban, an Agile framework for continuous work with limited throughput, or scenarios in which teams may be working on only a handful of tasks at one time. A typical Kanban team will have work requests coming in regularly, and the team will release on a continuous basis. This approach tends to work well for teams with work that is more operational or “keep-the-lights on” in nature, such as minor feature updates or bug fixes.

Organizations that want to expand their Agile practices to large programs or portfolios often select a scaled Agile framework. SAFe®, as it is known, is the most prevalent framework for enterprise-level implementations of Agile. This is often the choice for large programs with multiple teams and intricate dependencies. These large programs are typically a combination of Scrum and Kanban teams. 

The best way to select the right flavor for your organization is to first observe and listen. Experienced Agile Transformation leaders will assess existing teams, tools, and processes to understand the current state of existing Agile practices. They will then pair those findings with the strategic goals of the business to choose the most appropriate implementation. 

3. Team structures that fit the company’s goals and culture

Once leadership commits to the process and an appropriate Agile methodology has been selected, it is time to begin the “practice” of Agile. 

Regardless which methodology you choose, two things are critical to a successful implementation: team structures, and the roles and responsibilities within those teams. 

The Agile methodology has clearly defined roles with very specific responsibilities. The Product Owner owns the vision of the ultimate goal and is responsible for setting priorities to bring value to the customers quickly. Scrum Masters are servant-leaders, responsible for removing impediments and ensuring that the team adheres to Agile principles. Delivery Teams, which can include team members with different areas of expertise depending on the project, are responsible for producing high-quality products.

Clear roles and responsibilities prevent confusion. Without them, things fall through the cracks and there may be friction between team members with overlapping roles or reporting relationships. For example, some organizations may choose to appoint someone’s direct manager as a Product Owner. As work commences, the direct report working on the team may find it difficult to know when they are hearing from their boss, who can mandate how and when certain work gets done (and makes compensation and promotion decisions), or from the Product Owner, who does not dictate how the work gets done. Having a boss as a Product Owner can also diminish the sense of ownership a person has about their project. 

The second most common mistake we find occurs during the formation of teams. Whatever Agile methodology an organization chooses, there are common aspects of successful Agile teams:

  • Size: Small. Five, plus or minus two members, with clear roles and responsibilities
  • Skillset: Cross-functional, with each team possessing all of the skills needed for a project 
  • Goal orientation: Focused on a specific function or product and incrementally creating complete, potentially shippable products or features
  • Focus: Customer oriented and user focused
  • Culture: Empowered and autonomous team members

Teams with these qualities often will be better prepared to produce their best work while also adapting to changes in technology or customer demands. When teams continuously deliver products that meet customers’ needs, trust will continue to develop between teams and management.

Two of the most common and easy-to-fix mistakes we see involve team size and skillset. Teams that are too large often lead to longer meetings and time to align. Teams lacking cross-functional skillsets are more dependent on other teams. In both cases, teams risk increased complexity and potential for errors.

4. A true commitment to continuous learning

Implementing Agile at scale requires a commitment to continuous learning. Rather than conducting a post-mortem analysis at the conclusion of a project and filing away the findings, Agile puts specific emphasis on Kaizen, which means continuous improvement. The concept, which comes from the Toyota Manufacturing System, aims to eliminate waste by looking for product and process quality improvements throughout the entire development cycle.

In Agile, work is broken down into smaller increments so that learning from each increment can be applied to the following increment. Agile teams will conduct Sprint Retrospectives at the end of each one-to-four-week increment where they discuss and document what went well and what could be done better going forward. They then take these learnings to make the next increment more effective.

The importance of continuous learning is often overlooked. Leaders should allow their teams to fail and learn from those failures, while providing appropriate guardrails to ensure the team is not taking on undue risk. It is critical that teams not only hold regular and honest retrospectives, but that they also act on those findings and track progress. Too often, these retrospectives can become a routine activity that does not add value. By checking in frequently to discuss lessons learned, teams can quickly determine whether a product is meeting customer needs or changes they can make to their internal processes to ensure smooth delivery. 

5. The right metrics 

When measuring Agile maturity, teams should consider both hard and soft metrics. 

Hard metrics are often quantitative data that can be obtained from the tools that teams use. They include: 

  • How much work teams can deliver in one iteration, or ‘sprint’ 
  • The number of tasks teams commit to versus what they complete
  • The change in team velocity, or the amount of work that is completed over a given amount of time
  • The extent to which teams are validating the results of their work via incremental delivery and feedback loops

It is important to evaluate hard metrics over a defined period of time in order to measure continuous improvement. After collecting data for at least four to six weeks, leaders will begin to see whether a team is improving or remaining stagnant. Generally, teams that embrace Agile values deliver what they commit to and increase their velocity over time.

Soft metrics are more qualitative in nature and are usually obtained using surveys and observations. We find that high-functioning Agile teams often have:

  • A high level of trust and support 
  • A commitment to continuous learning and improvement
  • A strong sense of accountability about their work
  • Open and effective communication at all levels

An effective Scrum Master, for example, will regularly check in with the team to ask for their level of satisfaction with the project and process. High-functioning teams respect each other’s feedback, are open to discussing difficult issues, and support one another throughout the process.  From the outside, a mature Agile team will look like a well-oiled machine. Teams will be producing high-quality, innovative work that is validated in increments, and they likely will have fun doing it!

As companies continue to deploy Agile practices across their organizations, it is important to remember that it is a journey of continuous improvement. Agile is a way of thinking, and it best serves organizations when it grows and evolves with the organization’s needs. By choosing the right flavor of Agile, building cross-functional teams with clear roles and responsibilities, and practicing strong leadership from the top, companies will be better positioned to ensure that they can deliver the value that Agile promises.