Agile Implementation: Adoption and Challenges

In many companies, it is often the case that the only practice that’s consistent is that no practice is consistently implemented. Every company, department, and team has its own internal languages and shared histories; its own ways of working that are tailored to their culture. When changes are made to these aspects of a company, which are considered inviolable— especially when instituted abruptly or without the right planning and communication— the results can range from unfortunate to disastrous. More often than not, the process itself is implicated.

What people forget in the aftermath is that the process doesn’t choose itself: companies create these environments, and make the decisions that lead to these results. The methodology chosen might not work out, but is it because the practices themselves are terrible, or because the wrong fit for a given project or company is implemented? Agile methodologies frequently become the scapegoat for any number of failures, and as a result, “Agile” is determined to be the problem.

Here, the aim is to identify and explore the most common explanations companies give for Agile failing upon arrival, and uncover potential root causes for a company’s split from Agile. As mentioned earlier, no practice is truly consistent between organizations; it’s nearly impossible to drop any major operational change on a company and expect it to be implemented flawlessly without taking this into consideration.

Challenge 1: Lack of organizational support for implementation of agile practices
Challenge 2: Ineffective or poorly-attended Agile Scrum team meetings

Challenge 1: Lack of organizational support for implementation of agile practices

Every methodology has a set of situations within which it thrives. As such, there are environmental conditions within an organization to consider when adopting a certain methodology. Otherwise, these changes won’t get the support required to survive in a company, let alone thrive.

Under the right conditions, new methodologies may easily flourish, such as in smaller startups with little bureaucracy underfoot. Similar efforts in more established organizations, however, may not progress as smoothly. The larger the organization, the more complex the politics, and the more deeply ingrained pre-existing ways of working. For example, sharing information and setting expectations is undeniably simpler in a company of 10 working together in a single room than in a company of 100 spread across four globally-distributed office locations.

As agents of change for an organization’s shift to agile practices, it may fall upon team leads and managers to handle resistance to change, and secure the critical executive support necessary for success on a larger scale.

Creating a business case that secures buy-in

Obtaining buy-in across all levels of an organization is critical to the success of adoption. Before rolling an Agile methodology out to a department or an entire company, teams must first roll up an overview of key benefits and pitch it to the powers that be. Any implementation of Agile won’t get very far without proper executive support. This may mean drafting a business case to present to department or company leadership on the benefits of an agile work environment, holding frank Q&A sessions with teams to help them better understand how their day-to-day might change, and/or involving the marketing and sales teams early to ensure their strategies are properly aligned with the chosen methodology.

When pulling together any business case, the questions “Why?” and “How much?” are critical. The bottom line is often the focus, so make sure it is understood how introducing agile practices to an organization will affect budget, productivity, and other projects currently underway, both in positive and negative ways. As in any appeal, take the time to understand the values, needs, and concerns of each team affected and structure the approach to each team in kind. For example, if the executive team is concerned about speed, tailor the business case to include ways in which an agile workforce can execute and provide gains to the business quickly.

Here’s a framework to guide the construction of a strong and viable business case for Agile Transformation.

Business case framework & questions to answer

Situation/Context: Clearly state the problem. What is the problem to be solved? What is the current or anticipated business situation driving these recommendation? What facts are needed to understand the context?
Recommendation: What is the recommendation? When presenting a major change for consideration without a clear recommendation, the audience will not be clear on the request.
Benefits: What are the likely benefits? Again, based on what evidence and/or research from authoritative sources?
Impact Analysis: Who will be impacted if/when this recommendation is implemented? What are the anticipated impacts? What has been done to date to inform key stakeholders? Is there a financial impact? If so, how much?
Opportunity/Problem: Start with “Why?” Why is this important as it pertains to the vision and culture? What is the opportunity? Based on what evidence?
Organizational Readiness: What is going on in the organization that may impede adoption of the recommendation? Is there anything that needs to happen first to increase the likelihood of success?
Potential Risks: What are the risks of recommendations being presented? (There are ALWAYS risks!)
Resource Requirements: What resources will be needed for this recommendation? (Budget, time, staffing, etc.)

Proposal to the team and plan for execution

Timeline: What is the projected timeline of events and milestones?
Up Front Contract: The team member bringing forth the business case should state the purpose and outcome of the presentation upfront so that those listening know what the specific ask is. (i.e., inform, update, decide, feedback review, etc.). Make a clear request of the team: what is needed today?
Vision Check: Use company vision, mission, and culture to guide decisions. How does this tie back to vision and goals? Does it move the company closer to where it is going?

Business cases themselves are often highly specific and detailed, but the presentation of the information is usually set at a higher level. No matter which route is taken, know the audience and present the business case accordingly. More often than not, an executive audience will prefer brevity: direct communication of a plan without bells and whistles. If it is known that the executive team prefers supplemental information to review at their leisure, create a business case presentation with appendix slides at the end. If the more detail-oriented attendees have questions during the presentation, appendix slides can then be referenced as needed.

With these thoughts in mind, take note: Nothing will kill the adoption of Agile, or any major organizational shift, faster than a poorly-executed and under-communicated rollout, regardless of a company’s size or distribution. Not only will a failed Agile rollout flatten any present efforts, but it will likely poison the well for future attempts.

Up that communication rollout game

Many remember the game Telephone from childhood: one person thinks of a phrase and whispers it to the next person in a line, and so on until the last person in the line relates the phrase as they heard it. More often than not, the phrase is distorted, and frequently into something not even remotely resembling the original. More devious participants may intentionally change the statement into something they prefer instead (for shame!). Others may just forget portions of the phrase and pass on only what they remember, or paraphrase and include only the portions they believe to be critical.

Many encounter this exact scenario in their careers: a plan is delivered to a small group from on high, which cascades down as a mandate delivered from person to person throughout the company. Department leads may not share the message because they’re on vacation and forget, or they may change the message to suit their own initiatives, omitting parts with which they don’t agree. Others may paraphrase in an attempt to be helpful and succinct, which can lead to loss of valuable contextual information.

This potential communication gap is crucial. If an organization is unable to grasp the value of implementing Agile because necessary team members (or worse, entire teams) aren’t provided with consistent messaging and information, there’s bound to be confusion and resistance. However, these are some tried-and-true tactics to mitigate this communication breakdown, and to help secure buy-in from the start.

Identify Responsible, Accountable, Consulted, and Informed (RACI) roles

The roles within an organization to be included in a RACI matrix may vary from one implementation to the next, but often include members of software development or engineering teams, R&D department members, and executive team, depending on the breadth and scale of the rollout.

Form a RACI matrix in a spreadsheet, with roles as column headers and critical pre- and post-Agile methodology rollout actions as row headers
Mark each box of the grid as it intersects with a role and an action with an R, A, C, or I depending on the appropriate level of communication for that individual

Develop a communication plan that extends from pre-kickoff through execution

Making an email list and firing off messages in an uncoordinated frenzy about the rollout is not a communication plan. Effective communication plans should include the following:

Individuals to be contacted, and by what means, with their current roles
Circumstances under which they should be contacted, including a meeting plan with regularly-scheduled touchpoints
Acceptable and unacceptable communication formats, styles, and channels, based on the teams and organization
Project meetings, with frequency, expected attendees, and purpose detailed for each
Clear guidelines for project issue escalation
One master mailing list with all levels of the RACI included, to be used for major announcements regarding the rollout

Hold a kickoff meeting, inviting everyone identified in the above groups

This meeting will communicate reasons for implementing agile practices, roles, and responsibilities, and team member expectations for execution. Review the following items, at minimum. Typically, this is pulled together into a short slide deck and shared in an all-hands for the project team:

Project History: Background and reasons behind the rollout initiative
Project Objectives and Goals: Desired purpose and outcomes of the rollout
High-Level Scope: Outline of work to be done to support the rollout
Timeline and Milestones: When the work can be expected, and by which deadlines
Expectations for Communication: What, when, and how key information will be shared
Team Org Chart: Names and roles for all individuals involved in the rollout
Project Artifacts: Links and shared resources the rollout team will need
Known Project Risks: Potential impediments and their planned mitigations
Questions, Comments, and Actions: Feedback from the kickoff attendees

Put everything in writing, and share it with RACI groups via a central location In addition, make sure to do the following:

Send a copy of any kickoff materials (slide decks, other vital documentation, etc.) out immediately after the kickoff to all attendees
Ensure document storage locations are noted in the Project Artifacts section of the kickoff materials; these could be Google Drive, OneDrive, Sharepoint, Box, or another shared on-premises or cloud document storage solution
If an organization uses multiple document management solutions, work with your company to select the preferred document storage solution and file location

All of this to say own these communications. Make them clear, consistent, controlled, and centrally located. By controlling the message and sharing it broadly, the risk of the “Telephone effect” impacting an Agile implementation rollout is sure to be significantly reduced.

Not everyone will be thrilled with the organizational change, but the beauty here is that not everyone has to be thrilled. The goal isn’t to please everyone, but to guide everyone through efficiently and effectively. Not everyone takes to a change of environment, and there’s only so much to be done in that situation. Understand what can be controlled, and manage that. As long as the plan for introducing Agile takes into consideration the needs of the different levels of a given organization, and provides clear expectations for each of these levels, the fundamentals for success are in place.

Challenge 2: Ineffective or poorly-attended Agile Scrum team meetings

The intent of adopting Agile is not to go through the motions of Agile ceremonies for the sake of doing so. Instead, the intent is to enable teams to choose which methods work best for them, once equipped with different options and guidelines that can boost productivity depending on the situation, and let them move forward as they see fit. One of the core values of Agile is, “responding to change over following a plan”. If there are too many meetings, meetings are too long, people aren’t attending, or the meetings aren’t productive, question the practices in place to ensure they’re the right fit for the team before taking any other actions.

Tips for Sprint Planning

Using sprint planning as an example, the prevailing guidance for Scrum teams is generally to hold planning once a sprint, timeboxed to eight hours per one-month sprint. That doesn’t mean sprint planning has to be eight hours long just because it can be, and certainly not if running a shorter sprint cadence. If sprint planning has turned into a rote review of team tickets while the team itself sits silently by, work with the team to form a better communication strategy.

CONSIDER the following:

What does the team actually need to get out of sprint planning?
Would time be better spent in advance breaking down features, either solo or in one-on-one conversations?
What format works best for the team, while providing the necessities to work successfully?
If the team and project don’t require the boundaries of set sprints, why follow Scrum? Why not consider a more flexible Kanban (pull-based) workflow?

If external business pressure, the needs of leadership, or input from stakeholders indicate a specific Agile method might be better, are all parties aware that the chosen course might not be the right one for the team? Make time to discuss these preferences, and be sure to bring evidence as to how a different path may produce more fruitful outcomes. Remember, imposing unnecessary ceremonies on a team will only slow them down, frustrate them, and keep them from finding the pace that works best for them.

Tips for Standup / Daily Scrum

Another common meeting is daily standup. This ceremony of Scrum keeps everyone on the same page with work-in-progress and provides a forum for airing and addressing impediments to said progress. If team standup meetings are turning into drawn out, sit-down sessions, the team lead should dig into potential reasons why before removing them altogether.

CONSIDER the following:

Does the standup meeting have a set agenda?
If so, is someone on the team ensuring that agenda is followed?
How many people are attending standup?
If guests are attending standup that aren’t on the team, are they aware that their role is that of an observer first?
Is everyone on the team able to get through their own standup items, and are tangents put on hold for follow-up after the entire team has gone?

When meetings become inefficient, remember this: Agile Scrum ceremonies are for the benefit of, and owned by, the team. As such, the team always has the power to change their format.

Tips for maintaining engagement in Scrum team meetings

Setting expectations for participation is a critical step. Ignoring this can turn a 15-minute rundown into an extended tangent, leaving everyone feeling unheard and irritated. Some do’s and don’t that may reignite the value of daily check-ins:

DO listen to team members and their needs

DO align with leadership on delivery expectations and practices (see Challenge 1 above!)

DO work with the team to refine practices, and revisit regularly

DO plan an agenda, and stick to it

CONSIDER inviting only those necessary (notes may be shared with interested parties upon request)

AVOID meetings that provide little-to-no team value

AVOID continuation of ineffective processes solely for the sake of appeasing leadership

AVOID mandating that the team work in ways that ultimately slow them down

AVOID letting meeting topics run wild; keep it short, sweet, and simple when able

Doing the same thing over and over again and expecting a different result each time is the definition of insanity, not to mention folly. Much like throwing good money after bad, it’s only going to drain the company’s wallet, and the confidence of the team in their team leads. Don’t waste the team’s valuable time on a process that’s clearly not working instead of taking that time to find out what does work. Take the time to build that confidence by listening and adjusting, by being agile in everyday actions, and teams in an organizations will surely work together more efficiently and effectively.