Epic 1: Define the Why

Contents

The Epic

As a member of this organization, I want to know why a change in our work management is required, so I will feel motivated, instead of forced, to make the change.

Old-fashioned drawing of a someone holding a question mark after the word "Why"A counseling psychologist writing about organizational change said resistance can arise in an individual when “they believe their needs are already being met” or “they believe (the change) is unnecessary to avoid or escape a harmful situation.”[1] Persuasion research has shown that people convinced of a position will be as motivated to enact it as if they had come up with it.[2] That need for personal relevance to motivate change was echoed by two software management researchers: “It is essential that staff members understand the relationship between the objectives of software process improvement and revenues, cash flow, or other business results. Mere conformance to a standard, attaining certification, or reaching a CMM level usually is not a relevant goal for staff members.”[3] A study of a manufacturing firm spinoff surmised, “management underestimated the impact of the change on the employees (and) spent little time explaining the change… therefore resulting in the low levels of affective commitment for change.”[4] Two other researchers said, “Management must provide evidence that the current ways are no longer acceptable or appropriate if the organization is to remain successful or regain success.”[5]

The Association of Change Management Professionals (ACMP) states the case firmly: “A misunderstood or incomplete change rationale may be one of the biggest risks in successfully gaining stakeholder adoption.”[6] Merely assuming everyone will understand the benefits of Agile once explained and want to change is a precursor to failure.

These evidence-based warnings mean that even if you are the CEO, you need to come up with a compelling message and create a sense of urgency. Simply saying, in effect, “do it because I said so” is going to get at best an incomplete, and therefore failed, implementation. Whether you like it or not, psychology matters when it comes to change. Obviously, if you are not the CEO, you must provide everyone above you in the hierarchy a powerful justification for them to put up with the hassles an agile transformation will cause them for months.

The child stories for this epic walk through a logical process of identifying underlying causes; converting them into a concise message of why the change is required; getting approval from the sponsor, and then the Change Team once formed; and possibly revisiting the message later based on broader input, which will maximize its effect.

User Story 1.1: Identify Causes

As the change leader, I want to identify a list of potential opportunities or threats driving the organization to consider Agile, to identify causes justifying the change.

Why do you think your organization should be agile? Just because a lot of enterprises have gone that way, that doesn’t mean yours should. Maybe yours is performing as well as it can; your customers and workers are happy as clams; profits are over the moon; and stockholders are begging to buy shares. I’m being a bit flippant, but the truth is, many top managers are happy as long as all indicators are “good enough” and the board of directors isn’t breathing down their necks.[7] More importantly, doubters will come up with a slew of reasons not to explore agility, so you need a superior set.

To create a sense of urgency around the switch, start by identifying things that are going wrong and/or opportunities your organization might miss if it does not change. The spreadsheet version of this story refers to “SWOT Analysis,” a common method for devising strategy. “SWOT” stands for, “Strengths, Weaknesses, Opportunities, and Threats.” I won’t go through all the steps for facilitating a SWOT analysis here, because a Web search will bring up plenty of guidance. However, for this purpose I’m not suggesting a formal multi-person process. SWOT is just an easy guide for thinking through potential weaknesses compared to competitors or to best practices; opportunities the organization cannot take advantage of if it doesn’t switch; and threats from failure to change. See “Benefits of Agile and Scrum” for ideas.

This story’s “acceptance criteria” in the spreadsheet use the word “published.” Throughout the backlog, that just means capturing the results in any written form accessible on demand by everyone involved in driving the change, like physical bulletin boards or intranet sites. E-mails or memos can also be used, but a central repository of information is vital to group memory. In User Story (US) 5.3 you will create a “public” version of this location available to all stakeholders. There’s nothing wrong with doing that right away, but if you do, make sure drafts are clearly marked as such lest people think decisions have been made before they are. (For example, in a word processing program you can add a “watermark” or repeating header saying “Draft.”)

As explained under Epic 5, transparency is critical. That said, if you are a single individual or small informal group trying to foment change, you don’t need to make the documents public right away. Create a private folder/library in a document repository for drafts, and make public versions available when you’re ready to start the public process.

Per the Agile Manifesto principles emphasizing iterative development and good quality, make any draft as clean as you can get it before publishing. This forces you to think through the material more, and helps produce a cleaner final copy than trying to catch all mistakes in a later pass.

Suggested tasks:

  1. Write down why you think agility is needed, as bullet lists under three columns labelled, “Weaknesses,” “Opportunities,” and, “Threats.”
  2. Read your enterprise’s Annual Report, strategy documents, messages from top leaders, mission and values statements, project performance metrics, etc., and revise your lists, referencing the source(s) for each item.
  3. Conduct a Web search on your enterprise and again revise your list, including the evidence.
  4. Show the list to one or more people in the enterprise, and revise it based on their input.
  5. Create a location to “publish” the document, and place your list there.

User Story 1.2: Propose Why Statement

As the change leader, I want to propose a concise, motivating “Why Statement” so I can build a persuasive argument for exploring Agile.

Your next goal is to boil the causes list down into an advertising tag line, in effect. It doesn’t have to be as short as what you see at the end of TV commercials, but does need to be fairly easy to memorize to ensure it is repeated accurately and consistently. And like an ad, it needs to provide some emotional heft while still relating to the logical US 1.1 causes. In other words, this is the mission statement for the agile transformation project.

Notice that the acceptance criteria in the spreadsheet for this story require you to reach agreement with the project sponsor. Obviously you must complete US 2.1 to identify a sponsor before you can complete this story, so you might start that one in your first sprint along with US 1.1. In Scrum terms, US 2.1 is a “blocker” or “impediment” for this story.

Suggested tasks:

  1. Research good practices for mission statements.
  2. Draft a one- or two-sentence mission statement directly supported by the causes in US 1.1.
  3. Send the draft to the project sponsor.
  4. Meet with the sponsor to agree on the draft wording.
  5. Publish the proposed Why Statement.

User Story 1.3: Finalize Why Statement

As the change leader, I want consensus from initial change agents and the change sponsor on the Why Statement to ensure we deliver a consistent and effective message.

The value of multiple perspectives in decision-making exemplified by crowdsourcing is well proven, so it should be no surprise that seeking out those perspectives is part of organizational change. As you start talking about agility, you will begin to find allies who share your interest and offer help. These are “change agents” who, if the project goes forward, will become critical to its success. The earlier you involve them in creating tangible outputs, the more ownership and personal stake they will feel in the outcome of the project. Reaching out for their input both improves the statement and begins building a consistent vision.

In fact, the draft Why Statement will be useful in recruiting agents, so I would expect some time to pass between finishing US 1.2 and starting this story. Meanwhile, you can be starting on epics 2 and/or 3. Then when you are ready to step up your push for agility, engage potential agents by asking for their input. Note that this group is not intended to be a formal team (yet): The effort should be informal, and you’ll want to make clear it is not an official project at this point. You want people to feel part of something special “from the get-go.” Accordingly, do not get too possessive about any particular wording. Making people feel they can impact the results is especially important now, due to the motivational benefits.

Suggested tasks:

  1. Write out a list of people in your organization whom you’ve talked to about agility.
  2. Send an e-mail to them and the project sponsor with a link to the draft Why Statement.
  3. Set a half-hour meeting to revise the statement, inviting written comments from those who cannot attend.
    Note: Consider a lunchtime meeting since this is not an “official” project yet.
  4. In the meeting, read out any written comments, and facilitate consensus on the wording (revising as needed).
  5. Publish the revised Why Statement.

Task 2 is an example of a “reminder task” in Full Scale agile™. If you were estimating effort it would only be a quarter-hour, but it is included to make sure it gets done. Add these to the backlog freely when concerned you might miss a small but important to-do.

User Story 1.4: Refine Why Statement with Change Team

As the change leader, I want consensus from the Change Team and the sponsor on the Why Statement to maintain a consistent and effective message.

Repeat the prior story with the formal Change Team after it is formed. Though the team may mostly contain the same change agents, this will be an early chance for the team as a whole to feel a sense of ownership. Plus, what you have learned by using the statement since US 1.3 was finished may provide ideas for how it can be strengthened.

Obviously US 7.2, the kickoff for the Change Team, is a blocker for this story.

Suggested tasks:

  1. Add discussion of the Why Statement as an agenda item for the next Change Team meeting, and send an e-mail to the members and the project sponsor with a link to the current statement, inviting written comments from those who cannot attend.
  2. In the meeting, read out any written comments, and facilitate consensus on the wording.
  3. Publish the revised Why Statement.

User Story 1.5: Revisit Why Statement

As the change leader, I want to revisit the Why Statement if feedback from stakeholders warrants a change, to ensure it does not become a source of resistance.

I mentioned on the previous page that the lack of two-way communication is a source of RTC, discussed more under Epic 5. This story provides the first opportunity to prevent that problem. As noted in the spreadsheet, pay attention to comments and questions regarding the Why Statement during stakeholder sessions for two to three months after US 1.4 is done. If you see a pattern that suggests a change would strengthen it, repeat the tasks under 1.4 to refine the statement, adding to the meeting invitation the reasons you are suggesting the change.

The word “pattern” is important here. No wording of the Why Statement will be liked by everyone, so any version will get random critical comments. When an underlying theme to those comments arises, however, it can become a significant source of resistance if not addressed.

If you don’t see a pattern after a few months, it is okay to delete this story and ask the sponsor to accept Epic 1 as completed.

↑ A Process for Agile Transformation | → Epic 2

Full references are in the Agile Transformation bibliography.

[1] Hultman 1995.

[2] Morgan 1995.

[3] Stelzer & Mellis 1998.

[4] Walker, et al. 2007.

[5] Self & Schrader 2009.

[6] ACMP 2014.

[7] Williams 2017.

Share this page