My agile methodology and SAP system are fighting: Next Friday, Sept 25th, we’ll be hosting our DevOps roundtable with a focus on methodology. One topic that is sure to come up is the waterfall vs. agile debate. Sometimes described as methodologies and sometimes described as … ahem … mindsets, they are competing approaches to managing projects and portfolios. In many ways the approaches are incompatible. However, the fact that the problem repeatedly crops up may speak to a fundamental incompatibility between prevalent management practices and the agile ethos. In order to bridge this incompatibility, many approaches have popped up. They include the Scaled Agile Framework (SAFe) approach that we have have worked with at several of our larger customers.
While named methodologies can be very helpful in solving this conundrum, there is another incompatibility that we see a lot in our work: SAP vs. Agile. It isn’t so much that SAP system is architected in a way that is opposed to Agile. Rather, the tools and methods the software industry has developed to execute and manage agile projects are often at odds with the way that SAP system implementations have traditionally been structured. At Mindset, we use personas and story-telling concepts in our design thinking. While I’m still a novice at design thinking, I find that these kinds of stories help me think through how things could be different. Let’s do one such activity here, based on a developer persona.
Imagine
Let’s say I’m Olivia, a software developer who works on an agile SAP project. I work a 9 to 5, or maybe more like an 8 to 5 (ok, 8 to 5:30). I take some real pride in my code and doing things properly.
We start a 2 week sprint on Monday and I take up a user story after our sprint planning kickoff in the morning. The story is a small one – maybe 1 or 2 points, and I can probably knock out the development work on a Fiori app in a half-day or so. I happily sketch up a technical approach and get down to work making a smaller change to a UI5 application and backend OData service written in ABAP.
I work in a forward-thinking company, so a change request (maybe a ChaRM) and transport has already been created for the sprint with a task for me. My development work is complete mid-afternoon. I run my unit tests one last time, commit and push my UI5 changes, deploy the UI5 application one last time. We use ABAPGit for our ABAP version control, so I also commit and push the change there. Now the real fun begins.
My organization requires comprehensive documentation of development changes. Therefore, I need to attach a couple of documents to the change request. The documents need to indicate what I changed (never mind that my commit messages automatically link to the user story and task I worked on in Jira) and I need to update the technical design document to document the new behavior of the service and application. This is discouraging but I’m a professional and I slog through it. I finish it up first thing Tuesday morning. Now time to move the development to our QA system and test it out!
Release my transport task, and move the change request to testing status. Whoops, an ABAP Test Cockpit (ATC) failure. It’s complaining that I’m using a literal in my code rather than a constant. My team is moving to a Clean Code approach for ABAP, but the rest of the organization won’t let us turn off these ATC checks. That’s alright, I just request an exception and move on to another task while I wait for approval.
Our approvers are pretty quick. A few hours later, the work has been moved to our QA system and I can test there. Unfortunately when I log in with our test user to check in QA, I find a lock on the user. I don’t have access to unlock the user. I open a ticket with our security team to unlock the user. This takes a few hours. By the time I’m notified of completion, it’s the end of the day.
And so-on and so-forth. You get the idea. If our definition of done on our agile project is that code is ready to deploy to production, there’s a lot of stuff that gets in the way on SAP system projects. How could this be different and still satisfy the need to be able to manage our SAP system? Let’s imagine, starting where the real fun began…
Because my organization requires comprehensive documentation of development changes, I check that the Jira task is properly linked to the commits and that the commit messages I created describe the change. We need comprehensive documentation, so I check that our CI/CD process has updated the Swagger documentation of the OData service and the JSDoc documentation of the UI5 application properly.
Satisfied that documentation is in order, I take another moment to re-test the application in dev. Then I release my transport task, and move the change request to testing status. I notice an ABAP Test Cockpit (ATC) information message. It’s telling me that I’m using a literal in my code rather than a constant. My team is moving to a Clean Code approach for ABAP, so we use an ABAPLint configuration for checks and I can safely ignore the ATC check. Sure glad that my company doesn’t have that check set as a hard error like a lot of companies.
It’s almost the end of my Monday. However, I have just enough time to test the application in QA. The test user was locked, but I have access in this QA system to unlock users. I have enough time to set the story to ready-for-testing status. This way, our product owner is able to get in and verify that the user story meets the acceptance criteria.
Resolutions
These stories point out a few pain-points and possible resolutions. Each of us can think about what we can do to make life a little easier for developers like Olivia without compromising on our ability to manage SAP landscapes. And the best part about all of this is that it pays off. In this simple story, Olivia can move that user story to done a day earlier. She can stay more focused and efficient with fewer interruptions and interventions, and feel less frustration in her job. Meanwhile, development managers can focus on more important exceptions, and documentation is always up to date. The security team can focus on security instead of managing escalated minutiae. That’s the power agile, the DevOps mindset of empowering developers, and a little imagination.
Next Steps
If you have thoughts on these sorts of topics, stories, or ideas we’d love to hear from you. If you can make it to our DevOps Roundtable on Sept 25th, please register and come listen and share. The format will be almost entirely discussion between fellow practitioners so it’s the perfect forum for sharing and learning. If you have immediate thoughts or what to know what we think of a conundrum, use the hashtag #askmindset on Twitter or LinkedIn, or get in touch directly.
See the complete agenda and Register Free For DevOps Roundtable HERE.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
