Epic 8: Choose an Agile System

Contents

The Epic

As stakeholders, we want an Agile system that fits our needs, to gain the maximum benefits from the transformation.

An 1800s cartoon of a man standing at a road sign deciding which way to go, while walking two pigs on leashes Alongside a few scaled Agile systems or frameworks that are better known, the number of approaches is ever-growing. This is as it should be. Agile trainers will sometimes refer to “Shu-Ha-Ri,” a concept borrowed from the martial arts that says the dedicated student will move from learning someone else’s system, to teaching someone else’s system, to creating their own system. To avoid the downsides of isomorphism, I would expect more systems as more Agile Coaches attain that level of mastery, just as every top sports team coach has a unique approach to the game. In fact, the creators of the Agile Manifesto thought “there would be an explosion of methods,” according to original signer Andy Hunt.[1]

This website argues no existing framework or method is necessary for adopting agility, and the best approach is to allow each team to develop it’s own method. A decision to take this approach is a choice, however, and is the first step toward creating a unique system. (See Self-Directed agile for the arguments and one approach.) Epic 8 will be short if self-direction is chosen, but is written on the assumption that your organization insists on considering standard frameworks.

Any systematic approach to Agile will provide the majority of Agile’s potential benefits if correctly implemented; this is true of any sort of process improvement. Still, some systems may better fit your organizational culture and goals than others. Regardless, evidence detailed under Epic 10 proves you greatly enhance your chances for achieving the objectives of the project by choosing one system—or the self-directed approach—implementing it, and then customizing carefully, as detailed under epics 10 and 11. (I’m not talking about the minor customizations all existing systems call for within the system.) This epic takes you through the process of exploring your options and gaining approval of the system the Change Team chooses.

The stories in this epic may be a bit confusing, because they facilitate one of three paths for choosing a system:

  • Do it yourself (DIY), meaning creating your own system.
  • Choose a system and hire a coach for that system (or narrow down to a few systems/coaches first).
  • Hire a coach and (therefore) their system.

The last option is the sports model of coaching. A professional basketball coach, for example, would never agree to use someone else’s approach to basketball. Furthermore, the general (business) manager knows not to interfere in the coach’s approach. By hiring that coach, you have chosen their system.

That said, many basketball coaches have a recognizable approach to the sport similar to that of some other coaches, especially those who worked for the same big-name coach known for that approach. For example, the team’s owner might decide they want a fast offensive game without worrying about defense as much. They would look for coaches who share that philosophy. This is similar to deciding you want to use a particular system first, and then hiring an expert on that system.

Because of these options, I have put stories for hiring a coach in this epic. (Further rationale for doing so, and points to consider, are provided under US 8.7.) For the DIY option, delete the coaching stories (8.7–8.10); for the coach-first option, do them first and delete the system ones. Obviously the system-first option requires some mix of these stories. I chose not to put a separate story in for choosing an option. My guess is the answer will evolve as you start down this path.

The DIY option is messier and will take longer, like a “just for fun” basketball team coaching themselves. It can obviously succeed, or no one would have invented the various Agile methods! If you are not given money for coaching, you will need detailed steps to follow like Full Scale agile™ offers. In this case, the formal comparison process contained in stories 8.2 through 8.4, though time-consuming, will be especially important. These take you through a careful head-to-head comparison.

User Story 8.1: Gather Pros and Cons on Systems

As the change leader, I want to know what systems of scaled Agile are available, and the high-level pros and cons for each, to increase the odds of adopting one that fits our organization.

Since there are as many systems as there are “master” Agile coaches, there can never be a comprehensive list or detailed examination of all of those available. So this story is more about understanding what is important to your organization. Unfortunately, a Web search on the term “scaled Agile” returns a large number of entries on one particular method, Scaled Agile Framework or SAFe. Experiment with different related phrases. I got the broadest set of entries using “agile at scale models” and skipping stuff related to SAFe. One good attempt at an evidence-based comparison of major systems is the Agile Scaling matrix. You’ll want to look at the sites for each system of interest to get a better overview. And the DIY approach should be treated like a “system” in this epic.

If you:

  • Are already experienced with Agile, you may want to do US 8.3 first, deciding what is important to you and then doing this story with those criteria in mind.
  • Would rather find the right coach first and follow their lead on the system, skip to US 8.7.

Suggested tasks:

  1. Conduct a Web search for lists of different Agile-at-scale systems/frameworks.
  2. Read the sites of at least three of them, and other opinions you find, noting differences between the systems.
  3. Write a high-level list of strengths and weaknesses of each and publish it, notifying the sponsor and Change Team.

User Story 8.2: Choose Systems to Investigate

As the Change Team, we want to choose two or more Agile systems to investigate fully, so we can make a well-informed decision.

Since you can’t do a detailed comparison of every scaled Agile framework, in this story the team (or a subteam) looks over the alternatives to select a few for a deeper look. Remember you can always choose more later—making a copy of this story and repeating the tasks—if you can’t reach agreement on your first choices.

This story is blocked until US 8.1 is finished.

Suggested tasks:

  1. Decide whether the whole team will review the pro/con lists, or a subteam of volunteers.
  2. Conduct a review of the pro/con lists and choose two or three systems to investigate.
  3. At the next meeting, decide as a team which ones to review in the full comparison.

User Story 8.3: Draft System Comparison Tool

As the change leader, I want to draft criteria for comparing Agile systems, so I can get input to match our choices to our needs.

Compare the organizational readiness and gap analysis from Epic 3 to the pro/con list for Agile systems. Perhaps you will see some overlaps. For example:

  • Maybe your teams currently report constantly getting blocked by other teams. A system with an obvious point in the process for identifying and communicating dependencies will be valuable in the short term, and will eliminate many of those if it eventually creates full-stack teams.
  • Say that overwork is a major complaint. Look for a system that identifies individual capacities instead of relying only on team velocity.
  • Where teams are doing Agile well at the team level but having difficulties coordinating, a system focused more on the cross-team level may be sufficient.

The goal of this story is to produce a list of criteria with which to compare the systems, given what is important to your organization. An example technique may be found on on the Criteria Method from my Radical Agilist site. You can use whatever format you wish, of course. The point is to develop a more rational basis for comparing systems than just subjective impressions. The change leader proposes a list in this story, and the Change Team creates the final version in the next.

Suggested tasks:

  1. If not familiar with criteria-based decision-making, conduct a Web search to identify a preferred technique.
  2. Bearing the readiness and gap analysis in mind, review the Agile system pro/con list and create a list of criteria for comparing systems.
  3. Draft a comparison form according to your chosen technique.
  4. Publish it, and ask the sponsor and Change Team to review it prior to the next team meeting.

User Story 8.4: Approve System Comparison Tool

As the Change Team, we want to set criteria for comparing Agile systems, so we ensure our choice meets our needs.

Have the Change Team provide input on the decision technique and criteria and decide who will do the comparison. This is largely a tradeoff in decision quality versus speed: the more people involved, the more likely the decision is to meet the organization’s needs, but the longer it will take.

Suggested tasks:

  1. In a team meeting, review the technique chosen and the reasons for the proposed criteria.
  2. Discuss the proposed list and reach consensus on desired changes.
  3. Determine whether the leader will rate the systems alone, with a subteam, or with the whole team.
  4. Update and publish the criteria list.

User Story 8.5: Rate Agile Systems

As the change leader, I want to rate the systems the Change Team chose to review so we have a quantified basis for a rational decision.

Make a copy of Task 1 for each person involved. Task 2 will typically be done by the change leader.

Suggested tasks:

  1. Rate the systems using the method from US 8.4.
  2. When all raters are done, compile the ratings.
  3. Publish the results, and notify the sponsor and Change Team.

User Story 8.6: Approve a System

As the change leader, I want approval from the change sponsor and Change Team to move forward with a chosen system, so we can begin implementation.

Suggested tasks:

  1. In a team meeting with the project sponsor present, review the results of US 8.5.
  2. Choose a system, recording any reasons raised that are not already in the ratings tools.
  3. Publish the results.

User Story 8.7: Obtain Authorization to Hire a Coach

As the Change Team, we want authorization to hire an Agile Coach to save time, effort, and trouble.

Refer back to the epic information for a discussion on the timing of this next set of stories versus the system-choice stories above. When/if you decide to hire a coach, involve the whole team, for what should seem like familiar reasons by this point: to improve the choice, and reduce the sense the coach is being imposed without input.

For the reasons introduced above, hiring a coach to lead the transformation can be very cost-effective. The investment of a coach’s salary should save many times that amount of money by implementing Agile more efficiently, saving labor time of (theoretically) every manager and worker in your organization. If you have 200 people and shave half a week off the implementation in the first year, you have roughly covered the cost of a high-paid full-time coach for that year. Being an Agile Coach I am biased, but I think the math bears out the value of hiring someone.

I see no point to hiring a “permanent” coach, or more than one coach, for any but the largest of corporations. By definition, once an organization has fully adapted an Agile mindset, you no longer need an Agile coach. You will want to pursue other continuous improvement initiatives, but the teams will be handling Agile improvements via the Retrospective ceremonies. Because each Facilitator or Scrum Master becomes the team-level coach, and all frameworks I know of have an facilitator at the cross-team level, the Agile coach can drive the effort using a “coach the coach” approach, perhaps after working directly with teams to get them up to speed.

At the other extreme, I have seen zero evidence that “seagull” consultants—those who fly in once a week or less, drop their “stuff” on you, and fly out—have any lasting impact on their clients. More than once I have been hired into an organization to clean up a seagull’s mess. The coach needs to be involved on a near-daily basis to correct the ship as it goes.

Thus choosing to hire a contractor/consultant versus a “full-time” hire is more about the size of organization and relative costs for the time required to make the transformation. In my opinion, the coach’s goal should be to work their way out of a job, because Agile becomes “the way we do things” and is no longer something separate. In any but the largest corporations, three years should be sufficient for a competent coach.

Some hiring efforts can seem to take that long. Change leaders who already have a budget for a coach from the sponsor can pull this story off in one sprint. Others may need this story split after Step 2, with the sponsor’s decision serving as the acceptance criteria for the first copy of the story.

Suggested tasks:

  1. In a Change Team meeting, discuss whether to hire a coach.
  2. If the decision is “yes,” propose doing so to the change sponsor.
  3. If the sponsor agrees, monitor and support the effort to gain authorization for the hire from the organization.
  4. If the hire is approved, notify the Change Team and publish the decision.

User Story 8.8: Create an Agile Coach Job Description

As the Change Team, we want to draft a comprehensive job description so we recruit the right Agile coach.

The tasks in the next few stories enact the approach for team-led hiring explained at “Create New Teams.” Though split to fit into more than one sprint, they could theoretically be done together within one.

That linked page includes guidance on writing job descriptions. An Agile coach should be able to demonstrate:

  • Experience leading enterprise-level Agile change.
  • Experience coaching at all levels from top managers to line workers.
  • Experience with both training (delivering formal classes/workshops) and coaching (providing real-time guidance).
  • Demonstrated writing, presentation, and persuasion skills.
  • A track record of objectively measurable successes in changing organizational behaviors or outcomes.
  • At least one certification in Agile above the Scrum Master level, such as PMI-Agile Certified Practitioner (beware, however, the idea that a certification proves someone can do the job).

Of course, if you have already selected a system, include it in the job title and description to make things easier for everyone. For example, if you are using the LeSS framework, advertise for a “LeSS Agile Coach” and seek LeSS-specific training or certification. Because many coaches will not use a pre-chosen system, you will cut down on the number of applicants and increase the relevance of the remainder specific to that system.

At minimum, plan on having each candidate do a training session as part of the interview process, on the same topic common to all Agile systems (like “writing requirements or user stories”). This provides an “apples-to-apples” comparison. Better, plan on them also spending the day observing some meetings and offering critiques, thus giving you realistic tests of both their training and coaching skills. I mention this now because this requirement should be listed in the job advertisement, to weed out people unwilling to participate.

Suggested tasks:

  1. Create a job description of required and desired characteristics.
  2. Have the project sponsor and HR vet the description, and update it as needed.
  3. Place the job ad.
  4. Search for local Agile and project management groups, and publicize the ad through them to increase the pool of prospective candidates.

Key options for Task 4 are the Agile committee of your local chapter of the Project Management Institute, local chapter of the Agile Leadership Network, or related Meetup groups.

User Story 8.9: Select Interview Candidates

As the Change Team, we want to find several Agile coach candidates to interview, to increase our odds of getting the right person.

Suggested tasks:

  1. In a team meeting, decide whether a subteam or the whole team will vet resumes and/or interview candidates.
  2. Obtain training through HR on legal hiring practices for any interviewer who has not already received it.
  3. Review resumes to choose at least five candidates for initial phone interviews.

User Story 8.10: Choose a Coach

As the Change Team, we want to select an Agile coach who can lead us through our Agile transformation as efficiently as possible.

A subteam can do the phone interviews, but as usual you will get the best final decision by letting as many members participate in the in-person activities as possible.

Ask the change sponsor how much they want to be involved. I recommend they at least interview each finalist and be given veto power. A sponsor and coach who do not like each other, for professional or personal reasons, will make each other less effective. In the case of a veto, the hiring team can decide whether to propose the #2 candidate or reopen the search.

Here is an effective schedule for the in-person sessions, though steps 2 through 5 could be in any order:

  1. Greeting and signing of a nondisclosure agreement.
  2. Tour of the facility.
  3. Group interview (min. 1 hour).
  4. Training presentation (30 minutes plus Q&A).
  5. Observe regular meetings (any type available, though work team and Change Team meetings are preferred).
  6. Discussion with hiring group of the candidate’s meeting observations, and final questions from candidate.
  7. Candidate departure followed by group discussion of candidate.

If involving, say, 10 people in six hours of vetting time for three candidates seems expensive, consider this: That is 60 labor hours invested to ensure you get the right candidate for more than 2,000 labor hours of effective work by that coach just in the first year. Add in the time savings per organization member a good coach can provide, as mentioned under US 8.7, and this is a bargain.

Suggested tasks:

  1. Schedule phone interviews with all candidates.
  2. Conduct a phone interview with [candidate; make a copy for each candidate].
  3. Schedule in-person interviews/demonstrations with at least two candidates.
  4. Hold an in-person interview/demo with [candidate].
  5. In a hiring group meeting, choose a final candidate.
  6. Propose the candidate to the project sponsor.
  7. Once a candidate is approved, initiate the hiring or contractor procurement process.

↑ A Process for Agile Transformation | ← Epic 7 | → Epic 9

[1] Hunt, Andy, ‘The Problem with Practices’ (presented at Agile RTP, Webinar, 3/1/2022).

Share this page