Net Objectives' Approach to SAFe

A few words about the Scaled Agile Framework (SAFe). If you are not familiar with SAFe, here is an excerpt from its creators website on SAFE (www.scaledagileframework.com/about): SAFe? is an online, freely revealed knowledge base of proven success patterns fro implementing Lean-Agile software and systems development at enterprise scale. It provides comprehensive guidance for work at the enterprise Portfolio, Value Stream, Program, and Team Levels.

Net Objectives’ End-State Vision Using SAFe

The Scaled Agile Framework is a great platform to begin an Agile transformation. There are many concepts and directives that SAFe provides that are essential in doing Agile at Scale. SAFe provides a foundation of several elements of Lean Thinking – in particular, systems-thinking with a focus on removing delays in workflow and feedback with attention to quality. It also provides an approach that drives from delivering business value, while aligning technology with business strategy, with attention to having business strategy create the contexts for programs and team. The suggested intake process can avoid overloading the technology group by enhancing the focus on the most important identified work. SAFe helps to create a holistic view covering the entire value stream and a planning method that facilitates vertical and horizontal coordination of stakeholders and teams. These concepts and directives are easily identifiable in SAFe’s big picture, which defines a path for success and everyone’s role on the journey. These are good things and provides a good starting point for an organization.

For some organizations, SAFe by itself is sufficient, but for larger organizations (2,000+) that have inter-leaved products and whose shared services (e.g., business intelligence) are required to support multiple products, some additional practices are needed.

It is important to remember that SAFe is a framework and not a total solution in and of itself. There are many areas where SAFe provides mere awareness of issues you must solve, not a full solution. In addition, there are several practices we have found useful that are not included in the framework. While the standard courses and website might tell you what to achieve, they do little to tell you how to do it in many areas. The essential difference here is that we look to SAFe for ideas when provided solutions don’t exactly fit the needs of your organization. We use the principles of Lean-Agile to guide us, along with other practices (to be discussed later in this paper).

These principles and practices include the following:

  • Alignment across portfolios to achieve quick value delivery
  • Management of requests for shared services when requests come from trains in different portfolios
  • The ability to track requirements properly with tools
  • The role of management
  • Acceptance Test Driven Development (ATDD)
  • Agile architecture and Agile technical development
  • Forming trains when cross-functional teams cannot be created
  • How to migrate from component teams to feature teams
  • Continuous integration
  • Transitioning to SAFe when a full-blown all-at-once implementation will be less effective than focusing on what your problems are

This list delineates the picture of the end state for transformation. Once the organization is following these principles and practices, it will have implemented the following essentials:

  • Alignment via selection and sequencing of value
  • Leadership and management
  • Technological considerations
  • Organizational structure and transformation 

A successful transformation of an organization with SAFe must address all of these essentials. We will go through each of these here. 

Alignment Via Selection and Sequencing of Value

Alignment across portfolios is essential to avoid that challenge of most of a product being ready, but waiting for another train that’s focusing on something else to complete the last bit. This is a common challenge we see with almost all SAFe implementations where a product cuts across portfolios. The reason is a lack of agreement amongst the business stakeholders on what to focus on. (Overall, we follow the SAFe guidelines for aligning among stakeholders, product owners, and product managers.)

In 2006 Net Objectives started using the concept of the minimum business increment (MBI) to address this problem. Essentially an MBI is the smallest chunk of business value that can be realized that makes sense from a business perspective (that is, marketing, deployment, sales, support and other issues must be considered). An MBI is selected based on which target market will achieve the greatest value. By using this context, the identification of what needs to be built can be achieved prior to the planning event.

Sequencing of these MBIs must also be guided by a definition of business value that is agreed to across the organization. We use an enhanced measure of business value by getting business stakeholders across portfolios to agree on what is important to the business (for example, revenue, customer experience, lowering costs, compliance, …). Each company will have a different set. By achieving this agreement alignment on which MBIs are truly most important can be achieved. This is essential to manage where we put our capacity.

An important note here is that by sequencing MBIs we are able to focus on which specific items need to be built in order to achieve business value realization. Sorting features by themselves are insufficient because sets of features don’t always deliver value. 

A key component of this approach is the integrated use of Acceptance Test-Driven Development (ATDD). By having product owners, developers and testers write stories together based on the MBIs everyone in the value stream understands what to build, why it’s of value and the relative value of the pieces.

The Importance of Tools Supporting Requirements

The key to alignment is for everyone to understand the relative importance of what they are working on. In particular, at the team level, the items on a backlog must be consistent with the overall order of the MBIs – pieces of which will often cut across multiple portfolios and trains. This requires sophisticated setup of the tools being used. While Net Objectives is tool neutral we have done this with several tools including AgileCraft, Rally and Version One.

Alignment of Shared Services and DevOps

Adding Kanban’s use for shared services and DevOps was a great addition for SAFe 4.0. However, merely having a role for it is insufficient. Because both shared services and DevOps are fielding requests from several different stakeholders and portfolios, alignment of what they are working on is also essential. The alignment via MBIs and tooling discussed previously can provide this.

Leadership And Management

We extend SAFe’s management concepts with Middle-Up-Down Management written by Ikujiro Nonaka, one of the co-authors of “The New New Product Development Game” which is the basis for Scrum. In a nutshell, the role of middle management is to see the direction of upper management and create an environment within which those doing the work can work autonomously to achieve it.

Fundamental to our approach is a set of agreements that all roles in the organization make together. Taken together, these agreements have an outsized impact on organizational development, keeping everyone aligned and on track for transformation.

The path to aligned management requires a set of agreements that everyone must agree to. We call these guardrails because it both gives a target to achieve while providing guidance on whether you are aligned with those goals. These agreements are:

1. Work on items that will have us realize the greatest amount of business value across the enterprise

2. Collaborate with each other in order to maximize the realization of Business value across the enterprise

3. Ensure that all work is visible

4. Take the necessary steps to sustain or increase predictability

5. Keep the work throughout the value stream within our capacity

6. Encourage everyone to strive for continuous improvement

These agreements are clearly consistent with SAFe. By calling them out we provide guidance on what actions to take when a clear answer is not available.

Technology Considerations

The importance of Agile Architecture cannot be overstated in large scale Agile transformations. While SAFe continues to grow, this is an area where little has been added over the last couple of updates. Net Objectives was the contributor to SAFe for both ATDD and technology. We have a broad offering of services on:

  • Agile architecture
  • Emergent design (TDD and design patterns)
  • Essential skills for the Agile developer

While it is often not required to start with these issues, it is essential that they be addressed relatively soon.

Net Objectives’ approach here is a combination of on-site training and on-line guided self-study.

Organizational Structure

SAFe provides good guidance on the end state of how teams are organized. The preference for feature teams over component teams is good. Unfortunately, many organizations find themselves in having difficulty in creating either of these. The reasons is that several people are often required to assist several teams at one time. 

Net Objectives consultants provide guidance here in starting as far along as you can and changing over time as insights and new skills allow. This requires a combination of Scrum and Kanban at the team levels. We have created an integrated approach called Leanban. This enables consistent, effective use of Scrum and Kanban without the “Agile wars” we often see. In addition, we’ve pioneered several train organizational approaches that can be applied as needed. 

Transforming an Organization With SAFe

All too many organizations just jump into SAFe with an “all-in all-the-way” attitude. Even when not adjusting the framework it is essential to transition to it at the pace the organization can accommodate. In any event, however, no one size fits all. We begin with understanding the challenges you are facing and how they interrelate to each other. The next step is to decide what improvements to start with. While there are a dozen practices that must be implemented in order to be effective in building software, it is best to focus on those that provide the most benefit and prepare the organization for the next ones. This provides everyone with a well-defined answer to “what do we do?”

Then, on a regular basis, we work with you to validate how you are doing and whether you should modify the assumptions and practices on which you are working. This enables the organization to have a well-defined solution that is tailored for them while adjusting it on a regular basis as the organization improves.

Other articles of Interest

Go to www.netobjectives.com/articles to see the following articles:

  • The Business Case for Agility
  • Why Tailored Agile Transformations Are More Effective, Less Expensive and Less Risky

Like This? See our course Dec 19-20


 

 


Michael Küsters

Thought Provoker / Founder @VXS

8 年

You have a very interesting perspective on SAFe that, while describing the same framework, seems to emphasize completely different aspects thereof. The first difference is that my understanding of Lean-Agile Principles is not a set of practices that may be situationally helpful - to me it's the Big 9 of Don Reinertsen. The second is that I do not consider SAFe to provide an "end state" for anything. Much rather, SAFe provides a clear picture of sensible "next steps" for an organization that has no answers to the scaling challenge yet. The third is the role of middle management. In my opinion, SAFe does not strengthen middle-management - it provides a safe adjustment sandbox wherein middle managers can reorient themselves from executors towards growers of people ("lean-agile leadership"). The fourth is that while SAFe emphasizes "Deliver Anytime", which clearly requires solid Engineering Practices - the analysis which specific practices make sense in context is essential to minimize overhead and maximize effectiveness. And the fifth, probably most glaring, difference is that unless you have convincing evidence and good reasons, in the "Shu" phase of learning, customization and "taking baby steps" are generally inadvisible. Now, I am by no means saying I am "right" - it's just interesting how different the things are different people can see in the same thing. SAFe is a credible, reliable container to transform an organization which needs to answer the scaling challenge. The reliability of the content depends strongly on the reliability (i.e. experience) of the RTE.

要查看或添加评论,请登录

Al Shalloway的更多文章

社区洞察

其他会员也浏览了