Overcoming Common Agile Implementation Pitfalls

Over the past two years, organizations of all types and sizes have adopted the agile methodology for the delivery of projects in some or all of their programs. While many are recognizing successes and tangible improvements from agile software development, many others are either struggling with their implementation of agile practices, or are simply not reaping the benefits that they could and should. In our experience, there is no “one size fits all” agile approach or implementation, and it is important for organizations to recognize that fact and adjust how you use agile to fit your programs and your processes. Also key is setting realistic expectations and defining specific goals for your agile adoption, and not simply expecting agile to solve every challenge or struggle you have in your software development process. Through your agile implementation planning, we encourage you to be cognizant of a handful of common pitfalls that we have seen contribute to marginalizing our clients’ agile implementation success.

Agile in name, not in practice

Agile is a cultural shift, and it does not happen overnight. It takes a well thought through plan to successfully migrate to using agile. Far too many organizations are effectively just putting an agile label on their mostly waterfall methodology, and not truly embracing the change. In order to reap the benefits of agile, you need to commit to and focus on adopting its fundamental principles and putting them into practice. Specifically, achieving continuous value delivery throughout every aspect of your project, and ensuring that all of the activities that your teams are performing are contributing to adding value and delivering a better product. Changing processes and procedures can be uncomfortable and challenging; but really taking the time to consider how you could adapt and change your legacy requirements and processes to be more agile can enable your organization to actually deliver with a more orthodox agile methodology and achieve the continuous value that it is intended to deliver.

Key resources not dedicated and roles not well understood

Agile as a methodology cannot work without the people in place to execute it. The Agile Manifesto reinforces this by stressing “Individuals and Interactions.” There are three specific roles in an agile delivery team – Product Owner, Scrum Master, and “the team” – and each need to have both a clear understanding of their responsibilities, and to be dedicated to a single agile team if possible.

Product Owner: The most common issue we have seen with regard to the Product Owner (PO) role is the PO being responsible for other, ongoing “full time” tasks, in addition to his agile responsibilities. When the team needs a clarification or prioritization decision, often the overburdened PO is unavailable. Other product owners also struggle with the concept that their role is that of the single sign-off and decision-making authority, and thus if they need to enlist feedback from others within the organization, they need to do that in advance of when decisions need to occur.

Scrum Master: For the Scrum Master, dedication issues can arise when organizations ask a team member or a product owner to simultaneously play the scrum master role. Scrum masters have unique responsibilities, and ideally should be distinct from the Product Owner and “the team.” The scrum master role requires an individual who can facilitate the team’s progress and tempo, shield them from interference, and work across stakeholders and with the product owner to set project direction. For organizations indoctrinated in the waterfall or other non-agile methodologies, this shift from a work management role to a work facilitation role can be a difficult cultural adjustment.

“The Team”: The biggest issue we see with ‘the team’ is not having core resources fully dedicated to one agile team. In reality, there will be resources whose roles are to support multiple teams, given their individual contribution type or skill; the key with these resources is to manage the dependencies across teams so that each team is getting the involvement they need and plan for. When creating your core teams, building a cross-disciplined team (covering all core technologies) is ideal, but often when organizations have one or a few individuals with a unique skill set, they tend to ask them to spread time across teams within a given iteration. Dividing key resources across multiple agile teams at once could result in the following adverse effects:

  • Teams are unable to properly estimate velocity, as they don’t get the benefit of consistent presence and team member continuity;
  • Teams plan for or commit to work that they are unable to accomplish in a given iteration because the resource is not available or gets pulled into another effort;
  • The morale of the overstretched resources suffers, as they are not benefitting from the team atmosphere that agile fosters, and may feel over-utilized with multiple priorities always in front of them.

Organizations adopting agile should strive for dedicated core resources as much as possible —as we have seen, a focused, full-time product owner, a scrum master skilled in facilitation, and a committed, autonomous team are vital to agile success.

Inadequate sponsorship and stakeholder engagement

Agile promotes collaboration and engagement across the organization in order to ensure that the highest priority, highest value work is accomplished first, and that the right people are available when needed to support that work.

Given the magnitude of the cultural shift to agile from other methodologies, stakeholders from throughout the organization must commit to and sponsor the move to agile. They should be “on board” and supportive of the new methodology, and take tangible steps to foster the potential process and technology changes necessary to make agile successful. Examples include supporting the modification of the gate review/approval process, promoting technology changes to support continuous integration, and understanding and adapting to the differences in levels of forecasting and reporting that the agile process can and should provide. Securing executive sponsorship up front is also critical to setting the right product vision and shaping the initial scope and goals of the agile program. These examples also further illustrate the need for proper stakeholder and executive expectation setting up front about what it takes for an organization to fully and successfully adopt agile, so that once the agile train starts moving, it does not derail because of avoidable concerns.

Furthermore, taking the time to properly educate stakeholders at the outset of any new agile implementation will help ensure that everyone in the organization not only knows what agile is, but also and more importantly understands why you are doing it, and what their role is in the new method. Providing this level of understanding will help promote agile adoption.

Ceremonies not being properly executed

In any methodology, there are a number of phases, processes and procedures that define the execution framework, and agile is no different. Understanding the framework itself is key, but more importantly, you need to understand and value why each step or ceremony is part of the methodology, and use that understanding to effectively leverage that methodology. In our experience, there are certain agile “ceremonies” or steps that are often neglected, leading to unattained value:

  • Daily stand-up meetings: Too often, teams use this meeting to report status, because they are so used to status meetings from previous projects and traditional methodologies. This meeting is in fact not intended to be a status meeting, and its purpose is actually for the team to communicate with one another, not to provide status externally. Discussion in this meeting should be from the team, and only focus on answering three questions: what did I complete since the last meeting, what am I doing today, and do I have any obstacles that I need help removing? Furthermore, any issues or problems that are raised should not be solved during the meeting; team members should determine a time after the meeting to further discuss.
  • Sprint Retrospectives: The issue we have seen with the sprint retrospective is that its value is often overlooked, as teams are already looking ahead to the next sprint and do not see the benefit of spending time to conduct the retrospective. In reality, this is a key ceremony and an enabler of the important “inspect & adapt” principle of agile. This meeting is a time for the team to discuss what went well and where there may be room for enhancements or changes, so that they are continuously improving sprint over sprint, and furthering the achievement of value through their agile delivery.

It is important for organizations that have adopted agile to realize that these and other agile “ceremonies” are not simply empty rituals, but are an integral part of agile success and are rigorously followed by successful teams.

Not properly scaling the methodology

Most of the available agile scrum training and guidance is focused on how to effectively operate a scrum team or run an agile project. However, recently we have been engaged with many clients that really require more of a program-level agile guide, which recognizes the importance of integration across multiple concurrently running agile teams, the need for common and centrally-defined architecture, and aligned release milestones. Without this program-level agile framework, your organization may have highly performing individual agile teams, but still not be able to deliver the tangible value earlier because of lack of alignment across teams, missed dependencies that cause feature delivery delays, or the creation of technical debt realized from the lack of consistent and well-thought out architecture.

To mitigate these concerns, we have leveraged the concepts and methodology prescribed by the Scaled Agile Framework (SAFe), which stresses the recognition of Enterprise, Program and Team level agile adoption and processes. One of the key elements of the framework that we often see organizations overlook is the need to create a program vision and product roadmap, as well as to define incremental releases and feature sets. Establishing this definition up front helps deliver tangible value earlier to stakeholders, because it aligns work across agile teams to a unified feature set and sets the vision for all teams together, as opposed to individual goals.


We strongly believe that the benefits of agile are only realized if you implement it in a way that will work for your organization, reflecting your culture, your people, your technology, and your processes, and at the right time, with the necessary support and plans in place. To help you realize these benefits, we also suggest that organizations consider enlisting the help of a third party expert to provide an agile assessment or capabilities workshop to help your organization avoid some of the pitfalls we explained here, and to sure up your framework for agile success.

At TeraThink, we bring a wealth of experience and expertise implementing technology solutions using both traditional waterfall and agile approaches. We are also helping organizations determine the right agile approach for them, and helping them to course correct their waterfall to agile transitions in a successful manner. We bring seasoned personnel, including many certified scrum masters, to address our client’s implementation needs. To see how we can help you, contact us today.

[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]