Epic 3: Determine Organizational Readiness

Contents

The Epic

As the stakeholders of the potential change, we want to determine if the organization is capable of and ready for Agile, to prevent wasted time and lost goodwill if not.

Drawing of a medieval knight on a horse ready to joustThe Standard for Change Management from ACMP explained that an organizational readiness analysis “assesses the preparedness of the conditions, attitudes, and resources needed for a change to happen successfully.”[1] This analysis determines whether current factors internal and external to the organization make Agile feasible, and/or gaps that should be closed before making the attempt. As listed earlier and detailed in this epic’s stories, a wide range of factors both in and out of the control of an organization can make or break organizational change (OC) efforts. Given the costs of OC in time, money, and psychological effort, it makes no sense to start that effort if there is little chance of success. Besides those risks, you will create resistance and dissatisfaction that reduce the likelihood of later success with Agile or any other change.

If you haven’t dug deeply into Agile methods yet, this is the time. Read a couple of books on different methods; the Agile Alliance (for software only) and Scrum Alliance sites; and, I humbly suggest, this FuSca site, in their entireties. (Instead of listing this as a task, make it a blocker that must be cleared before you start the gap stories like US 3.2.) Then in this epic, use document reviews and interviews to get current-state information to compare to what you’ve learned.

The primary output of this epic is a “go/delay/no-go” decision on whether you will attempt to get leadership agreement to become Agile. Given evidence that Agile firms outperform non-Agile ones financially, and that most projects bear the characteristic of high uncertainty that suggests the use of Agile, the answer probably should be “go.” Unfortunately, that does not mean the organization is ready at this time. In most cases, the gaps between what would make the organization fully successful and where it is at the moment need not stop the transformation: Any project has risks that must be addressed. However, if the sum of those gaps indicate the transformation is likely to fail, and closing them will take a long time, you are better off delaying further consideration of Agile. Instead seek process improvements within your current work management approach and work to remove the deal-breaker gaps.

In talking with people in the “interview” tasks below, pay attention to patterns of differences between line workers and each level of manager. If people have opinions similar to their peers but different from those on other levels, this can become a significant source of RTC.

Per the Agile Manifesto’s call to minimize documentation, this should not be a massive text-heavy document. The backlog spreadsheet specifies that each section produced per these user stories should only be a couple of pages, and can just be bullet lists. The point is to think through these issues and, if needed, create new stories to address the gaps you identify.

User Story 3.1: Review Change History

As the change leader, I want to understand the organization’s recent history with organizational change, to determine what kinds of resistance might result.

Organizational change requires people to challenge their own beliefs, break old habits, fight for preferred alternatives, and learn new skills. It takes significant personal effort, in other words. “Change fatigue” arises when there have been so many process, structural, and/or tool changes in an organization within recent memory, people resist a new change just because they are tired of changing. Workers and managers who have gone through a lot of change may resist Agile even if they like it, whether or not those changes were successful. Unsuccessful change efforts make change fatigue worse.

Survey the history of change in your organization over the past 10 years by searching for relevant documents in the Intranet or share drives. Even if you are a veteran of the firm, you may not be aware of changes people in other groups tried. Also ask longer-tenured line workers and middle managers what changes were attempted, and how they were implemented. Pay attention to how people talk about the change efforts, and ask whether those changes brought results people liked.

You will have to use your judgment, but generally if:

  • People complain about the pace or frequency of changes, consider delaying the Agile transformation, and openly address change fatigue if you can’t delay (due to an external threat, for example).
  • Previous efforts did not bring positive measurable results and please people, be ready to address why that happened and why this effort is more likely to succeed.
    Tip: Many changes fail due to poor or partial implementations (see “Trying the System”), and also refer back to “Sources of Resistance and Failure”).

This story delivers one section of the organizational readiness analysis. Produce a one- to two-page text or list summarizing:

  • The change initiatives and their results.
  • The collective opinion of whether they were implemented correctly.
    Tip: If those initiatives didn’t follow an approach like the one in this backlog, or took only partial steps, that is evidence of a poor implementation.
  • Your recommendations regarding problems that might arise due to change fatigue, if any.

As already stated, an iterative approach means you should produce as complete a draft as you can, proofread and ready to show your “customer”—the project sponsor—at the end of the sprint.

Suggested tasks:

  1. Search for documents indicating changes in the organization over the past 10 years, including org charts and job titles reflecting structural changes.
  2. Interview a selection of line workers and managers at different levels to ask about previous change efforts and the results (both measurable results and satisfaction levels).
  3. Write a short section summarizing your findings for the readiness analysis.
  4. Write user stories for this or other epics to address those problems in case the transformation goes forward.
  5. Publish the document.

User Story 3.2: Perform Structural Gap Analysis

As the change leader, I want to understand at a high level how our organizational structure might limit Agile success, and what structural changes might be required to gain maximum benefits.

“Structure” includes at least: legal structure (partnership, corporation, nonprofit organization, government agency, etc.); functional silos vs. strong matrix vs. weak-matrix; number of management levels; manager portfolios (what managers control), and spans of control (how many direct reports they have); stability and cross-functionality of team membership; and the team leadership model.

Taken together, these sections of this site detail an ideal structure for Agile:

Read through these and compare them to your current organizational charts and roles (not necessarily job titles). Some of the questions you’ll need to ask are:

  • Does every small group/team have a team leader? If so, is that person generally more of a project manager, a functional leader, or something else?
  • Who provides customer/business/user and other requirements?
  • Are teams cross-functional, and better, full-stack?
  • Do teams have stable, full-time membership, or do they instead get re-formed for each project and/or share members across teams?
  • Do people direct-report to the team leaders, or to functional managers?
  • Does anyone outside of the work teams provide architectural direction, work standards, etc.?
  • Is there a Project/Program Management Office (PMO) invested in waterfall?
  • How might the myth that Agile is only for software cause resistance to restructuring of non-software units?

The organizational structure does not have to be perfect for Agile to succeed. In fact, most implementations start in siloed organizations with traditionally managed teams. Your primary focus is what must change, before or during the transformation, for any system of Agile to succeed.

You’ll see that the first couple of tasks overlap with those of the previous story and some of the later ones—that is, the information-gathering and write-up tasks are essentially the same. Clearly it will make sense to do similar tasks at the same time, by searching for all the document types you need at once and by combining questions from different stories into the same interviews, so you don’t have to bother people twice. I usually complete the entire analysis draft within one month working on it nearly full time, so even if you have less experience as a coach and work on it part time, completing a few stories/sections at once shouldn’t be a problem.

Suggested tasks:

  1. Read the relevant FuSca site sections and write questions about your organization’s structure.
  2. Obtain the most current copies of the organizational charts, project management policies, and other related docs.
  3. In interviews with workers and managers, ask the questions above and others you identified.
  4. Add a short section to the readiness document summarizing gaps between the current structure and the ideal future state, and the steps required to close them.
  5. Write user stories for this or other appropriate epics to address those gaps.

User Story 3.3: Perform HR Gap Analysis

As the change leader, I want to understand at a high level what changes to human resource practices might be required to implement Agile, to help determine the likelihood of success.

Human resources (HR) practices include at least: hiring, onboarding, performance management and evaluation, compensation, and termination practices. In addition to the FuSca sections listed under US 3.2, the section titled, “Re-focusing on Team Performance” provides other Agile ideas that may be hindered by HR policies and practices in your company. If corporate policy mandates performance evaluations and compensation based solely on an individual’s performance measures, you may have to work within those parameters over the short term while trying to reform them. Talk to the highest-level person you can who is responsible for HR in the organization to find out how things are done now and what is possible to change fairly quickly.

Don’t be afraid to test the boundaries, to look for ways to achieve what you need within current constraints. I have often found “wiggle room.” For example, state governments tend to have highly prescribed performance management and compensation systems individual agencies cannot change. Yet when performing this investigation at one agency, I found out managers had considerable discretion in setting objectives for individuals. We could, for instance, use the same team- or agency wide metrics as objectives on each individual’s performance evaluation, and nothing prevented us from requiring supervisors to create objectives based on 360-degree survey results. Also, supervisors had to both initially screen and have the final say on job candidates. But teams could still do most of the hiring work, and only giving the supervisor veto power was sufficient for the approval requirement.

Suggested tasks:

  1. Read the relevant FuSca site sections.
  2. Review HR policy documents or internal sites.
  3. Interview an HR leader to provide an Agile 101 summary, identify gaps between current practices and the ideal ones, and ask what changes or compromises are possible.
  4. Add a short section to the readiness document summarizing gaps between the current HR policies and the future state, and steps required to close them.
  5. Write user stories for this or other epics to address those gaps.

User Story 3.4: Perform Sales/Marketing Gap Analysis

As the change leader, I want to understand at a high level what changes to sales and marketing practices might be required to implement Agile, to help determine the likelihood of success.

Companies that sell consumer products and services only offer what exists today. In terms of features, the potential buyer judges exclusively on the product or service as it is. Even for consumer electronics and automobiles, producers would rather sell you a current version than risk your buying a competitor’s, at least until a newer version is almost ready for release. For most items, marketing therefore emphasizes the current offering. Sales are made and commissions are earned based, again, on the existing feature set.

In other types of firms, the customer is exposed to a schedule for future products or features to induce them to buy. The more that is true for your organization, the more the “Waterfall Myth” complicates your life. Customers of research and development projects have been misled into believing someone can tell them when a new product version or software feature (or house) is going to be finished. In turn sales and marketing professionals have been taught to make promises along those lines to increase their results. Worse, they often get paid for convincing people those impossible promises will be met, and worst of all, sometimes parts of sales commissions are based on meeting delivery dates with specified features—something completely out of their or anyone else’s control.

For organizations in this kind of market, a switch to Agile can create significant interface conflicts with Sales and Marketing departments. You must change the worldview not only of those professionals but of customers as well. All must be convinced that predictions of scope, time, and budget only reduce customer happiness, and the Agile approach will increase it because that is the primary focus (see “What Customers Really Want”).

In a large company dependent on delivery of new features to compete, Agile may be impossible over the foreseeable future. I speak not about what should be possible, but of what is possible. (Agile would help that large corporation and its customers, but the change could require a generation of management changeover in both, given how slowly other best practices have spread and how many minds must be changed.)

For this story, identify first whether salespeople and any managers have a financial incentive to promise deliveries of new features at set scope, dates, and/or prices. If so, this will be a major barrier to success. A lesser barrier is working in an industry where people expect such estimates, but these are not included in contracts, and compensation isn’t tied to them. Here an Agile approach can actually be a differentiator giving your company a competitive advantage (“We’re the only company that won’t lie to you about dates, instead giving you control over your project and delivering ‘the right thing done right’”). Regardless, you will likely need to build methods by which customers participate more actively in project planning and sprintly demonstrations, if not sales representatives.

Find out from a leader in the Sales organization:

  • What performance metrics are used for evaluations of and commissions for salespeople.
  • What messages are given customers regarding budget, cost, and scope of purchases that require changes to your products or services.
  • Whether these are included in contract language.
  • Whether any executives’ bonuses are tied to these.

From a Marketing leader, find out about pricing models, marketing materials, and the general strategy for increasing demand. The more these emphasize future features, the more changes would be required by a switch to Agile.

Suggested tasks:

  1. Interview a Sales leader to provide an Agile 101 summary and determine potential barriers.
  2. Interview a Marketing leader to provide an Agile 101 summary and determine potential barriers.
  3. Add a short section to the readiness document summarizing gaps between the current practices and the future state.
  4. Write user stories for this or other epics to address those gaps.

User Story 3.5: Perform Finance Gap Analysis

As the change leader, I want to understand at a high level what changes to finance practices might be required to implement Agile, to help determine the likelihood of success.

The “Agile Budgeting” section discusses approaches to organizational and project budgeting supportive of iterative development. As explained there, in one sense project budgeting is much simpler under Scrum or Kanban, but getting people who are accustomed to thinking of budgets as “commitments” to instead consider them “initial educated guesses” can be difficult.

Organizational as opposed to project budgeting is less likely to be impacted by Agile, unless individual projects are large enough to directly influence quarterly forecasts released to shareholders and analysts. When part of an executive’s compensation is based on hitting arbitrary revenue figures, and only two or three project deliveries make up most of those revenues, that executive is likely to push for deliveries regardless of how complete or tested they are.

Another potential issue is labor hours. Many waterfall companies insist on tracking how people use their time, as a billing or accounting tool when individuals work on multiple projects, or to make people prove they are filling up their working hours with productive work. This practice is strongly opposed by the Agile philosophy, as shown by principles focusing on “working software” and trusting people to get their jobs done. FuSca in particular has another way to prove people are working at full capacity (to get skeptical stakeholders off their backs) without tracking how hours are actually used, and one for billing based on weekly team costs instead of hours.

To summarize, Finance practices that could cause issues or need to change include:

  • budgeting (organizational and project-level),
  • accounting,
  • financial performance metrics and requirements, and
  • shareholder communications.

Suggested tasks:

  1. Review the “Agile Budgeting” section.
  2. Interview a Finance leader to provide an Agile 101 summary and determine how budgeting or time tracking might need to evolve in an Agile environment.
  3. Add a short section to the readiness document summarizing gaps between the current practices and the future state.
  4. Write user stories for this or other epics to address those gaps.

User Story 3.6: Perform Legal Gap Analysis

As the change leader, I want to understand at a high level what changes to legal practices might be required to implement Agile, to help determine the likelihood of success.

Most issues related to employment laws and contract terms will be covered by the previous conversations with HR, Sales, and Finance. Changes to those practices could require revisions to employment agreements and customer or vendor contracts. For example, standard customer contracts might need to change to eliminate hourly cost accounting.

As for vendor management, in the ideal scenario your supply chain follows Agile practices that let you interact with those companies as if their teams were just extensions of your organization. However in many or most cases, you will have to cope with suppliers that are stuck in waterfall, unless you represent enough of their business to catalyze changes. (The easiest way to cope is to treat their deliveries as blockers, ignoring whatever dates they promise and doing other work until they make the delivery at the quality you need.) In any of these cases, standard vendor contract language may need to change. See “Agile Contracts” for a model that can work for both customers and vendors.

The Legal Department also may be aware of implications Agile has for investor relations, agency/nonprofit charters, bylaws, and so on. None of these should be blockers, but stories will be needed for considering any changes the lawyers recommend. Specifically, ask what contract language changes might be required, specifying gaps identified in earlier stories of this epic as well as any other potential legal concerns.

Here someone in a highly regulated industry might espouse one of the biggest myths about Agile, that it is somehow incompatible with that kind of market. There are many examples of companies in those spaces using Agile. I worked at the most regulated of facilities, a nuclear weapons laboratory, and instituted many of the team and work management principles now identified as “Agile” with no regulatory issues (and amazing results). If you hear objections along these lines, demand specific examples of problems the individual perceives, not just generic statements that Agile “won’t work in our industry.” (For more, see: “Will Agile work in regulated industries?“)

Suggested tasks:

  1. Interview a Legal Department leader or the company’s outside counsel for contracts to provide an Agile 101 summary and determine potential barriers.
  2. Add a short section to the readiness document summarizing gaps between the current practices and the future state.
  3. Write user stories for this or other epics to address those gaps.

User Story 3.7: Review External Constraints

As the change leader, I want to understand what external factors might impact the adoption of Agile, so any risks can be addressed in the change project.

As implied in stories above, external forces can make Agile transitions more difficult even if outsiders are not aware of the change. This story is mostly a “catch-all” for any external influence not already identified in this epic, intended to make you think through any other external constraints. I do not believe these should be allowed to prevent a company from operating as efficiently as possible, hence the purpose listed in the story statement, but the effort to address them could inform your decision.

As summarized in the spreadsheet, constraint types include at least:

  • Vendor management practices, from requirements planning to project management to delivery methods and standards (like fitting in user acceptance testing of vendor deliveries).
  • Customer willingness to change how they interact with your company, if required.
  • Current contracts (as opposed to standard language that is the main point of US 3.6), whose terms must continue to be met even if the other party is willing to change them in the future.
  • Expectations of the owner(s), shareholders, market analysts, lenders, venture capitalists, board of directors, etc.
  • Certification bodies, such as Underwriters Laboratories or those for ISO, CMM, ITIL, etc.

Suggested steps:

  1. Review the readiness assessment draft and try to identify unaddressed external constraints that could possibly impact the success of an Agile transformation.
  2. If needed, interview internal experts related to those constraints to provide an Agile 101 summary and determine what steps must be taken to mitigate any barriers.
  3. Add a short section to the readiness document summarizing gaps between the current practices and the future state.
  4. Write user stories for this or other epics to address those gaps.

User Story 3.8: Perform Process Gap Analysis

As the change leader, I want to understand at a high level what process changes might be required to implement Agile, to help determine the likelihood of success.

This story gets into the organization’s core work management practices. In the current and the future states, how are requirements identified, prioritized, distributed among workers, estimated, scheduled, supplied inputs, tracked, changed, quality controlled, tested, and delivered? Even limiting each answer to one or two pages, this will become the biggest part of your analysis.

You may need to break this story down into several more specific areas to fit each into one sprint. For instance:

  • You may need to talk to Product Management about requirements gathering and communication.
  • In a siloed organization, Quality Assurance and other departments could disappear, so that will be a critical conversation.
  • Similarly, the architects may be a separate team accustomed to completely detailing a system architecture document and handing it off as a fait accompli, instead of co-evolving the architecture with the R&D teams.

In each case, you’d be better off creating a separate story and set of tasks to ensure complete coverage.

Suggested tasks:

  1. Review procedure documents and workflow diagrams regarding how work is identified and accomplished currently.
  2. Interview internal experts related to those materials to provide an Agile 101 summary and identify details regarding potential changes required.
  3. Add short sections to the readiness document summarizing gaps between the current practices and the future state, grouped by functions, types of teams, deliverables, etc.
  4. Write user stories for this or other epics to address those gaps.

User Story 3.9: Assess Organizational Readiness

As the change leader, I want to assess the results of the history and gap analyses to determine whether an Agile adoption should be attempted, to prevent wasting time, money, and stakeholder goodwill if not.

This is where, as we say in the automobile-addicted United States, “the rubber hits the road.” You will clean up the readiness and gap analysis, present it to the sponsor and additional parties, and make one of three decisions:

  • Seek top management approval for an Agile transformation project immediately, if there are only minor blockers that can be addressed before or during the project.
  • Delay the attempt indefinitely while addressing major blockers that currently make success unlikely.
  • Give up on Agile, hopefully in favor of other process-improvement efforts more likely to succeed in your environment.

There is no shame in saying “no,” for reasons already addressed. However, in 30 years of working with a wide variety of business teams, I can’t think of any organization that would not have benefited significantly from a switch to practices I now consider “Agile management.”

Suggested tasks:

  1. Edit, proofread, and spell-check the readiness and gap analysis.
  2. If needed, create a slide deck based on your findings.
  3. Set a meeting with the sponsor and all potential change agents you have identified.
  4. Present your findings and facilitate consensus on one of three options: go, delay, or no-go.
  5. If the decision is “go” or “delay,” ask for input on suggested changes to the document.
  6. Update the document, if needed, and publish it.

Note: If the decision was “no-go,” skip the next story and simply communicate that decision and the reasons via US 3.11.

User Story 3.10: Create Organizational Readiness Stories

As the change leader, I want to create stories to address the identified organizational readiness gaps that must be addressed before attempting or as part of Agile adoption, to mitigate the risks they pose to success.

You have been creating new user stories throughout this epic, but another set is likely to emerge from US 3.9. In theory creating them could be another task in that story, but this one also seeks input on all of the stories resulting from the epic.

Suggested tasks:

  1. Review stories created from the organizational readiness analysis and add to, delete, combine or divide them as needed.
  2. Send them to the sponsor and change agents and request feedback (or hold a meeting to obtain feedback).
  3. Update the stories as needed.

User Story 3.11: Communicate Organizational Readiness

As the change leader, I want to communicate the results of the readiness and gap analyses to invite help with gaps and reduce negative resistance.

This story marks a step up in transparency for the Agile effort. By now rumors will have begun to spread, and a few people outside the change agents may have taken a look at what you have published. The organizational readiness and gap analysis gives a wider audience something to chew on, and your decision in US 3.9 will dispel or confirm some of the rumors.

Communication studies over many years have proven recipients must hear most messages multiple times via multiple channels for the information to sink in. Think about the ways information is commonly distributed in your organization, often without it successfully spreading due to lazy reliance on one e-mail or an announcement in a meeting. Beginning with this story, get in the habit of choosing multiple approaches and forcing yourself to repeat the message more than you think should be necessary. For example, an e-mail blast to all employees is okay, but remember that many people have hundreds of e-mails in their inboxes and get dozens per day. Also announce the news at the next “all-hands” meeting, being aware some people will be out that day. Ask change agents to mention it in their group meetings… post it to digital displays, bulletin boards, and chat groups… post flyers… do whatever will get people’s attention.

The message delivered by all these means should be short: Here is the decision we made, here is why we made it, and here is where you can go to get more information. This will make your life easier regardless of the answer:

  • Even if the decision is not to pursue Agile, you will need to explain why to those who see problems it might have solved. Otherwise they will continue to agitate for it, or resist other approaches you take to solving the problems (repeating, “Why don’t we just do Agile?”).
  • If you are delaying the implementation, some will see this as an act of managers unwilling to address problems (as discussed under Epic 2). You will need to focus everyone’s attention on the gaps that need to be fixed before Agile can be pursued, and communicate any visible steps already taken to tackle them.
  • Finally, if the answer is “go,” it will be important to emphasize, as you did when identifying a sponsor, that the firm is exploring adopting an Agile system, not yet implementing one. This will prevent people from feeling the decision is being imposed on them without an opportunity for input, a significant source of negative resistance to change.

Suggested tasks:

  1. Make the organizational readiness and gap analysis and other related documents visible to everyone in the organization.
  2. Compose a basic message stating the decision, summarizing why it was made, and providing the location you have used for publishing stories and documents.
  3. Send it to the sponsor and change agents and request feedback.
  4. Create tasks in this story for at least three methods of getting the message out.

Note: If the decision was not to move forward, you are done with the project. In the case of a delay, put this backlog on hold until you feel the blocking gaps have been addressed, and then repeat related stories in Epic 3 to verify.

↑ A Process for Agile Transformation | ← Epic 2 | → Epic 4

Full references are in the Agile Transformation bibliography.

[1] ACMP 2014.

Share this page