Why is agile SAFe

Agile methods: On the way to more agility with SAFe

Regardless of whether they are products, services or complex services: Agile frameworks have now become established in many organizations - the best known are Kanban and Scrum. However, the requirements have grown significantly in recent years. While only a few teams used to work on a product in an agile manner, now it is important to manage a large number of different teams that work on several applications, some of which are based on one another. In addition, organizations have to react flexibly to changing requirements and want to scale their business on a larger scale.

The greatest challenges include dealing with existing dependencies, the organization of the individual work steps and communication between the project teams and stakeholders from other departments. The coordination effort for the responsible Scrum Master, Product and Process Owner is correspondingly high. These are particularly important when people are members of several self-organizing teams and unexpected problems and delays arise. Especially when organizations continuously develop projects and product portfolios, adapt flexibly to changing market conditions or want to digitize their entire business, they need tools with which they can manage these complex constellations in an agile manner.

Scaled Agile Framework - the emergence

Dean Leffingwell has been one for many years the Experts in the agile field. As a coach and consultant, he supports the implementation and application of the Scaled Agile Framework (SAFe). Through his many years of experience as an entrepreneur, methodologist and consultant, Leffingwell has demonstrated his leadership skills. In 2013 he became the co-founder of Scaled Agile. His idea to develop the Scaled Agile Framework arose from the problem that numerous Scrum teams within a company had to deal with many restrictions. Organization and coordination of the agile teams were the thoughts that he wanted to answer with his framework. Since version 1.0, Leffingwell and his team have been developing further releases and gradually making them available on the market. Version 5.1 is currently available.

With four ready-to-use configurations, the framework supports the entire range of products and applications in an organization - from a few small teams to the complex systems that thousands of people are involved in developing and going live. Depending on the size, complexity and degree of maturity, Essential SAFe, Portfolio SAFe, Large Solution SAFe or Full SAFe can be used. According to the authors, the difference between the various models lies in their complexity and objectives. Full SAFe not only focuses on complex implementations that are available to customers, but also on corporate development. Scaled Agile repeatedly refers to the term business agility: the ability to be competitive and grow in the digital age by reacting quickly to changes in the market and emerging opportunities with innovative, digitally supported business solutions. In addition to using Full SAFe, business agility can also be achieved with Portfolio SAFe. Essential and Large Solution SAFe can help organizations bring complex solutions to market using multiple agile teams.

When deciding on a framework, it depends on what goal an organization is pursuing: If it tries to deliver complex applications, a framework is required that helps to coordinate several teams (Essential SAFe / Large Solution). Portfolio SAFe, on the other hand, tries to organize the strategy using value streams in such a way that added value can be continuously achieved through the implementation of the goals.

The most important core points include the formation of cross-departmental teams, the organization of activities in so-called Agile Release Trains (ART), as well as the continuous development of projects, products and people.

The journey with the Agile Release Train

One of the most important prerequisites for agility is the elimination of previous boundaries: An agile team does not only consist of IT specialists, but is staffed by other people who can provide technical input or benefit directly from the developed scenario. Depending on the methodology used, there is also a Scrum Master who is responsible for process optimization and obstacle removal and coordinates the processes, as well as a product owner who ensures that the output achieved by a team also meets the agreed requirements of a product manager. The Scrum Master can support both Scrum, ScrumXP and Kanban.

Agile teams can use Scrum and Kanban in a wide variety of ways. An agile team can work within the framework according to Scrum, Kanban and "Scrumban". There are often differences in the framework when it comes to wording. SAFe speaks of agile teams that can look exactly like a Scrum team, but are not called that.

According to the authors, Scrum can be helpful in the implementation and use of SAFe, as the already lived mindset can make the implementation and living of agile values ​​a little easier. Nevertheless, it must be made clear that not the entire Scrum framework, as it is taught, is used in SAFe.

To implement complex projects, these agile teams are bundled and additional roles such as product management, system architects and business owners (stakeholders) are added, and a so-called Agile Release Train (ART) is created.

This is exactly where one of the differences to project development based on the classic waterfall model lies. Longer planning phases, such as in project management, do not exist in agile frameworks. Attempts are made to plan in more detail and to focus more on customer involvement. The agile approach is not the panacea and is not suitable for every organization. If you know exactly what kind of product is to be created in the end and are still bound by strong framework conditions, then, in the opinion of the authors, classic project planning and development is the better. For example, you yourself have a planning phase in which you create project plans or a business case. In so-called management phases, they try to define work packages in detail, which in turn work out individual specialist teams. Not always, but often, these teams are slowed down by older processes and hierarchical structures (rather general and extreme).

Agile tries not to invest a lot of time in large, long-term planning. Why not? There are three reasons for this: On the one hand, it is not yet clear what the product will look like in the end. In addition, the requirements can change in the course of development. The stakeholders should also be included on a regular basis in order to show progress or to be able to make new adjustments more quickly.

As long-term planning becomes more difficult, many companies have switched to the agile mindset. In agile product development and also in SAFe, a "fixed" budget is therefore planned for each value stream. If something needs to be changed at the adjusting screws of the agile triangle (time-cost scope), it is usually the scope. For this purpose, overarching "high-level" goals are defined, which can be achieved within this time and with the defined budget. On the way there will be many new requirements to be implemented and existing ones to be discarded. However, if the agile values ​​and the way of thinking in the respective organization have been understood and are also put into practice, then at the end of a defined time window an implementation occurs that satisfies the customer in question.