原标题：4 biggest challenges in moving to Scaled Agile Framework (SAFe)

Adopting the Scaled Agile Framework, or SAFe, can be tricky, and some parts more so than others. Here are some of the biggest challenges and suggest some techniques to make potential problem areas easier to overcome. (Note: We're assuming you have some familiarity with SAFe. If you don't, or you simply need a refresher, see my introductory TechBeacon article, posted last month.)

So what are the top problem areas?

1. Identifying your initial epics
2. Identifying value streams and your initial trains
3. Executing a release planning session
4. Ensuring code quality

There are other elements that will need to be addressed, including how to prove that SAFe is measurably benefiting the organization, how to create a transformation team, how to move to SAFe-style portfolio budgeting, and more. I will share my thoughts on those passion areas down the road. For now, let's focus on the following four problem areas:

1. Identifying your initial epics

I have seen clients stall in the process of defining their initial epics. Because defined epics are the fuel for the train, stalling or failing to understand this part of the process can derail things quickly. But defining initial epics doesn't have to be that hard. First, let me clear up some misconceptions.

There are technically four categories for epics, and each is a combination of two categories:

1. Portfolio epics vs. program epics
2. Business epics vs. architectural epics

Each of these can cause some confusion, so let's clear this up.

What is an epic in SAFe?

Before SAFe came along, people used the word epic to indicate a user story that was too big to fit into one sprint but was otherwise exactly the same and even written the same way. "A user can" or "As a I want to so that."

But in SAFe, this is not the case. Clear that definition from your mind. Instead, SAFe defines an epic as "enterprise initiatives that are sufficiently substantial so as to warrant analysis and understanding of potential ROI before implementation." SAFe also advocates creating a lightweight business case for each epic.

This should sound familiar. In the pre-SAFe world, this would be similar to the definition of a software project or program. Both require a business case. Both require an ROI analysis before funds can be allocated to it. The big difference is that once a project is funded, a team must be created to work on it. In SAFe, approved epics are pulled by a pre-existing train. This follows the same pattern you see in scrum, asking for dedicated teams but, as usual for SAFe, on a much larger scale. For example, this team is 50 to 125 people instead of 5 to 9 people.

Portfolio epics vs. program epics

There is a strong misconception that every program epic must be a child to a portfolio epic. But the real definition is simple: A portfolio epic spans multiple agile release trains (ARTs). A program epic belongs to a single ART. That's it. The few portfolio epics are broken down into program epics — generally one per train that is involved in the portfolio epic — and that is where people seem to get confused. But this is the exception, not the norm!

Imagine if there were zero overlap between trains (the ideal state in train design). There would be no portfolio epics, just program epics. The other extreme is trains that are so poorly designed that every epic requires multiple trains to deliver value. In this case, 100 percent of the program epics would trace back to a portfolio epic, and that would defeat the whole idea of trains being dedicated teams delivering concept to cash value.

To add to the confusion, both program epics and portfolio epics are generally kept on one backlog, called the portfolio backlog. Portfolio epics originate from the program portfolio management team, while program epics originate from a train. A train can create a program epic as a stand-alone epic, or they may see a portfolio epic that they are a part of and create a program epic to scope their part of the portfolio epic. Both, however, go through the portfolio Kanban (think project pipeline) to ensure transparency and good metrics on throughput.

So to recap, here is the important part. From the ART perspective, all epics are program epics. Only some link back to a portfolio epic.

Now, what is the realistic blend of program vs. portfolio epics? Think 80/20, where 20 percent are portfolio. In fact, SAFe talks about having trains create a budget reserve for portfolio epics and keeping the rest for local program epics. That budget could easily be split along 80/20 lines.

Business epics vs. architectural epics

There is less confusion about business and architectural epic categories. Business epics provide value to your customers, while architectural epics improve the portfolio's ability to deliver value as well as the quality of the value delivered. But the one spot of confusion I see is that there are also architectural features, and teams believe that they all originate from architectural epics. In fact, architectural features can come from either business or architectural epics.

Identifying your first epics

So, if the above is now clear (or at least clearer), we can focus on how to identify your epics. Most companies I work with already have a pipeline of projects that have not yet been funded. They have an intake process for new projects. Some call them proposals and flip them to "projects" only after they are funded. The fastest way to get your initial epic set is to convert your current proposals, projects, and programs to epics. This will also help you start to realize what your trains might be. Think of permanent program teams instead of assembling teams. Your current programs and projects already have teams working them, and these could actually become your initial trains of dedicated resources as well.

2. Identifying value streams and your initial trains

More than any other part of SAFe, my clients seem confused on the real definition of a value stream. But with an easy-to-understand example, we can unlock the answer. But there's one important thing to remember: the purpose of a train in SAFe. Traditional unscaled agile methodologies such as scrum ask for "dedicated teams" to ensure a stable velocity. SAFe asks for dedicated large teams to ensure stable project throughput. These are teams of 50 to 125 dedicated people. And as noted above, they call this team an agile release train, or ART. And like an agile team, the goal is for them to be completely self-sufficient. Or close to it.

OK, now on to an example that most everyone can understand.

Imagine we have a company called Nanosoft, and that it has three major profit centers: productivity software, operating systems, and consulting. What should these three ideas become? The immediate thought is that they would be great value streams, since each is a separate source of value. The truth is, with SAFe, it's all about size. SAFe solves the problem of large teams or multiple teams that have functional dependencies between them. And their sweet spot is 50-plus people.

Scenario one

So, in this example, imagine there are only 20 developers for all three of these value streams. It wouldn't make sense to have three trains. In fact, you may not need SAFe at all since you are below the 50-person mark. (Of course, if these 20 people all had SAFe experience, they would likely still steal a lot of the best practices from SAFe despite their smaller-than-50 team size.)

Scenario two

But now let's imagine we have 50 to 125 developers for each of those three value areas. Now we have a choice: You could have one value stream with three trains:

productivity software train, operating systems train, and consulting train. (You may be asking, "What if the consulting train didn't develop software?" That is a topic for another article: SAFe for non-software development.) Or, you could have three value streams, each with a single train. My advice here: start simple, and expand only when evidence shows you should. So, in this case, create one train.

Scenario three

Now let's scale up even further. Imagine the value streams have a whole lot of developers. Imagine that for productivity software we have four major products: NanoEdit, NanoSheet, NanoPresenter, and NanoPlanner. Further, operating systems includes PC, mobile, and cloud. Each of these seven product areas has between 50 and 125 developers. Now we have a case for creating three value streams, each with multiple trains.

Planning your value streams and trains

The trains are a dedicated team of 50 to 125 people, and that is the number one driver as to how many trains and value streams you will need. Start as simple as possible — one train, one value stream — unless you have more than 125 people. If you do have more, look to your current lines of business for guidance. If you are developing software for internal clients, value streams are about either your internal products or the client types you have. Ensure you put a skill growth system in place to find skill gaps in your trains and close them as much as possible.

3. Executing a release planning session

Many teams have gotten to the release planning session and found their readiness to be lacking and the momentum to be less than they had hoped for. Others hit the ground running. To figure out how to be in the latter group, we need to study the two-day agenda of the planning meeting.

Take a look at the SAFe diagram. If you click on the two-day agenda for the release planning session (find it in the middle tier, right of center, under a yellow, 90-degree inverted tab called "Release Planning"), it may seem overwhelming, at least at first.

Split release planning into 3 identical parts

I'm a big fan of simplification. So here is a simplification. Each of the two days can each be understood as having three identical parts: kick-off, breakout, and wrap-up. It's simply a matter of understanding how the three parts differ by day.

Day 1: Kick-off

On day one, the kick-off focuses on just four things: sharing the business context, the epic vision, the architecture vision, and the top 10 features for the program increment (along with explaining how to do the breakouts). That's it! We need to prep these if we want a strong release planning event.

Day 1: Breakout

The day one breakout is fairly straightforward. Teams allocate stories across four sprints (you can adjust this, but four is the recommendation from SAFe). Right now, I expect a ton of agilists to be leaping out of their seats. "Four sprints? That's waterfall!" Further, SAFe mentions that 70 percent of these stories should be ready before the release planning event starts, which flies in the face of two big agile concepts: creating your stories together, since the conversation is critical to understanding the story, and doing the stories in the sprint when they are due.

(Yes, folks, some teams never do any story refinement/grooming and only refine stories for the sprint within the sprint!) So this is definitely at the other extreme. However, the teams still collaborate to form estimates and acceptance criteria and to task the stories, and they can adjust stories during the breakout sessions. Also, part of the breakouts is to abstract the many features into a smaller set of program increment (PI) objectives for the team. Teams also identify risks and impediments. Scrum masters meet.

Day 1: Wrap-up

The wrap-up on day one is where the teams present their PI objectives and risks. Contrary to what you might think, the objectives are rolled up to the program, not down to the teams. They are an abstraction of the stories to make things more digestible at the program level when there are a bunch of teams with lots of stories at the team level. They also present risks, and they are likely not done with the work. Also part of the wrap-up is that all of the teams take off and senior management sticks around to create action plans to mitigate the risks presented by the teams in their draft plan.

Day two shares the same pattern. Characteristics of each part follow.

Day 2: Kick-off

On the day two kick-off, management presents risk solutions.

Day 2: Breakout

The teams break out to finish their work. But this time, the business owners come around and put a value score on the PI objectives.

Day 2: Wrap-up

Finally, in wrap-up, the updated plans are presented and a confidence vote is taken (how confident are we that we can deliver what we came up with?), a retrospective is run on the event, and the event is over.

I hope this simplification of three identical parts per day makes the default calendar in SAFe a lot less intimidating to master and a lot easier to prepare for.

4. Ensuring code quality

The fourth challenge I want to discuss is ensuring code quality. With two-week sprints, I have seen some ugly engineering shortcuts happen. But the one thing I most worry about, and encourage you to look for, are stories that are really tasks and not units of business value. A story should represent some value to the business. It should be refined (with understood requirements), developed according to a good architecture, tested, and deployed to an agreed-upon environment. If your stories are just fragments of this, you've missed the boat. I've seen four sprints where sprint 1 is all requirements and sprint 4 is all test work. Hello, waterfall!

So how do we improve this? I have a theory, which starts by asking a question: What happens when you teach agile to a team that has poor engineering practices? Poor techniques for requirements, architecture, development, test, and deployment? You probably guessed it. It does bad work a whole lot faster.

So my first piece of advice is to ensure teams have strong, modern engineering practices before you let them go agile! What are these practices?

• Modern requirements techniques (scenarios, business rules, terms, nonfunctional requirements)
• Modern architecture techniques (intentional architecture, model-driven development, architectural patterns)
• Modern development techniques (emergent design, technical debt, test-driven development, continuous integration)
• Modern testing techniques (test virtualization, automated test, test management, test ideas, test cases vs. test scripts)
• Modern deployment practices (shift left, continuous deployment, mock environments)
• And don't forget DevOps, which permeates all five of these prior categories

I don't have enough room in a single article to go into depth on each of these, but mastering these practices is critical to "going agile" effectively. It's much easier to master the agile ceremonies: release planning, sprint planning, stand ups, collaboration sessions, sprint reviews (demos) and retrospectives. It's much harder to do excellent engineering in two weeks.

Step 1 - Ensure strong engineering practices

Ensure your base engineering practices are strong, or make efforts to improve them.

Step 2 - Understand the essence of agile

Ensure that the teams really understand the spirit of agile: collaboration, high trust environments, self-organizing teams. When ignored, these three alone can turn your agile adoption into a command-and-control nightmare.

Step 3 - Embrace innovation and trust the teams

Ask yourselves how often you say no to team ideas. Can we do three-week sprints? No. Can we do stories the original way "a user can," which Mike Cohn wrote about? No. Can we count tasks instead of estimating hours for our metrics? No. Can we publish a library of practices that are not vetted by a review board? No. The list goes on, and instead of saying no, you can say yes to these things. Embracing the spirit of agile means embracing innovation and trusting the teams to make the best choices.

Step 4 - Measure and measure

Of course, I recommend measuring the teams to ensure they don't fly too far off the rails. Measuring innovation can be done, and that's another topic I'd like to write about later on.

Action items in moving to SAFe

If your teams have strong engineering disciplines and they have embraced not just the roles and ceremonies of agile but the spirit of it, your adoption of SAFe will be incredibly smooth. As my colleague Ali Ali at Blue Agility says, each layer of SAFe (Team, Program, Portfolio) is a fractal of basic agile or scrum ideas. The same roles, the same ceremonies, the same values, but scaled up for team size and responsible ROI.

So there you have it, my four biggest challenges in moving to SAFe. I doubt I have addressed all the issues you may face, but I hope you find nuggets of actionable ideas you can pursue in your adoptions.

What is the single biggest challenge in moving to SAFe in your opinion? Why? Add your comment below.

原文
【4 biggest challenges in moving to Scaled Agile Framework (SAFe)】