Contents
Timing is Everything
Some of the release and enterprise work described in other sections will eventually hit a roadblock if the project teams involved have not made some progress in learning Scrum. As you are getting the wider efforts under way, in most cases it will make sense to go ahead and begin converting the team(s). And of course, your team may not be doing any of that upper-level change (though I prefer clients do some of the stuff in “Structuring for Agile” right away).
The one reason to wait is if the current teams will be reorganized according to the principles listed in that section. Primarily this involves creating fully cross-functional, full-stack teams instead of having, for example, a team of hardware engineers, a team of software testers, etc. It makes no sense to invest time in team decisions that will have to be re-made by the new teams. In that case wait until after the reorganization, and have each create a “Team Charter” before doing anything else. The step sets will remind you to do that.
A key advantage of Full Scale agile™ is its emphasis on keeping teams productive. That starts at the start! Don’t stop forward progress to make this switch. Existing teams converting to Scrum should continue to work on deliverables using your current work management methods until you are ready to start your first sprint. (A step set will tell you when that is.) New teams can be researching the technology, investigating architecture, and identifying technical requirements while running through the steps to start FuSca™.
In either case, get started on choosing how to track your work first. It could take a while, and you can be doing other Scrum-related tasks in parallel. Those of you transitioning one small team can skip directly to “Choose a Tracker” (next page). Everyone else, keep reading.
You’re the Head Coach
Coach the Coaches
A staffing agency once contacted me to see if I would be interested in leading an Agile transformation for a statewide insurance company. That company had been struggling with Agile for years. In fact, I had turned down a Scrum Master position there earlier in my career because it was clear they weren’t really adopting the Agile mindset. The recruiter assured me the company was making a sincere effort “to change this time.” Yet the job description said this role would be leading a “team of coaches” through the process.
“It sounds like now after years of doing Agile wrong, they are trying to change the wrong way, too,” I said. The recruiter asked, what do you mean? Well, I explained, “they are assuming they need a ‘team of coaches’ before anyone has done a gap analysis to determine what they need!” He saw my point, but said his client wanted to make sure whatever coach they hired “had the resources” to implement the changes. And here I heard the dollar signs popping up in his head. It turned out the staffing agency had an “Agile Practices” team. The agency would, of course, make more money if it could sell the client a bunch of coaches, necessary or not.
In any but the biggest companies, I consider it a waste of money to hire more than one coach. You already have, or will have, a “team of coaches”: The primary role of managers in modern companies is to coach their employees. Google did a two-year internal study analyzing performance reviews and employee feedback on technical-area managers. Contrary to their expectation that technical expertise would be the leading success factor, that landed at the bottom of the list. At the top? “Be a good coach,” followed by, “Empower: Don’t micromanage.”[1] Your managers must change how they relate to their teams to get the full benefits of agility, so if coaching is their top job, they must become your agile coaches.
If you are going the Scrum or Kanban route, you also have people who will need to find new roles: in a fully agile organization, for example, the process does most of what project managers used to do. Those capable of making the needed mindshift can become coaches while they find those new roles, or perhaps shift into new careers as Agile Coaches for other companies. In FuSca, the Agile Release Managers serve as coaches at the program level, and other scaled Agile systems have similar roles. Why not train them to do the team-level coaching, a great way for them to fully learn the system?
In short, you would only need a team of additional coaches if you did a lousy job of training the people who are supposed to be doing the coaching. Assuming you are the change leader, you can be thought of as “training the trainers,” a well-established concept in adult learning.
To be clear, I have no objection to hiring an external coach to help you implement FuSca, or any other Agile system… obviously, given that I make my living that way! The coach’s job, though, is to work their way out of a job. Doing that well means leaving behind agile teams that can take it from there to run the system—and radically evolve the system, if desired, to keep meeting their and their customers’ needs. Given the power of self-direction, I especially cringe when I see the phrase “Agile Center of Excellence.” Having such nearly guarantees an overly standardized and un-agile approach to Agile. FuSca is highly prescriptive at first due to the value of systems thinking, but then teams are free to change processes as long as the organization’s objectives are still met.
You can hire an official Agile Coach if you have the money, and the transformation may go faster in that case if you’re not an experienced trainer. But a goal of this site is to make that unnecessary. By following the step sets in order, almost anyone can help people implement the system. Then restructure for agility per “Structuring for Agile”; tie your performance appraisals to the Agile Performance Standards, if you do appraisals; and your teams will continue to fill the needs behind your conversion to Agile.
Model and Guide Desired Behaviors
Adults learn best by doing, in small chunks of learning at a time. The FuSca step sets incorporate these and other best practices from adult-learning experts, but most sets are focused on someone facilitating meetings with a specific team or program. The FuSca change leader will provide training of those facilitators on what to do, and then follow up to ensure the learning sinks in.
In programs of four teams or less, I strongly recommend the use of “modeling.” Simply put, this means to demonstrate the skill until the learner expresses a sense of understanding. That done, let the learner try the skill under close supervision, and finally let the learner take over while the coach monitors. This should sound familiar: It is the “Shu-Ha-Ri” model discussed earlier, but from the coach’s perspective.
Specifically, I am suggesting you, the change leader, serve as the initial hands-on coach for each team (in Scrum, the Facilitator[2]). One person can handle up to four with a little juggling. After a team is running Scrum or Kanban smoothly, help them select their own Facilitator(s) or start turning your coaching role over to the manager. Slowly shift into the background, attending team meetings to “coach the coach” until every Facilitator, Team Guide, and manager seems and feels ready to take over. After that, check in on occasion and remain responsive to questions. Otherwise, you can move on to your next set of teams, or up to release planning and larger enterprise issues. After those are done? Go back to your regular gig in the company, or if a consultant, find your next contract!
When helping a larger number of teams get started all at once, the alternative is to train people to identify internal coaches. If you are following the Agile Transformation Process, change agents are logical choices. Others are people who would otherwise be displaced, like project managers.
As you are doing that, make your Agile Tracker decision (next page). Then gather the teams and lead them through this “Sprint Process” section at least to the point (in Scrum) of their identifying their Facilitators and Team Guides. Better is to get through all the sets for this “Sprint Process” section or “Use Kanban for Flowing Work“; this ensures these critical steps are done correctly, while helping ensure the initial Facilitators and TGs do not have too much influence over the decisions. The guidance on project kickoffs shows how to do this in an initial multi-day meeting. If a single meeting isn’t possible, meet with the teams individually within a short window, two to three weeks, to facilitate them through to that point.
Then set weekly meetings with all of the coaches to coach them through the remaining steps of the sprint process. At each, let people discuss the efforts from the past week. Next cover the steps for the following week, reviewing the background information under this “Sprint Process” section and also walking through the relevant step set(s). Let the group dictate how many sets they think they can do in a week. They should continue with their normal work, but don’t let that be an excuse not to take at least one step (set) forward each week. Keep pushing change like a sports coach, or the momentum may die.
Between training sessions, attend as many team meetings as you can. As defined under “Scrum Ceremonies,” be more of an “observer” than a “participant.” That is, resist the urge to jump in unless the coach says something wrong based on FuSca. Remember that person is the coach of the team at this moment; you are the coach of the coach. You don’t want to undermine the coach’s position on the team. After the team begins using a tracker, look at it after sprint planning to review the quality of story grooming, capacity planning, etc. After each Demo, review sprint results.
For issues specific to a particular team, talk to their coach or current Facilitator—talk, not e-mail, for reasons explained under “Coach the Team.” Problems that other teams might run into, or did, you can bring up in the next training session without “naming names.” Just say you spotted a problem whose discussion would benefit the whole group, and discuss it without revealing the specific team or details that would identify them. The coach involved is welcome to self-identify, of course, but putting them on the spot will reduce their willingness to cooperate with you in the future.
Once the teams have Scrum or Kanban down, the most efficient way to get multi-team release planning under way, if relevant, is for you to serve as the initial Agile Release Manager (ARM). The entire transformation effort can be derailed if someone mishandles this position. Just as the Facilitator and PO cannot be allowed to think of themselves as bosses of their teams, this person is not the boss of the program. Establishing the role correctly will build in defenses against bad behaviors, because people who have seen it done right will resist—or at least report—actions that cross the line. As when serving as the original Facilitator for the team(s), you can train a replacement and roll off once the Release Planners have the process down, usually after two or three releases. Obviously, the coaches from the team-level effort should be excellent candidates to become ARMs, and you can transition a large program into release planning by coaching them step by step the same way.
⇒ Steps:
↑ The Sprint Process | → Make Initial Decisions
[1] Williams, Chuck (2017). MGMT9: Principles of Management. Ninth edition. Boston, MA: Cengage Learning.
[2] The FuSca equivalent to “Scrum Masters.” See: “Why does FuSca use ‘Facilitator’ instead of ‘Scrum Master?’”