Making Your Organization Agile with the SAFe Enterprise Agility Framework - dummies

Making Your Organization Agile with the SAFe Enterprise Agility Framework

By Doug Rose

The process of making an organization agile might seem complicated, but it’s surprisingly simple. The enterprise agility framework is generous about what a SAFe organization should look like. It has levels on top of levels, dozens of roles, and relationships between those levels and the roles. Yet the framework is stingy about what to do to make it work. You know where you need to be, but the system is not very clear about how to get there. And when you ask for clarification, SAFe’s answers aren’t very helpful:

  • When you ask, “How do I build an agile release train when I have well-established departments?” SAFe says, “You just do.”
  • When you ask, “What are some different techniques for making the large release train meetings effective?” SAFe says, “You just figure it out.”
  • When you ask, “How can I use team story points to make enterprise-level estimates?” SAFe answers, “Somehow it just works.”

You could easily forgive this missing information if SAFe were a lightweight framework like Scrum. Scrum has only three roles, three artifacts, and a few events. You’re expected to figure out a lot on your own. However, with a large system, such as SAFe, you need more guidance.

Plugging the gaps

Some of the people who created SAFe would be likely to tell you that the secret to success is in building high-functioning agile teams. That’s fine, but these teams still need some direction on making this large-scale organizational change. Following are some tips on how to make SAFe work for your organization:

  • Begin by choosing the SAFe configuration that’s most relevant to your organization. For example, Full SAFe, Large Solution SAFe, Portfolio SAFe, or Essential SAFe.
  • Try to understand the output of each of the key meetings. If you can figure out what you need, then you may be able to adapt the meeting to fit your organization. Remember that SAFe is a template and it’s frequently updated. If something doesn’t work for you, look for ways to make it work or look for a different way to achieve the same outcome.
  • Approach agile teams as virtual organizations within your larger organization. Think of each team having an objective and the personnel needed to achieve that objective. Engage existing management in a discussion of how agile teams break down silos and run across existing departmental boundaries.
  • Choose several people in the organization and get them trained as SAFe program consultants. Eventually, you must train everyone in your organization, so all of them understand SAFe in principle and practice, but getting several people trained early on is a good start.

    Give it more time. When a person is trained as a SAFe program consultant he has a week to make the transition. The reality is that most organizations will need much more time laying the groundwork for such a big change.

  • Start your training by introducing the following three key concepts (in this order):
    1. Queueing theory
    2. Value streams
    3. Agile release trains

      If you can get your organization to understand these key concepts, rolling out the framework will be much easier.

  • Develop a clear vision of how your organization will function with the SAFe framework. Choose the pieces of the framework you need to bring your vision to fruition. Only when your vision is clear will you be able to explain SAFe to others in a way they’ll understand.

Making your organization agile instead of fitting agile into your organization

SAFe is an attempt to fit agile into your organization, so the framework will feel as comfortable as an old pair of jeans. However, this can be a false sense of comfort that carries its own risks. It often seduces companies into embracing a water-agile-fall approach, which allows them to maintain a control culture they’re reluctant to relinquish and simply adopt agile for a smattering of teams within the organization.

To make your organization agile, you need to change its collective mindset, its culture, and you must break down the silos of clearly defined departments. Everyone in the organization needs to stop thinking so much about product and think more about process, and stop focusing so much on projects and shift his focus to value streams.

Agile teams break down large initiatives into smaller chunks that can be delivered by cross-functional, self-organized teams. In practice, that requires pulling people out of their clearly defined departments and giving up a great deal of authority and control to teams. Such changes are the most difficult to make, but they deliver the greatest benefits — innovation, responsiveness, and value to the customer. So, if you like SAFe because it seems familiar and comfortable, you’re probably liking it for the wrong reasons.

Starting communities of practice

A great way to maintain a SAFe mindset and culture is to start communities of practice (CoPs) within your organization. A community of practice is an informal self-organized group of people who share a common interest, typically in a specific technical or business area. The group meets regularly to collaborate, share information and insight, improve members’ skills, and continuously advance their collective knowledge of their area of expertise. In other words, they “talk shop.”

The good news is that in large organizations, such groups are likely to exist in various departments. For example, an organization is likely to have separate departments for software development, engineering, business analytics, information technology, accounting, and so forth. While these divisions may be challenged by the need to create agile teams, communities of practice enable and even encourage the divisions to persist.

However, CoPs need not be departmental. Sometimes developers create CoPs around a certain skill, such as Java development or programming in Python. They may even create a CoP around agile practices such as Extreme Programming or user stories.

While the primary goal of CoPs is to increase knowledge and skills in an area of expertise, a beneficial byproduct is that the groups can share their knowledge and experience of working in teams. In the process, their discussions can deepen their understanding and appreciation of SAFe and strengthen the SAFe mindset and culture.

As soon as you begin to form your agile teams and ARTs, start to encourage and facilitate the creation of CoPs. As soon as people in your organization receive their SAFe training and find out about CoPs, they’re likely to take the initiative to start these groups on their own. A large part of encouraging them is to simply get out of their way. Let them schedule and manage their meetings. You can also encourage the formation of CoPs by allotting time during the normal day to conduct the meetings and perhaps by budgeting for snacks and beverages.

A CoP should have a loose format. Maybe a Scrum Master will give a short presentation about something that’s worked very well for her team, or another Scrum Master may pose a question to the group that she needs help answering.

Don’t be too concerned if a few of your CoPs fizzle out over time. They tend to have a natural lifespan that gives out when the need for them no longer exists. Do be concerned if all your CoPs suddenly stop meeting. That usually means the people are spending too much time doing and not enough time learning.

Community of Practice lifespan
All SAFe content reproduced with permission from © Scaled Agile, Inc.
Community of Practice lifespan.

The concept of communities of practice is born out of the Lean approach to software development. A core value of Lean organization is continuous improvement, which applies equally to people, solutions, and processes.