“We tried Agile, but we couldn’t get support from outside of our team, so it slowly reverted back to waterfall.”
Every methodology has a set of situations within which it thrives. They’re similar to plants in that you can’t put, say, a cactus down in just any soil and not without maintenance. You need the appropriate conditions in place in order to sustain life: Plants need the right amount of sunlight and water or timely attention and adjustment if external forces such as weather and insects decide to wreak havoc. Two different plants are also going to have different criteria for their care—you can’t treat an orchid like a cactus and expect successful growth. Likewise, there are environmental conditions you must consider when adopting a certain methodology, or it won’t get the support required to survive, let alone thrive.
Change will encounter only minimal resistance in certain situations, but resistance might block your efforts in others. As an agent of change for your organization’s shift to an agile approach to project management, it may fall upon you to manage the resistance. Under the right conditions, new methodologies can flourish, especially in smaller startups with little bureaucracy underfoot.
Similar efforts in more established organizations, however, may not progress as smoothly. As software consultants, we’ve seen a correlation: 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.
Creating a business case that secures buy-in
Obtaining buy-in across all levels of your organization is critical to the success of adoption. Before you can roll an Agile effort out to the company, you’ve got to roll it up and pitch it to the powers that be. Implementing an agile approach to project management won’t get very far without the proper executive support. This means drafting a business case to present to your company’s 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 your marketing department 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 king. The bottom line is often the focus, so make sure you understand how introducing agile practices to your organization will affect the 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 your approach to each team in kind. For example, if your executive team is concerned about speed, tailor your 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 your construction of a strong and viable business case for Agile Transformation.
Business case framework & questions to answer
- Situation/Context: What is the current or anticipated business situation driving your recommendation? What facts are needed to understand the context? What is the problem to be solved? Clearly state the problem.
- Recommendation: What is your recommendation? If you are bringing the topic up for consideration but do not have a recommendation, what is your clear 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 have you 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 our vision and culture? What is the opportunity you see? Based on what evidence?
- Organizational Readiness: What is going on in the organization that may impede the adoption of an agile approach to project management? Is there anything that needs to happen first to increase the likelihood of success?
- Potential Risks: What are the risks of your recommendations? (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 individual 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, decision-ing, feedback review, etc.). Make a clear request of the team—what are you asking for today?
- Vision Check: Use VTO and your culture to guide decisions. How does this tie back to our vision and our goals? Does it move us closer to where we are 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 you go, know your audience and tailor the presentation of your business case accordingly. More often than not, an executive audience will prefer brevity: direct communication of your plan without bells and whistles. If you know the executive team wants supplemental information to review at their leisure, create a business case presentation with appendix slides at the end. If some of your more detail-oriented attendees have questions during the presentation, you can jump down to these appendix slides 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 your communication rollout game
Do you remember the game Telephone? 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 he or she 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 gospel 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 the loss of valuable contextual information.
This potential communication gap is crucial. If your organization is unable to grasp the value of your rollout 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, there are some tried-and-true tactics to mitigate this communication breakdown and help secure buy-in from the start.
1. Identify Responsible, Accountable, Consulted, and Informed (RACI) roles
Note: 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-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.
2. Develop a communication plan that extends from pre-kickoff through execution
Before we go any further: Making an email list and firing off messages to everyone everywhere ever to tell them about your 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 your RACI included to be used for major announcements regarding the rollout
3. Hold a kickoff meeting, inviting everyone that you’ve identified in the above groups
This meeting will communicate reasons for implementing an agile approach to project management, including 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
4. 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 your kickoff materials (slide decks, other vital documentation, etc.) out immediately after the kickoff to all attendees
- Make sure you share any document storage locations in the Project Resources section of your kickoff materials; these could be Google Drive, OneDrive, Sharepoint, Box, or whichever local or cloud document storage solution your company prefers
- If your organization uses multiple document management solutions, pick one location only to minimize confusion, unless otherwise required by the company
All of this to say own your communication. Make it clear, consistent, controlled, and centrally-located. If you control the message and share it broadly, the risk of the “Telephone effect” impacting your 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. Your role as an agent of change isn’t to please everyone but to guide everyone through efficiently and effectively. As in the world of flora, not everything (or everyone) takes to a change of environment, and there’s only so much you can do in that situation. Understand what you can control, and manage that. As long as your plan for introducing an agile approach to project management takes into consideration the needs of the different levels of your organization and provides clear expectations for each of these levels, you have the fundamentals for success in place.