Debunking Common Agile Myths

Your organization decided to implement Agile because of its proven advantages, but nine months into your implementation, teams are realizing few, if any, benefits. Is Agile just not the right fit for your organization? Unlikely. Research conducted by an Agile software producer across 160,000 projects found that Agile had the ability to cut time to market in half.¹ But that research also revealed that not fully following Agile could severely impact quality and productivity. Unfortunately, common myths and misconceptions about Agile mean that teams sometimes believe they have implemented Agile when they are still using waterfall methods. Supporting your teams to effectively implement an Agile framework (Scrum, Kanban, Scaled Agile Framework [SAFe®]) ensures that you realize the gains in efficiency, quality, clarity, and collaboration that Agile promises.

Here is a look at six common Agile myths, and how they could hold your team back from fully realizing the benefits of Agile.

Myth #1: We Are Agile if We Overlap Requirements and Development

A common misconception is that working on simultaneous activities means you are implementing Agile. In Agile, products should be broken down into smaller workable parts, called increments, that are demonstrated during every sprint review. If you are only showcasing and validating completed work when the project or entire feature is done, you will be more susceptible to excessive rework due to the lack of real-time feedback during the sprint reviews. The purpose of a sprint demonstration (demo) is to see if you are going in the right direction via frequent client feedback and confirmation. Therefore, you should be building the product in increments, and the client should be given the opportunity to see parts of the product before the full product or feature is completed, even if it does not seem ready.

While this does entail gathering requirements during development, it alone does not constitute Agile methodology. Agility comes from creating requirements focused on shippable increments or features based around user stories. These shippable increments then become the basis of each sprint’s demo. Requirements should then shift and adapt based on the feedback received. Rather than setting a goal to complete requirements-gathering as soon as possible, a team should be gathering only high-level requirements first and then refining them during development. This will ensure that the team is better able to determine the feasibility of requirements, get client confirmation on the need and priority, adjust course as needed, and focus on the development of specific parts of the product.

Myth #2: Scrum Masters Are Not Necessary

Scrum Masters (SMs) are servant leaders who are key contributors to the success of Agile teams. SMs prep and facilitate scrum ceremonies, display team progress via visualizations (charts, tables, flows, etc.) such as burndown and velocity, mitigate risks and impediments, and coach teams toward continuous improvement. Just as a coach helps a team achieve its full potential, SMs coach their programs and teams to reach their potential by adopting Agile principles and processes. This drives important feedback cycles and consistent course corrections that allow Agile projects to achieve success. Without an SM, teams may conduct Agile ceremonies, but struggle to see improved results. If there is no SM, often, the responsibilities will fall on the Product Owner or Business Analyst, which conflicts with the SM’s role, and burdens the Product Owner or Business Analyst with additional duties on top of their own roles. While a Product Owner focuses on maximizing a team’s efforts to deliver client value, an SM is focused on maximizing a team’s effectiveness to ensure successful delivery by the team.

Many projects are undertaken with the assumption that SMs are not needed, and their roles go unfilled to save money. However, if a team has been working a particular way for a long time, it can be hard to adapt to a new Agile way of working. SMs are there to guide a team and point out blind spots that team members might not be able to see for themselves.

Myth #3: Leadership Always Knows Best

Many Agile frameworks recognize that decisions are best made by the people closest to the work. One of the most important jobs of leadership in an Agile framework is to remove impediments and empower teams to do their best work. The best Agile portfolio leaders need to create an environment of trust and Agile mindsets while encouraging autonomy wherever possible.

One principle of Lean-Agile is decentralized decision-making. Leaders, therefore, should empower those closest to the work to make the decisions that affect them. Leadership should focus on making decisions on broader portfolio-wide issues and delegating where they can. One danger of leadership not adequately listening to team members is that leaders may become so focused on deadlines that they ignore the technical facts or important context. Development leads are then often afraid to speak up because leadership’s deadlines override their concerns. This often results in poor decisions that lead to technical debt or substantial rework.

Myth #4: It is Okay Not to Include Clients in Sprint Ceremonies

Management may be reluctant to request client time for sprint planning and retrospectives. However, it is important in Agile to have clients/ customers involved. If you are catering a dinner, you want caterers to work directly with you to determine what they are making, not just make assumptions and guesses about what you and your guests might want to eat. Software development is no different. You need to talk to the people who are actually going to use the software to get the feedback you need to make it right. Clients help provide business context, prioritize work, provide essential documentation and information in a timely manner, and remove impediments. Having clients engaged encourages discussion about the work and what is still needed. This can help manage the clients’ expectations and allow them to be part of the decision-making. Clients are more supportive when they are involved in the work and are given a chance to provide feedback as often as possible. This involvement helps clients feel they share in the success of the team. Including clients can yield good results in terms of understanding prioritization, business value, context, and other key project aspects.

Transparency is also a key aspect of Agile. It is important to instill transparency into a project’s culture, especially during retrospectives. There needs to be a certain level of comfort between the client and the supplier when it comes to sharing bad news and acknowledging mistakes from both ends. In fact, a true retrospective should allow all staff and clients to speak freely about any concerns, issues, or mistakes that were made during the sprint, as this helps the team improve in the future.

Myth #5: We Are Working in Sprints or Iterations, So We Are Agile

Just because your team is assigning work via sprints or iterations does not necessarily mean you are Agile. Reaching Agile maturity requires a mindset shift as much as implementation of Agile ceremonies. If you have implemented sprints but are not regularly able to deploy and demo your software (even to a test environment), then you are just going through the motions. A sprint is an opportunity to build a functional product increment or feature. This does not mean every sprint results in a product release, but rather functional parts are created and batched together for a future release on demand. This enables the client to see working software and provide feedback at the end of each sprint, as well as on the full feature or product prior to each release. Sprints should produce a completed, demo-able increment.

Some people believe operations and maintenance (O&M) work cannot be tracked in sprints as they are sporadic and unpredictable. However, it is often valuable to see the team’s entire workload on the sprint board, including O&M work. But in true Agile fashion, teams should implement strategies that work best for them. In some cases, it may make sense for Agile O&M activities to be tracked separately in a Kanban board instead of being implemented as sprints.

Myth #6: Agile Will Solve All Your Delivery Problems

Agile is not a silver bullet that will solve all organizational challenges. It is a software development life cycle (SDLC) approach that promotes better coordination, improves alignment of goals/priorities, and keeps the end customer engaged in the process. However, the myth of Agile solving all problems exists in environments as a last resort when everything else has failed. Unfortunately, there are many factors that determine whether a project will be successful or not. Some of these factors cannot be overcome by any SDLC approach. For example, Agile cannot solve lack of organizational buy-in to Agile principles and best practices or lack of involvement by the product owner, nor can it force end users to be part of the SDLC processes. However, Agile promotes co-creation and enhances overall efficiency through simple principles that require the willingness to adapt organizational processes to fit – otherwise, you will not get the benefit.

Conclusion

These are just a few of the myths that produce unsatisfactory outcomes for Agile implementations. Undertaking an Agile transformation is a challenging effort full of pitfalls and requires the empathetic understanding of the entire SDLC concept to embody the human mindset. Whether it is navigating the myriad of Agile frameworks (Scrum, Kanban), scaling your Agile implementation (SAFe, Large Scale Scrum, etc.), or ensuring that you are achieving agility instead of going through the motions, it is imperative to have a guide who has been through this before and brings the lessons learned from successes and failures to enhance the framework’s adoption process. Agile implementations should be based on proven Agile principles, with processes and actions that are tailored to your situation.

Guidehouse has a proven history of helping clients implement Agile projects of varying scopes, by conducting evaluations of existing Agile methodologies, and assisting with the adoption of true Agile collaborations while customizing them to the nature of the clients’ work. We help organizations identify which Agile myths and misconceptions are compromising their development projects and help them transform their teams to tailored Agile methodologies, so they get the best work out of their teams. We have helped a number of teams identify their main challenges and created plans for transformational change.