Contents
ContentsEvangelize Scale
Given the misconceptions executives have about project management embodied in “The Waterfall Myth,” I do not recommend trying to implement any method of scaled Agile unless all executives to whom team members report, directly or indirectly, agree to change their own behaviors as needed to support that method. For FuSca, that means the understandings under “Desired Agreements.” The intent is to help them understand how they have to change, not just the people who work for them. This is the line in the sand between merely “doing Agile” and “being Agile.”
You will find this transition easier if you evangelize the scaling effort the same way you did team-level Scrum (see “Gain Buy-in“), if you didn’t include scaling at that time. The steps linked to below for release planning refers you back to the same boxes used for that effort. The content narrows to only the concepts relevant to releases, but the process is exactly the same.
By “you” in this case, I mean either the project sponsor or a change champion that person designates to lead the FuSca conversion. The “project sponsor” is the person providing the budget or otherwise considered to have primary responsibility for the success of the project, regardless of official job title. (I’m using the Project Management Body of Knowledge term here, but the role might more accurately be called a “program” sponsor in your case.)
The rest of “Plan in Releases” assumes you are working with existing teams and projects. Not true for you? Skip to “Initiate Agile Programs,” and do the steps you need to. Then start any new teams on the appropriate team-level content and come back here when ready to continue with release preparation.
⇒ Steps: Get Buy-In for Scaling Scrum
Add Cross-Team Roles
Ensure True Believers
Some FuSca Guidance Roles are specific to multi-team programs. Although these lend themselves to existing job titles, I think it a mistake to simply designate individuals for the Cross-Team Roles. The psychology of someone who enjoys project management may not lend itself to the much leaner facilitation role of an Agile Release Manager, for example. It’s not enough for these people to agree with the desired agreements—they have to believe enough to implement them!
I recommend writing up job descriptions based on the information below and conducting an internal hiring effort. If you don’t find someone enthusiastic about the role, that is a clear sign that you have not gained enough buy-in yet.
⇒ Steps: Prepare to Fill Cross-Team Roles
Explain the Roles
Agile Release Manager
Take what you know about the sprint Facilitator role, add a little of what the Team Guide does, throw in training skills, and you will have a pretty good idea of what the Agile Release Manager (ARM) does. The key differences are that the ARM works across teams the way a Facilitator works across individuals, and facilitates the planning of releases instead of sprints. Specifically this person:
- Facilitates agreements on the release cycle and planning practices.
- Ensures features are identified by the Customer(s) in the format and timing needed by the teams.
- Facilitates Release Planning Meetings to ensure sufficient work is identified and ready for team planning by the start of each Planning Release.
- Facilitates release retrospectives and documents the agreements on cross-team practices.
- Trains and coaches program members on cross-team practices, eliminating the need for program-level Agile coaches added by some other scaled Agile frameworks.
- Networks to address issues external to the program with leaders of other programs or functional groups across the enterprise.
- Is the primary defender of Agile processes from interference by customers, managers, or others in the company.
Like the Facilitator role, in all but the largest programs, this can be part-time as well. By definition, anyone currently serving as a classic release manager in your company will probably convert without issue. That role is often part-time, too, filled by someone doing engineering or testing the rest of the time.
In theory a program, project, or functional manager could make the transition, speaking as someone who has held each of those positions. In practice, unfortunately, people with this background seem to struggle with letting go of the “Triple Constraint,” and their habit of controlling rather than coordinating. Plus, many of the classic program/project management tasks are spread out to groups or pushed lower in the organization. Unless the PM is assigned to three or four times as many units—like a full-time Facilitator guiding three or four teams at once—the PM is likely to do things an ARM is not supposed to do, in an understandable effort to justify their pay.
My typical recommendation to clients is to transfer or hire someone not previously associated with the program, but with some Agile exposure, training skills, and significant facilitation experience. People who have done similar roles using other Agile-at-scale methods, such as a Release Train Engineer from SAFe, are no more qualified than those who haven’t. In fact, I know from many heated discussions that a SAFe fan is likely to resist the parts of Full Scale agile that differ. When you interview people about this role, make absolutely sure they can let go of whatever they did before and are willing to follow the system exactly as presented until the Performance Standards are met.
Once the role is filled, have them read any part of this site they haven’t. Besides needing a comprehensive view of the system, they will benefit from knowing the environmental factors working for and against them in your company, as discussed in “Create an Agile Enterprise.”
Architects
Traditional functional managers—silo leads like a Product Engineering Leader or Quality Assurance Manager—often resist pure Agile methods for a reasonable reason: They fear for their jobs! After all, if the teams are self-organizing and outsiders cannot assign work, how do the managers add value?
Meanwhile, traditional system architects and analysts wonder what is left for them. They are no longer asked to create a detailed system analysis or technical specification and hand it off to be implemented. How do they now add value?
The answer in both cases is, “Through your subject-matter expertise.” In FuSca these experts, called by the more generic term “architects,” may be asked to:
- Research best practices related to their area of expertise.
- Facilitate identification of, and agreement on, cross-team functional practices based on those best practices.
- Provide formal training and individual coaching on functional practices.
- Drive recommendation and adoption of particular functional tools (hardware, software, and/or services).
- Provide initial direction and ongoing recommendations on the design or architecture as related to their function, and facilitate and document agreements (per “Agile Architecture”).
- Co-evolve the design and architecture with the teams throughout the project, creating rapid changes to the minimized documentation.
- Help with “make or buy” decisions regarding whether to develop something internally or seek external resources.
- Screen job candidates for the teams to ensure the candidates have the minimum technical skills required for the function.
- If the company uses performance evaluations, provide input on the individual’s functional skills and future developmental needs.
In larger companies, there tend to be two different types of architect, depending on whether they were a functional manager or a system analyst/architect. The traditional functional manager is required by the company to continue the usual functions of hiring and performance appraisal, unfortunately. They usually support people in various teams, and sometimes in both agile and non-agile programs. As explained under “Structuring for Agile,” they can continue to do so, but in an agile way that frees more time for the bullet items above. For people who enjoy the power of their positions, this change can be a struggle.
Most system architects I helped through the transition have reported being happier with the new role, since it affords the fun of collaboration; less wasted planning effort; faster movement from idea to reality; and more hands-on work. As an architecture expert quoted elsewhere on this site, James Madison, wrote, “An architect should spend as much time as is reasonable physically collocated with the team and product owner to maximize opportunities for direct communication.”[1] The change also reduces work stress because there aren’t people pressuring you to complete a specification—fast—that includes a lot of unknowns. Instead you only have to come up with a starting point that takes a few weeks, after which you will get the same stress-relieving benefits related to schedule that FuSca provides to engineers and testers. Finally, mistakes are no longer yours alone to make. Lots of people will be involved in architectural decisions, meaning the Agile Performance Standard about “no blaming of individuals” applies to you, too!
⇒ Steps:
Agile Liaison
Few are the companies progressive enough to embrace agile thinking across the enterprise. Most think of agility as something only for software development, or maybe for research and development more generally. That means agile teams must interact with non-agile groups to get and provide information and/or deliverables. Those groups have little understanding of the impact their decisions will have on deliveries, much less the harm those decisions can do to achieving the Agile Performance Standards.
Wise program sponsors and ARMs thus will recruit Agile Liaisons (ALs) from each of those organizations to perform relevant Customer and Team Guide duties related to their units:
- Provide work requests from their units as epics or user stories, using the correct formats and program processes.
- Provide input into epics and user stories of interest to their units.
- Provide information requested by Guidance Roles and teams on relevant deliverables either in planning or under development.
- Attend parts of Release Planning Meetings, Grooming Sessions, and Planning and Demonstration ceremonies as desired or when requested by the facilitators.
- Funnel work requests from the agile organization to their units and coordinate those to ensure unit deliveries fit sprint and release performance needs.
I have not found it difficult to recruit people for these positions. In most cases the non-agile groups were suffering a lot of pain due to lack of coordination with the people creating requirements or the development teams. Rarely have meetings I held with the manager in charge of the function gotten past my description of the purpose before the complaining began about the current state. When I explain that this role and other parts of FuSca are intended to address most of their complaints, I often had more than one volunteer! That is good, because you also want a backup named who can seamlessly fill in for the primary AL when they are absent or busy.
⇒ Steps: Identify Agile Liaisons
Organize the Work
Create a Portfolio
Create and Rank Epics
FuSca release planning centers on epics. As explained before, these are simply requirements that provide a larger function or feature over two or more sprints (see “Epics”). They are written in the same format as user stories and get the same kind of grooming, though by the cross-team roles, Customers, and TGs instead of team members. They cover the same types of requirements: user, market, business, and technical. They are in the Product Backlog, which now contains epics instead of stories and is at the program instead of the team level. They are rank-ordered against each other for prioritization. Planning moves them to a “Release Backlog,” a list in the tracker the ARM creates that shows all epics assigned to a release. Prior to the Final Release Planning Meeting, they are only “proposed” epics; after that, those that remain are “planned.” (The rest have either been deleted or moved, either back to the Product Backlog or proposed for the next release.) The only sizing required is that an epic must be small enough to complete within one Planning Release.
Before the first Release Planning Meeting of your first Planning Release, the Customers and Architects must have created enough epics to potentially keep the teams busy for the length of the release. The stories to deliver the epics in a particular release are created later by the teams. Each epic’s stories form a subset of the Release Backlog called its “Epic Backlog.” A team that does release planning uses either of those views to create its Sprint Plans instead of pulling directly from the Product Backlog. That is, the stories in each are rank-ordered and the team draws from them during the Planning Ceremony. Don’t get too hung up on all of these backlog types; the relevant steps use the generic word “backlog” for whichever type the team is using.
The Release Backlog can be revised by rewriting the epics, deleting them, or re-ordering them. But unlike the Product Backlog, which can contain stories that may never get done, the goal for the Release Backlog is to empty it—that is, to complete all of the stories in all of the epics. Here is a basic decision tree to illustrate what happens to each epic by the end of each Planning Release Ceremony:
That is, before and during the Release Planning Ceremony, any given epic and its related stories can move back and forth between the Product Backlog, current Release Backlog, and next Release Backlog, or may be deleted. The Epic Backlog is not a separate container, just a filtered view of that epic and its stories within the Release Backlog.
Organize a Portfolio
A portfolio management function in an Agile tracker allows creation of nested categories of work, called “portfolio items,” that roll up from lower to upper levels. For example, each team’s stories and standalone defects attach to epics; all epics could combine into “Products”; and all products into “Strategies.” That way a picture of overall progress is provided at whatever degree of granularity a manager or executive needs.
Portfolio items are held in one-to-many relationships. This means a higher-level category can have multiple categories underneath it, but each of them belong to only one higher-level item. For instance, a grocery chain might use this hierarchy for a program to improve its supply chain for individual products:
“Food” is the program, and “Vegetables” and “Fruit” are projects. Notice that “Food” can be “Fruit” or “Vegetables,” but “Fruit” can only be “Food” (not “Paper Products,” for example).
In at least one tracker with this feature, the categories can be rank-ordered. Combined, these features make a portfolio management tool a powerful means of implementing strategies, prioritizing competing projects, and tracking progress across teams.
FuSca does not require a portfolio hierarchy. However, larger companies with multiple product lines, especially where multiple teams contribute to the same project, will gain a competitive advantage in efficiency by choosing a tracker with this capability and using it faithfully. Then come up with a single scheme across the organization for at least the top-level sets of categories. This becomes the means for the organization’s leadership team to convey and rank-order strategic initiatives, and Customers to do that with the levels used in implementing those initiatives. It eliminates the logical absurdity that “everything is #1,” a mindset that invariably causes significant conflict, duplication of effort, and wasted labor hours as people are yanked from project to project.
Here’s an example of a portfolio hierarchy showing portfolio items above and below an investment management website called “Wealth Manager” to be sold to companies as an employee benefit, the “Product” (Level 3) in the table below:
| Level | Name | Description | Item | Level Owner |
| 1 | Strategy | Company-wide investment category | Commercial Sales | Leadership Team |
| 2 | Program | Multi-product initiative | Benefits | Program Mgmt |
| 3 | Product | Deliverable sold to customers | Wealth Manager | Product Mgmt |
| 4 | Epic | Set of functions marketed to customers | Investment Picker | Product Mgmt |
| 5 | User Story | Small user or back-end function | Fund search | Team Guides |
The Wealth Manager is one of several products in the Benefits program, itself one of several programs which support the Commercial Sales strategy.
Since managers are the primary audience for the progress data in the middle layers, it makes sense to work across organizations to build consensus on what types of items should appear at a given level. The Marketing Department and Design Group might have radically different types of items they consider “Epics,” but both have deliverables of that size they can link to the Wealth Manager portfolio item. An advertising campaign for the company as a whole is not technically a company product, but it is a deliverable with customers—the top leadership team—so why not refer to it as a “Product?” In the table above, you’ll see that the heads of the company pick the initiatives; middle managers work out the middle three; and the teams via their Team Guides have final say over the bottom level.
ID the MRP
The “minimally releasable product” or MRP is the smallest set of epics that will result in a useful deliverable to end users. (For a product offered to buyers, think of this as the “minimally sellable product!”) The first Version Release will include the MRP at minimum, and preferably some additional functionality that pleases customers, plus continuous improvement epics. Only the tiniest software or nontechnical projects will provide a finished product in one Planning Release, though they can easily provide new versions in each Planning Release. The MRP is “good enough” for end-user testing, marketing demonstrations, early adopters, or whoever needs an early look at a functioning product.
In a warehouse redesign, the MRP might be a fix to the 20% of causes we believe cause 80% of our problems with safety or efficiency, per the Pareto Rule.[2] The MRP can be implemented right away, which will in turn provide feedback for future iterations.
For a new Web site, the MRP might be a fine-looking site with minimal content and navigation. The customer has accepted the proposed layout, graphic types, fonts, and colors and added enough pages, links and navigation to go public. On the other hand, if you are developing a new “smart” toaster design for another company to sell, the MRP might be a 3-D model and bill of materials taking several Planning Releases to develop. However, the MRP is not necessarily the same thing as the “minimum viable product” or MVP from the startup world, which does not (contrary to a common myth) have to be a product or app.
The Customer(s) must identify the user and market requirements for the MRP. The other Guidance Roles then add the “must-have” business and technical requirements without which those user and market requirements cannot be released. Your tracker should provide one or more ways to designate the MRP options, such as a Version field or a Tags/Labels function. Each Planning Release will be made up of MRP and continuous improvement efforts. With luck, in the last Planning Release of a Version Release, you will have extra capacity to work on epics that add value for the customer or get a jump on the next Version Release.
↑ Plan in Releases | → Run the Release
[1] Madison, J. (2010), “Agile–Architecture Interactions,” IEEE Software, March/April:41.
[2] For instructions on doing Pareto analysis, see “Pareto Chart” on my Radical Agilist site.