Epic 4: Specify the Objectives

Contents


The Epic

As a stakeholder, I want to know how Agile success will be measured, to make it easier to sell the effort, celebrate small wins, define “done,” and prevent backsliding.

John Kotter discussed the value of objective goals for: measuring progress; preventing premature declaration of success; and ensuring the changes “stick” by raising alarms if metrics backslide. Both the Project Management Body of Knowledge and the Standard for Change Management specify that projects in general and OC projects specifically should have these (and they are part of “The 10 Ingredients of Better Teamwork[1]). A study of law-firm mergers concluded a way to facilitate genuine two-way communication per Epic 5 is to ensure the “objective is boss.”[2]

Objectives are most effective in the form of SMART goals, defined under “Keep it SMART” in my Web book, The SuddenTeams™ Program. Instead of deadlines, however, an Agile project handles the “T” (for “timely”) differently. Any metrics are either limited to a sprint or release, or are measured within repeating time periods (sprintly, quarterly, etc.). An example for an Agile transformation project might be, “Increase customer satisfaction as measured by the ‘Would Recommend’ score on our CustSat survey by 10% every six months until reaching and maintaining 95%.” This is specific, lists the measure, starts with an action verb, seems realistic (no one pleases 100% of customers), and lists a time period. A slip below 95% after it is achieved provides objective evidence something has gone wrong.

You made a start on SMART by identifying in US 1.1 the opportunities and threats you wish to address using Agile. These should suggest to you ways to measure whether positive change occurs. If customers seem unhappy, measure customer satisfaction objectively now to establish a baseline, and repeat on a regular basis. Trying to close gaps in features relative to competitors? Have your product managers assign financial values to each gap and repeat the exercise every six months or year (depending on how often you release updated products). Need to serve more clients using existing resources? Measure throughput now and monthly thereafter, accounting for any other changes you make that could impact the numbers—and external factors that may be reducing demand.

Some warnings are useful. One of the biggest points to Agile is to ensure your firm is working on the right things to reach its goals: a common quote is “the right things, done right.” You need to be careful both that you are measuring things that are really important (like profits instead of just revenues or costs) and to protect against unintended consequences. As regularly discussed in the business literature long before Agile, a metric emphasizing productivity like “raise the number of widgets produced per cycle” can have a devastating impact on later profits if quality isn’t held constant.

Also, many measures businesses follow will fall in the initial phases of any OC project, as people spend time learning new skills and improving processes. For the example metric I gave, no panic should result if the monthly Customer Satisfaction score goes down during the early months and thus ends up below the baseline at the six-month mark. It would be a sign to increase customer interactions regarding the change to Agile and its long-term benefits to customers, but major concerns are only warranted if the trend is still downward at that point.

This epic follows a pattern you will recognize from the earlier ones: research and draft, get change agent input, later get Change Team approval, and revisit if needed. I won’t repeat justifications below that are essentially the same as for earlier similar stories.

User Story 4.1: Propose Objectives

As the change leader, I want to propose quantifiable performance measures for the transformation so that everyone knows how it is progressing.

Refer to the epic description above for background. You want to end up with three- to five metrics eventually, according to many studies into goal-setting. Before proposing them or to reduce the number later, vet for SMART-ness by considering these questions for each:

  • How would we measure this?
  • Can measurement and reporting be automated?
  • How important is this to the organization?
  • What figure is realistic within the time cycle given, and would rate as sufficient progress to justify the Agile transformation?

Suggested tasks:

  1. Review the causes list from US 1.1, and convert as many of them as you can into potential metrics.
  2. Reduce the list to no more than ten metrics and publish it.
  3. Schedule a meeting with the sponsor and change agents, including a link to the draft objectives and requesting written feedback from those who can’t attend.
  4. At the meeting, read out any written comments and facilitate consensus on a proposed list of three to five objectives.
  5. Publish the list.

User Story 4.2: Gain Change Team Approval on Objectives

As the change leader, I want Change Team approval of quantifiable performance measures for the transformation, to verify they are realistic and relevant.

The Change Team kickoff, US 7.2, is a blocking predecessor for this story. This should be one of the first stories done after that one is accepted.

Suggested tasks:

  1. Add discussion of the objectives 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 set, inviting written comments from those who cannot attend.
  2. In the meeting, read out any written comments, and facilitate consensus on the wording (revising as needed).
  3. Publish the revised list of objectives.

User Story 4.3: Revisit Objectives and Address Feedback

As the change leader, I want to revisit the quantifiable performance measures if stakeholder feedback warrants a change, so they don’t become a source of resistance.

Like US 1.5, this is a placeholder to make sure you look for and address patterns of feedback about the objectives, should they arise. The other comments under that story apply, except that you would copy the tasks from US 4.2. As with 1.5, if you don’t see a pattern after a few months, delete this story and ask the sponsor to accept the epic.

A Process for Agile Transformation | ← Epic 3 | → Epic 5


[1] PMI 2017, ACMP 2014.

[2] van Dijk & van Dick 2009.

Share this page