Skip to Content
Business Trends

Using SAP Activate in Scaled Agile Environment

Over the past few months I had opportunity to work with several customers that have adopted Scaled Agile Framework® (SAFe®) in their IT organization. The SAFe® framework is designed to scale agile processes for larger teams and organizations. It is one of the ways for organizations put more structure in managing portfolio or programs, projects and deployments. The framework itself is relatively complex and caters well especially to large programs and organizations. Coincidentally the organizations I visited with have highly engineering and manufacturing oriented company culture where I think SAFe® fits very well.

In all these visits the discussion I had with the program teams was about how to use SAP Activate in environments that follow SAFe®. I want to share few key points I have discussed with the customer program teams to help them take advantage of SAP specific deployment approach SAP Activate delivers while staying true to the SAFe® principles. One fair question to ask is “Why would we use SAP Activate when we have SAFe® and are adopting it across the organization?”. The main advantage of SAP Activate is that it is not just a methodology, but a comprehensive approach for teams deploying SAP solutions. SAP Activate brings not only the implementation guidance in the methodology, but also enables project teams to apply ready-to-run processes and deployment tools for rapid implementation. It is also true that SAP Activate has been built as project level methodology that can be relatively easily integrated into the program & portfolio framework in use by the customer. Regardless of which program & portfolio framework customers uses, SAP Activate can be used with all of them. It doesn’t matter if you  are following Managing Successful Programmes®(MSP®), Standard for Program Management and Standard for Portfolio Management from Project Management Institute®or SAFe®for Lean Enterprises from Scaled Agile, Inc. In this post I will focus on scaled agile framework from Scaled Agile, Inc.

Image above: SAP Activate Methodology Flow

Scaled Agile Framework® in its latest version 4.6 is shown in several configurations that are designed to support adoption scaled to the specific need of the organization. In this blog I will refer to the full version of SAFe®, though most of the alignment points will be on the Large Solution, Program and Team levels of the framework. The image of the full framework is shown below, and you can always browse fully interactive version of the framework on Scaled Agile website.

Before we get into the alignment points and mechanics, let me say few words about the agile framework used in SAP Activate. Many of you know that SAP Activate relies on the SCRUM agile framework for execution of the agile activities, from backlog management, sprint cadence, team structure and ceremonies during the course of the project. While the SCRUM framework caters well to teams following agile processes and small to mid-size projects, it has limits in providing guidance for large programs and organizations. That’s where SAFe® and other agile scaling frameworks can help providing the necessary structure, governance and transparency.

Now let’s talk about common principles that are critical to understand:

  1. Deliver Value Incrementally– this is at the core of agile thinking – building the minimal viable product and delivering value incrementally throughout the program. While SAFe® talks about program increments and solution train, SAP Activate uses terms of releases that represent the incremental deliveries to production. In both cases the goal is to shorten time to value and deliver value incrementally.
  2. Time Boxing and Focusing Team in each iteration– in SAFe® the project team plans each increment by selecting capabilities and enablers from appropriate backlog and then the team works throughout the program increment timeline in iterations to deliver the selected backlog items. Similarly, SAP Activate uses the fit-to-standard workshops to create initial backlog for the scope of the release and then iterates in time boxed sprints on selected backlog items that are completed.
  3. Close involvement of business usersSAP Activate emphasizes the close involvement of business users throughout the project by bringing the users into fit-to-standard workshops and then again in each sprint for playbacks and acceptance of completion of backlog items. SAFe® uses the PDCA (Plan – Do – Check – Adjust) cycle common to agile projects and the team plays back the results of the iteration in the Iteration Review event.
  4. Use of common language– in both SAFe® and SAP Activate you will encounter terms like backlog, sprint/iteration, continuous delivery, built-in quality, product owner, scrum master, team, product owner, business owners and many others. Whether these are roles, deliverables or artifact produced during the program the vocabulary used in both is to large degree consistent.

Now let’s take a look at how you can best utilize SAP Activate in organization using Scaled Agile Framework®. I’ll briefly discuss the relevant levels of the Scaled Agile Framework® that in this case is the leading entity as its coverage is broader including the Lean Portfolio Management which is not in scope of SAP Activate.

Image above: FULL Scaled Agile Framework®, for more details refer to https://www.scaledagileframework.com

Team Level

On the team level, you will find the most commonality in the deliverables, procedures, processes and artifacts. The team structure in both SAP Activate and SAFe®includes SCRUM Master, Product Owner and Team Members. SAP Activate nicely extends the guidance for how to structure the project team with the relevant experts for SAP solutions, like architects, application consultants, data migration specialists, etc. The second point of alignment is the actual execution of the sprints/iterations – in both we have planning activities, execution activities, inspection activities with sprint review, and adjust activities with retrospective. Both SAP Activate and SAFe®use backlog for management of the scope of work that gets selected for each iteration or release (or program increment). There are other commonalities in both approaches as they both build on common agile practices of working as a cross functional team to deliver value.

Program Level

The notion of continuous delivery via the release train from SAFe® is represented in SAP Activate with the ability to split larger project into multiple incremental releases. While this concept is embedded in the methodology, many implementations, especially on-premise projects, fail to take advantage of it. This is either due to missing this concept entirely or due to the complex integration challenges where it is not easy to carve-out the MVP and deliver incrementally. We see incremental delivery approach used more often with cloud solutions where capabilities like content lifecycle management, regression testing capabilities and pre-delivered test scripts built into SAP S/4HANA Cloud help realize this easier. Second key element that ties to the continuous delivery is the execution of the program in increments – SAP Activate refers to them as releases while SAFe® uses term of Program Increment. Conceptually these are very similar concepts as both aim to delivery working, tested software that is ready to deploy.

So, how does one use the SAP Activate approach in SAFe® framework on program level. In a nutshell, the program will be executing the fit-to-standard workshops for the scope of the program increment in the beginning of the program increment (during planning and early stages of the increment) and then deliver on the backlog items that have been identified, whether they are configuration, data migration, extensibility or integration requirements. The backlog is living repository and some backlog items that are identified in the program increment workshops may flow into the next program increment – for example complex development work.

Large Solution Level

SAP Activate workstreams of Solution Adoption, that includes the value management framework, change management activities and project team on-boarding as well as business users training will fit to this level. As the value management framework provides “Economic Framework” (SAFe® term) for the program to deliver value. Additionally, the topics of the overall program scope, standards, policies and governance will be largely represented on this level. The overall program management, including the key milestones, high level schedule, overall objectives of the program from PM worksteam of SAP Activate will find their place on this level. Overall solution architecture work represented in SAP Activate in the Technical Solution Management workstream will also be in this space.

The goal of this post was to outline the key alignment points that you can use to bring SAP Activate into organizations deploying SAP software while using Scaled Agile Framework®. The text is providing high level overview of the alignment points and is meant to start a conversation with teams that are using SAP Activate in conjunction with Scaled Agile Framework® to deliver SAP solutions in agile way. I’m looking forward to your feedback. Feel free to post directly here or on the SAP Activate JAM space (join here).

 

References

Trademarks and Terms used in the article

  • Scaled Agile Framework® and SAFe® are registered trademarks of Scaled Agile, Inc.
  • Manage Successful Programmmes (MSP®) is a (registered) Trade Mark of AXELOS Limited. All rights reserved.
  • Project Management Institute (PMI) is the world’s leading association relating to project management and owner of the Standards for Portfolio, Program and Project Management.
  • SCRUM – Scrum is a framework for developing and sustaining complex products. More details available in the Scrum Guide.
5 Comments
You must be Logged on to comment or reply to a post.
  • Very nicely positioned! Yes that makes sense.

     

    What I am only afraid is that organizations always tend to put more bureaucracy and also micromanage the projects so with such a beast like SAFe they could have a good ways to spoil the projects, but if we take and keep a hold of this way of symbiosis it may work!

     

    Regards, Waldemar

  • I think that some people might be not really familiar with the agile methodology and those people check this article to learn some more about agile and some other major methodologies that are used in software development now.

  • Thank you Jan.

    Can you elaborate on the challenge of finding the MVP, and perhaps on how to address the challenge?

    SAP is by nature an integrated platform, so it’s not easy find stand-alone capabilities that don’t break external dependencies on other modules.

    The challenge of decomposing a complex problem into smaller pieces in SAP is often the roadblock on the way of adopting an incremental approach – which leads to sticking to waterfall projects.

    Does Activate provide any guidance to identify the MVP, i.e. are there any projects or business areas where Activate is more, or less, adequate?

  • Francesco Tiberi thank you for your comment. Let me offer few points that can help you in identification of the scope for the MVP (or you can also think of it as a first release in multi-release program). I’ll use example of customer that is moving to SAP software from current environment of 5 different ERP systems that are either home grown or from other vendors. The way this customer structured their release plan is to:

    1. Harmonize the data for all the impacted units and make the SAP ERP the single source of truth for all businesses (Release 1)
    2. Move first 2 businesses into SAP for scope of Finance, Logistics and Sales & Distribution – this reduces the legacy systems from 5 to 3. (Release 2)
    3. Next release will remove another 2 legacy ERPs
    4. Last release will ensure that all units are on the same solution

    This is one of the possible scenarios. I have also seen customers that planned deployment of their solution in stages of increasing the functional footprint. Something like this:

    1. Release 1 for Finance and Asset Management
    2. Release 2 add Sales
    3. Release 3 add Logistics
    4. Release 4 add Manufacturing

    This strategy of course leads to additional effort of integration building for legacy systems.

    The above two definitions of MVP are only few possible examples, other view could be geographical approach where you define which parts of the organization will be brought into the new solution and define a roadmap for global rollout. Many projects need to make multi-dimensional considerations about scope and geographical footprint.

    The definition of MVP should always be value driven – does it make business sense for the company to go live with smaller solution footprint sooner or have broader functional footprint at the price of extending the project duration. Generally scope and implementation duration are closely correlated.

    Hope this helps at least directionally.