I think it’s safe to guess if you’ve been asked about going Agile on your next SAP project, your response was along the lines of: “What are you talking about? Agile SAP? Now that is an oxymoron if I’ve heard one. It doesn’t work that way.” I know that because I’ve had a lot of recent conversations with customers and partners who are being asked about Agile by their management, and the need to go for Agile or DevOps with SAP, and their response frequently is, “We don’t really know how you can do that. What are your thoughts on that?”
Well, that’s a very common point, and in my experience with SAP projects, it was frequently the case where we thought that Agile wasn’t really possible. The reality is that it can be done, but not in the same sense that it is done in a custom development environment. SAP is different. Enterprise apps are different.
SAP itself is adopting Agile as the approach to building its own products. We’ll look at how that is affecting not just SAP’s products, but also how it affects SAP’s methodology and the architecture of Solution Manager 7.2. Another point of reality is that Agile is coming and so we have to get ready for it. Not adopting Agile has a cost. And that cost can be that you may not be able to move as quickly in adopting SAP technologies and changes to the technologies as rapidly as they’re coming out.
In the blog “Why DevOps Doesn’t Work for Enterprise Applications,” Worksoft CTO Shoeb Javed boils down the difference in doing DevOps for Custom Apps vs. Enterprise Apps like SAP to four key factors – size, operational focus, multiple stakeholders, and risks. If you were to make an analogy, it would be similar to saying you want to make a change to a house (Custom App) versus a change to an entire city (Enterprise App). One is very focused and limited, the other has a much greater scale of impact, and much more that has to be taken into consideration. You may be able to build or update your own house, but no one can build or change a city on their own! With this in mind, we need to take the inherent differences in size, scope, scale, impact, and risk into account as we embark on the journey to Agile for SAP.
So How Do We Do Agile for SAP?
When we talk about “doing Agile for SAP,” I think it helps to group the considerations into two buckets – technical and nontechnical considerations.
Technical considerations focus around the fact that the Software Development Lifecycle (SDLC) is dramatically different for a packaged application like SAP versus a custom application you build yourself. In the custom world, there is no delivered functioning application; you have to build a functioning application yourself. In the SAP world, a functioning application has been delivered to us by SAP. What we’re doing is we’re taking that functioning application, understanding the requirements, and then doing a fit/gap analysis. Then we’re taking that and going into the next set of exercises around process design, configuration, and master data definition. Even though SAP delivers the application, it has to be configured to meet the requirements of your business.
There will be some coding; you’re always going to have RICEF objects that you create, ABAP coding that has to be done. But the core build activities really consist of building business process that cross business units and span functional areas. Then there’s the testing, which is a really significant part of the total project. A lot of organizations I talk to say that 60 percent of their project is testing. In the end, there’s a significant foundation that has to be laid to deliver the minimal unit of functionality needed to provide business value. Trying to package this up into a “story” for one person to complete in two weeks is just not going to happen!
This brings us to the reason why many believe Agile won’t work for SAP. I fully agree that Agile executed using the scrum methodology designed for custom apps is not going to work. There are several key reasons why:
- SAP stories and functions are massive and cross functional and technical teams
- Complete business functionality has to be delivered
- Two four-week sprints to production are not possible
This is where the Scaled Agile Framework (SAFe) comes into play. SAFe 4.0 is an industry framework that extends the Scrum Agile concept for large complex organizations. SAFe adopts principles from lean and Scrum Agile and expands on them to better meet the needs of complex organizations. It uses a tiered approach based on a release train, and within that release train you do have the releases that are built on top of those iterations, sprints and waves. But the key difference from Scrum is that the sprint isn’t artificially forced into production. In the custom dev world, the perks of a sprint are to get that functionality into production. SAFe recognizes that this is not necessarily viable in the enterprise application world, and so instead, functionality is bundled into units. SAP has adopted many of the concepts from SAFe, and you’ll see those showing up in Solution Manager 7.2. One key point of Agile that SAP has adopted is that of the business getting hands-on with the application earlier in the process.
When people say, “Well, you can’t do Agile with SAP,” we want to make sure that we’re making a distinction between what are some of those technical constraints of doing Agile versus what are some of the nontechnical constraints. These non-technical constraints include such things as:
- Coordination with Change Control Board (CCB)
- Coordination with organizational change management (OCM)
- Fiscal calendar “freeze” periods
- Regulatory/compliance policies
- Availability of infrastructure and SAP instances
In any SAP project, you always have to contend with the CCB and its schedule. There’s a lot of rigor that’s placed around moving changes in an SAP environment, so that you don’t disrupt the business. Many times the CCB uses a set schedule for approving changes, so if we miss a meeting, we have to wait until the next one. Same thing with organizational change. To implement Agile, organizations have to be able to adapt and really be able to integrate changes across the business. One example of the organization adapting to Agile would be to get the CCB to meet as the waves are released, instead of the waves having to meet the CCB schedule.
In conclusion, when looking at Agile for SAP projects, organizations need to recognize that Agile, as it applies to SAP, is different from Agile for custom development. Understanding the differences is critical for setting and managing expectations, as well as for a successful project. SAFe 4 provides a starting framework for adopting Agile. In my next blog, I’ll talk more about best practices for implementing Agile for SAP. Or you can view the webcast I recently recorded: “Agile Change Management for SAP.”
Wherever you are on your Agile journey for SAP, I’m interested in hearing about the conversations you’ve had and what you’ve experienced.