- SAP Managed Tags:
For any company with a live SAP system, delivering new capabilities without risking the smooth execution of existing business process is a top priority. The conventional wisdom says that the best way to manage risk and keep things under control is to follow a Release Management process. This means delivering groups of changes at defined intervals, to allow for more integration and regression testing. At the same time, a common recommendation is to include an Agile philosophy in the approach to delivering new functionality. So how do these two things fit together? To get some answers to this and other questions, I recently had a discussion with Scott Barber of GP Strategies. An Agile Expert and Certified Scrum Master, he has developed and delivered training courses on the Agile framework.
---------------------
Marcel van den Top: Let's start by getting everyone on the same page about Agile. How would you define Agile? Is it a methodology, or a framework? How does SCRUM fit in?
Scott Barber: Agile, from a Software Development perspective, is a philosophy. It grew out of an effort to change the culture around software development from command and control, with formal organization structures and"Dilbert-esque" processes. Software development is so complex that this doesn't work well. The Agile philosophy is based on empiricism, and has three components: transparency, inspection, and adaptation.
Scrum, on the other hand, is a way to become more Agile, as a lightweight project management framework, with shared responsibility and leadership. Each team is made up of the following members:
Marcel van den Top: I think I have a basic understanding of how Agile projects are supposed to work vs. waterfall / traditional projects. The main thing is to define smaller sprints, and deliver smaller increments of functionality more frequently, allowing you to adapt to changing business needs and correct your approach. Big Bang Greenfield SAP implementation projects haven't usually followed an Agile approach because you can't go live in increments with fully integrated business processes. But let's first look at an example of an organization that has been running SAP solutions for some time, and is continuing to deliver enhancements and support fixes and updates. Splitting the change requests and new functionality into sprints does makes sense to me here, with each Sprint being a new Release. Would this be a way to apply Agile principles into an SAP support environment?
Scott Barber: Yes, that is one way. In Scrum what you do is timebox in sprints, and there are always the same activities done in each sprint. Sprint planning meetings at the beginning, Daily Scrum Meetings, and at the end you do a demonstration of the deliverables built during the Sprint, and then a Sprint retrospective. The team discusses the things they should stop doing because they are not working, what are the new ideas to start doing, and what you should continue. This drives the approach for the next sprint to become more efficient.
More broadly speaking, though, whether it makes sense to adopt an Agile approach depends on the complexity of the effort. The question to ask is, Do I know what we are doing and how we are going to do it? The more you can answer yes, the less Agile you need to be. If you have done it many times, and know how to plan for it, then you may not need to take an Agile approach. Agile has a much bigger benefit when the path is less clear, things are changing and there are many unknowns.
A good example that you can look at is Spotify. There is a case study called “The Spotify Engineering Culture” available on YouTube where you can see how it's working for them when developing new features for the Spotify product.
Marcel van den Top: So what about larger implementation projects? Usually these involve a lot of interrelated components that you cannot deliver in smaller pieces. How does Agile and Scrum work here? How do you define "sprints" in this context?
Scott Barber: The different components that make up the whole can be developed and delivered in sprints. The work that you are doing doesn't matter so much, it's the way you are working and the way the team is working together is what is important. Agile and Scrum aim to make the team work together more efficiently and deliver more relevant outcomes for whatever goals you have.
Marcel van den Top: Thinking now about my current client, they deliver break/fix transports on a weekly basis. Every transport is managed independently. Not a lot is done in terms of true Release Management. They do deliver a lot of enhancements as well, but only a few of them are grouped together into semi-annual releases. Where would you recommend to start making improvements? What Agile concepts can help here?
Scott Barber: A weekly schedule is faster than the typical sprints. In Scrum, you generally do 2 to 4 week sprints. Moving from weekly to monthly releases would allow you to follow a typical pattern. But you can incorporate the Scrum methodology regardless of how big or frequent each release is. A sprint does not have to deliver a complete operating function from design to deployment within one sprint. You can also break down the different phases of work in a release into smaller packages as the Sprint Product Backlog. For example, the initial design is the goal for one sprint, different parts of a prototype for the next, detailed design and development of components follow from there, etc. Sprints can contain whatever you want to define. So regardless of whether you are working on monthly, minor releases, or less frequent major releases, you can define separate work products within each phase of a release.
-----------------------------
Conclusion: We can use an Agile approach in many types of projects, beyond custom software development. The key is to organize the work into individual work products that you can define and complete within ~4 week sprints. But Agile isn't always the way to go. If we already have a tried and true project plan to deliver a clearly defined set of services to our clients, then it probably makes sense to continue with that. If we are facing a more complicated situation, where the path is more ambiguous, then Agile will help us be more efficient in delivering the most useful and relevant outcomes for our clients.
You can read more about Agile from Scott Barber by accessing his White Paper on the topic here: Using an Agile Project Charter to Guide Your Most Complex Projects
---------------------
Marcel van den Top: Let's start by getting everyone on the same page about Agile. How would you define Agile? Is it a methodology, or a framework? How does SCRUM fit in?
Scott Barber: Agile, from a Software Development perspective, is a philosophy. It grew out of an effort to change the culture around software development from command and control, with formal organization structures and"Dilbert-esque" processes. Software development is so complex that this doesn't work well. The Agile philosophy is based on empiricism, and has three components: transparency, inspection, and adaptation.
Scrum, on the other hand, is a way to become more Agile, as a lightweight project management framework, with shared responsibility and leadership. Each team is made up of the following members:
- The Product Owner, who decides what the team is trying to achieve (product backlog)
- The Development (Scrum) Team, which is self-organized and self-managed, and does the work
- The Scrum Master, who is a coach to all the members of the team.
Marcel van den Top: I think I have a basic understanding of how Agile projects are supposed to work vs. waterfall / traditional projects. The main thing is to define smaller sprints, and deliver smaller increments of functionality more frequently, allowing you to adapt to changing business needs and correct your approach. Big Bang Greenfield SAP implementation projects haven't usually followed an Agile approach because you can't go live in increments with fully integrated business processes. But let's first look at an example of an organization that has been running SAP solutions for some time, and is continuing to deliver enhancements and support fixes and updates. Splitting the change requests and new functionality into sprints does makes sense to me here, with each Sprint being a new Release. Would this be a way to apply Agile principles into an SAP support environment?
Scott Barber: Yes, that is one way. In Scrum what you do is timebox in sprints, and there are always the same activities done in each sprint. Sprint planning meetings at the beginning, Daily Scrum Meetings, and at the end you do a demonstration of the deliverables built during the Sprint, and then a Sprint retrospective. The team discusses the things they should stop doing because they are not working, what are the new ideas to start doing, and what you should continue. This drives the approach for the next sprint to become more efficient.
More broadly speaking, though, whether it makes sense to adopt an Agile approach depends on the complexity of the effort. The question to ask is, Do I know what we are doing and how we are going to do it? The more you can answer yes, the less Agile you need to be. If you have done it many times, and know how to plan for it, then you may not need to take an Agile approach. Agile has a much bigger benefit when the path is less clear, things are changing and there are many unknowns.
A good example that you can look at is Spotify. There is a case study called “The Spotify Engineering Culture” available on YouTube where you can see how it's working for them when developing new features for the Spotify product.
Marcel van den Top: So what about larger implementation projects? Usually these involve a lot of interrelated components that you cannot deliver in smaller pieces. How does Agile and Scrum work here? How do you define "sprints" in this context?
Scott Barber: The different components that make up the whole can be developed and delivered in sprints. The work that you are doing doesn't matter so much, it's the way you are working and the way the team is working together is what is important. Agile and Scrum aim to make the team work together more efficiently and deliver more relevant outcomes for whatever goals you have.
Marcel van den Top: Thinking now about my current client, they deliver break/fix transports on a weekly basis. Every transport is managed independently. Not a lot is done in terms of true Release Management. They do deliver a lot of enhancements as well, but only a few of them are grouped together into semi-annual releases. Where would you recommend to start making improvements? What Agile concepts can help here?
Scott Barber: A weekly schedule is faster than the typical sprints. In Scrum, you generally do 2 to 4 week sprints. Moving from weekly to monthly releases would allow you to follow a typical pattern. But you can incorporate the Scrum methodology regardless of how big or frequent each release is. A sprint does not have to deliver a complete operating function from design to deployment within one sprint. You can also break down the different phases of work in a release into smaller packages as the Sprint Product Backlog. For example, the initial design is the goal for one sprint, different parts of a prototype for the next, detailed design and development of components follow from there, etc. Sprints can contain whatever you want to define. So regardless of whether you are working on monthly, minor releases, or less frequent major releases, you can define separate work products within each phase of a release.
-----------------------------
Conclusion: We can use an Agile approach in many types of projects, beyond custom software development. The key is to organize the work into individual work products that you can define and complete within ~4 week sprints. But Agile isn't always the way to go. If we already have a tried and true project plan to deliver a clearly defined set of services to our clients, then it probably makes sense to continue with that. If we are facing a more complicated situation, where the path is more ambiguous, then Agile will help us be more efficient in delivering the most useful and relevant outcomes for our clients.
You can read more about Agile from Scott Barber by accessing his White Paper on the topic here: Using an Agile Project Charter to Guide Your Most Complex Projects
5 Comments
