Hi, welcome to this compact lesson where we combine the previously covered SAFe scalings into the Full SAFe scaling.
In the last lessons, we have been learned to know the SAFe scalings
- Essential SAFe,
- Large Solution SAFe,
- Portfolio SAFe,
- and the common foundation of all this scalings.
If we want to implement agility and lean management in a company for projects from the management to the implementation level “and” unmanageably large projects with many internal and external stakeholders, then we combine the Portfolio SAFe with the Large Solution SAFe to form the Full SAFe.
Attached to this lesson you will find a PDF in A3 format with the Full SAFe Overview. Depending on the project scaling you use, feel free to print this out and hang it on the wall in your project room as a basis for discussion and explanation to the team.
I can promise you in advance that this lesson will not be very extensive, quite the contrary: because the content of the components of this combination we have already discussed so far that the scope should be sufficient for a basic understanding in my opinion.
Nevertheless, I would like to mention a few interesting points about the combination:
- In Portfolio SAFe, Epics are broken down to Capabilities, Features, and Enablers directly at the Portfolio level. With the availability of the Large Solution level, only the Epics and Capabilities are defined in the Portfolio level.
- Breaking these backlog elements down to features is then done at the Large Solution level – as is the enrichment with Non-Functional Requirements (we will go into this later).
- At the program level, the features are then broken down to user stories. In addition, additional Non-Functional Requirements and Program Epics can be included at the Program level.
- At the team level, tasks and test cases are derived from user stories. Bugs and defects are also recorded here, broken down to tasks and test cases, and then solved. User stories are scheduled in sprints and the associated tasks and test cases are processed. In doing so, the implementation pays attention to compliance with the Non-Functional Requirements associated with the User Story.
If you are now ringing alarm bells and thinking that user stories should actually be created at team level, then you are basically absolutely right. However, practice shows that the creation of user stories in a large project at team level leads to unnecessarily multiple work, in that the requirements (i.e., user stories) recorded in the specialist departments have to be recorded several times per team. This usually also results in deviations in similar requirements, which subsequently lead to problems. For this reason, and in order not to involve the business department more than necessary for requirements elicitation, I prefer to write the user stories one level higher with support from the teams. This solution is efficient and leads to a more homogeneous solution, even if the effort for the team is minimally higher.
The team still assists with requirements elicitation, but subsequently only takes over the breakdown to tasks, sub-tasks if necessary, and test cases. Ideally, test cases are already predefined in the user stories in the form of acceptance criteria.
We have already gone through everything else together.
So, that was a quick run through SAFe. Time to draw an interim conclusion: We’ve spent a lot of time on the basics of SAFe, and I hope this has given you a good idea of the challenges we face in the day-to-day of large-scale projects and the tools we’re offered to solve them. I still suggest you to go through the links from the SAFe overview and also have a look at the related pages. I have presented only a fraction of them to you here in the last lessons on SAFe.
You also see that SAFe already takes some approaches from other methods and combines them coherently. This is exactly what we want to expand on after completing the project and process management basics, going much more in depth and supplementing it with my experience from the last 3 decades. But for now, here are the last two methods, the first of which we have already touched on both in Agile and within SAFe. Let’s start with lean management. So, get excited about what’s coming next.
