- The Epic
- User Story 10.1: Create Child Stories for “All-in” Epic
- User Story 10.2: Communicate Project Success
As an organization, we want to implement our Agile system as quickly and completely as possible, to reduce resistance based on inertia and cynicism about change, and allow for shared learnings across teams.
Strong objective evidence, built up over many years from many types of organizational change projects, strongly suggests that a systematic approach to Agile is a critical success factor. John Kotter insisted that his process be followed without skipping steps, but the research goes back much further.
A 1948 study that directly compared A) a training-only approach to B) a coached pilot to C) a coached full adoption, found Option C was most successful by far. A review of all OC studies from 1990 to 1998 determined that taking shortcuts lowered results. An analysis of 92 studies covering 19,319 organizations determined having a set of progressive HR practices provided twice the financial and operational performance improvement of any one practice, due either to additive effects or synergies between practices. The most innovative Danish firms in another study had three or more progressive practices.
Regarding more specific changes:
- A survey of professional groups related to quality found that companies who tried to leave out some practices when adopting Total Quality Management did not get as much benefit from the change.
- Successful Honeywell and Caterpillar programs for manufacturing plants mandated systematic adoptions.
- A primary finding from a meta-analysis of 83 ProMES productivity method adoptions is that “when the original process is followed, the effect sizes are very large, and they drop off dramatically when the intervention deviates from this original process.”
- In their report on implementing holistic improvements to a healthcare system, two consultants emphasized, “Every nurse and doctor does not get to do it his or her own way. Standards are established about how the work is performed, and those standards are followed by all until a better way is determined collectively by the team.”
Specific to Agile:
- In Ericsson’s transformation to Agile, they found it important to, “Clarify which processes & tools are mandatory and which ones are optional.”
- One of the lessons Primavera Systems drew from its conversion was, “There aren’t many rules in Scrum, but you need to adhere to the ones that exist.”
- The one journal review on large-scale transformations as of early 2018 concluded, “to successfully perform an agile transformation, it seems important to use a single approach as a starting point…”
PMI states in its Agile Practice Guide, “adopt a formal agile approach, intentionally designed and proven to achieve desired results. Then take the time to learn and understand the agile approaches before changing or tailoring them. Premature and haphazard tailoring can minimize the effects of the approach and thus limit benefits.”
Agile writers and presenters correctly mention the need to customize a methodology to the organization, but miss the importance of the timing of that customization. Upfront customization seems best limited to the choice of Agile method and any decisions the method requires adopters to make. Beyond that, adopters should learn how to ride the bike before deciding what parts to remove or modify. That’s not to say you can’t take an iterative approach to the transformation, implementing the basics and then adding details of the system step by step, but do so across the board without “off-book” tailoring until the full system is in place.
As the change leader, I want to review with the Change Team an initial set of child stories for implementing the Agile system, to minimize problems at the start.
The system you choose likely recommends a particular approach to its implementation. FuSca™, for example, provides a complete set of steps. That’s why a full set of stories is not provided for this epic. For this story, convert your chosen system and approach into an initial set of implementation stories attached to the epic, many of which will become part of a “template” set with placeholders that get copied for each team as it begins the conversion (like US 9.3). For this purpose you only need the title, three-part story statement, and acceptance criteria.
In general, the team-level process for a Scrum-based system will likely go something like this, with many of the steps overlapping:
- Align people with the system roles.
- Choose a tool for tracking the work.
- Create initial team backlogs in story format.
Note: By this I mean backlogs of work requirements, not transformation stories.
- Make initial decisions required by the system (like sprint lengths and ceremony schedules for each team).
- Groom/plan the first release for each product/program, if releases are used.
- Groom/plan the first sprint for each team.
- Start the release/sprint cycle(s).
For a detailed example specific to FuSca, see the “Steps” section.
This epic could eventually be hundreds of stories depending on the number of teams you have. To break up the work, you may want to make a copy of the epic with the template set of stories for each group of teams and of stakeholders. Of course, those group-specific epics would be worked in parallel.
- Review the Agile system materials and draft “must-have” user stories for implementing the system at the organization, program/project (if applicable), and team levels.
- Schedule a meeting with the Change Team, including a link to the draft stories and requesting written feedback from those who can’t attend.
- At the meeting, facilitate consensus on changes, emphasizing this is only the initial set.
- Prioritize the top of the list, as many stories as you think the organization can accomplish in the first two months.
Per the process I recommended for the Change Team, you next would plan some top stories into the next team sprint. However, at this point the Change Team may want to switch to whatever Agile system it has chosen for the organization.
As stakeholders, we want to know the Agile system has been implemented so we can celebrate our accomplishment.
Although improvement efforts will never end, an Agile transformation is only successful when you cease thinking about it as a “transformation.” Once you have an Agile culture, there is no longer a need for a special effort to become Agile: your culture is Agile. When the measurable project objectives from Epic 4 and ongoing performance standards have been met, you can declare the project done, maybe look for another major change initiative, and enjoy your Agile life going forward.
Even if a formal project closure seems unnecessary to you personally, it can have a strong impact on worker morale and motivation toward future change. Too many managers underestimate the power of a genuine “thank you.” At the very least, all stakeholders need to be informed and thanked using all of the project’s communication channels. After this much effort, though, I think a formal celebration is called for—at least a cake party at lunchtime! This will also serve as the official closure ceremony for the Change Team.
It may seem strange that this story is not in the last epic, but this placement illustrates two points. First is the point made earlier that the epics are groupings of work to be accomplished, not waterfall-like steps. Communicating the end of the project seems to fit an epic about implementation of the system better than one about customization. Second, its placement in this epic emphasizes that you must be “all-in” before you consider the project complete. Obviously, the story is blocked until all acceptance criteria for all other epics are accepted.
- At a Change Team meeting, present the evidence of project completion to the team and sponsor, and request approval to disband the team.
- When approved, request a thank-you message and budget for a celebration from the sponsor.
- If approved, schedule the celebration.
- Announce the success and celebration via your established communication channels, including the sponsor’s thank you in the announcement.
- Hold the celebration.
- Archive the project site for future reference, arrange closure of the e-mail list if created, clear the physical bulletin board, etc.
 Coch & French 1948.
 Armenakis & Bedeian 1999.
 Combs et al. 2006.
 Laursen & Foss 2003.
 Kaynak 2003.
 Paper, et al. 2001.
 Pritchard, et al. 2008.
 Toussaint & Correia 2018.
 Esser 2017.
 Schatz & Abdelshafi 2005.
 Dikert, et al. 2016.
 PMI 2017a.