wio-
原标题：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?
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:
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:
Each of these can cause some confusion, so let"s clear this up.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
On the day two kick-off, management presents risk solutions.
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.
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.
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?
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.
Ensure your base engineering practices are strong, or make effo
分享好知识！