Iterative Kanban and Scrum Modes For SAP Agile Development Factory

Agile with lean delivery methodology is the most adapted delivery process in modern software deployment, including that of SAP. The two popular lean methods for SAP projects are called 'Iterative Kanban' and 'Scrum'. Both use time-bound iterative cycles which focus on early demonstration, improving the end product through continuous feedback. Such delivery gives higher business value and customer satisfaction. Business is engaged in all phases appropriately and participates throughout the lifecycle of the product. The delivery risk decreases with time, it is more predictable and stable. Let us understand the difference between the two and appreciate which type of work packages can be routed to them.  

Iterative Kanban Mode Of Delivery: This methodology, leverages Kanban to deliver the work package in waves, that consist of multiple sprint cycles that make up each wave. Each sprint is 3 to 4 weeks long and each wave could have 2 to 3 sprints making the wave 6 to 12 weeks long. After every wave, the product is demonstrated and feedback is incorporated as a retrospective for further prioritization of features in a subsequent wave. When the new requirement is prioritized, the current work-in-progress backlog is put to hold to preserve the schedule. Every wave generates a release backlog, which then is integration-tested, user-accepted, and approved for deployment as a release. This release deploys multiple story points together. 

Scrum Mode Of Delivery: This project methodology includes scrum backlog management, scrum execution, iteration, demonstration, and retrospect. Each scrum typically lasts 3 to 4 weeks. When new changes are brought in, it adjusts the scope backlog to preserve the schedule. Changes can be deployed in a quick turnaround.

Iterative Kanban Way	Scrum Way
Major Projects With Milestones       Where work is based on a major milestone generally with one big bang go-live. Examples: Greenfield Implementation, Package Upgrades, S/4 Conversions, Mergers, and Acquisitions, etc…	Urgent Changes       Ideal for delivering urgent or emergency changes that comes in from the application support organization. This is not just a temporary workaround, but getting the permanent change moved in quickly.
Periodic Maintenance Activities       Periodic maintenance of applications, Service pack upgrades, Scheduled Planned activities, etc…	Service Request       All Service Requests that are part of the run organizations, for example: Adding a new element to a Fiori app, configuring a new plant, configuring a new routing logic, etc...
Application Development       Large development work which has a linear workflow. These could be allocating support to other external projects or doing staff augmentation. Ideal for projects where we block dedicated capacity.	Agile Application Development       These work packages are generally built for early value realization in an MVP way. In this type of work, it is okay to release various features over time as soon as they are ready. The work generally is executed at a service level and not capacity.
Business Process Change       These are moderate-size projects where the customer has to adapt to a new business function or adapt changes for regulatory compliance. Generally, this type of work has a company-wide impact and must be handled with organization change management track, training, etc… Example: Adapting a new GST Add-on, Onboarding of Treasury module.	Release Window-Based Activities       Work here is built in sprints and is tested and kept ready in a release backlog. This backlog is reviewed and prioritized to be deployed in release windows. This is the most popular way to develop SAP in an Agile factory model.
Work Package Size       All sizes of work can be delivered	Work Package Size       Work order that has less than 400 hours of effort and can be deployed within 4 weeks goes to Scrum by default. All small and large work order that follows Agile Scrum is delivered through this engine.

Agile Development Factory For SAP

Here is an infographic showing the way we deliver through our Agile Development Factory. We have boxed the team roles & the workflow for which one needs to effort/demand estimate the work package. This shows the key  The Ceremonial roles are an operational necessity and are kept outside of the main box, an overhead. This model works for both Iterative Kanban and Scrum models. This also represents the team cadence model. The secret sauce is the underlying DevSecOps Toolchain and building the cross-functional capability every team member needs to have.

 

21 Excuses SAP Managers Make To Avoid The Agile Way

These are a list of reasons that have come up when we talk to managers of SAP projects that are not Agile. If your project is not yet delivered in an Agile way, what has been your excuse?

1 Business process cuts across various SAP modules and may not be fully configured in a single sprint/iteration. We cannot break all the business processes into smaller chunks. Even if done how will we know that it is on track for meeting the end-to-end process requirement?

2 Delta process cannot be demonstrated after every sprint, we can arrange the demo after several sprints.

3 SAP has interconnected processes and to have end-to-end visibility of the business processes, needs data reconciliations, thus it needs a big bang go-live

4 Customers will have an insatiable demand for change if we don’t freeze the scope upfront in blueprinting.

5 The SAP solution has been customized extensively, we need to lift and shift.

6 We don’t have documentation, nor do we have experts who know the complete working of these codes. Cannot advise you to change or drop what is already built.

7 SAP is best delivered using waterfall methodology and cannot converge with Agile.

8 We don’t get cross-functional multi-skilled team members as required in an Agile Squad.

9 Only functional consultants will interact with business process owners, and they will direct the developers and testers. The whole team doesn’t understand the process, nor do they need to know.

10 Automation is not easy; every requirement is unique.

11 We do not have enough repeatable tasks to automate.

12 We have boxed the scope in the contract. Any change is a change request.

13 It is not possible to provide a demonstration to the customer for every little feature that we add to a process. They will see it once fully configured in User Testing.

14 There is no value in doing incremental testing. We should do testing only once a process is fully configured.

15 Training the end user is not my responsibility.

16 Agile projects have too many meetings and overheads. I spend my full day in coordinating and preparing for different meetings.

17 We cannot do any further shift-left in our project

18 We cannot do releases of every feature we configure. We will bundle all the changes in one transport and move during cut-over.

19 If you introduce new changes, the schedule will be delayed.

20 This team cannot deliver in Agile

21 I don’t have that skill in my team

Do look out for this space for the rebuttal to each of the reasons stated.

Implement Tribes-Squads-Chapter Matrix Model For Your Organization

Here are the various elements of the Tribes-Squads-Chapter Matrix delivery model for Agile Delivery. This model can be adapted to most Agile models for software delivery and has been extensively used in both the lean methodologies of Scrum and Kanban. 

The Building Blocks

The Building Blocks Of Tribes-Squad-Chapter Matrix Model

Program:  A Program is a collection of Tribes / Squads organized around the same purpose. The Program enables and supports a collection of tribes in achieving their goals. 

PMO & Agile Coach: The PMO & Agile Coach team facilitates the feature planning, estimation, tracking, dependencies, risk/issues, and reporting of the delivery progress. 

Tribe: A Tribe is a collection of squads with a Tribe Leader, organized around the same business goal. They work on the product backlog.

Squad or Scrum Teams: A Squad is a high-performing delivery team consisting of a set of people who provide executive power. They work on the sprint backlog.

Chapter or Capability: A Chapter is the ‘hierarchical’ line to Squad members, in which personal development and craftsmanship are organized. They are formal “communities” of people with the same job role/expertise deciding on how things need to be done (often within a Platform), regarding their area of expertise. 

Guild or Cohort: This is an informal organization that represents a group of people that come together for a specific purpose or shared interest. They can be from different chapters, different squads, or even from different tribes. They open channels for adopting new innovations, building new capabilities, sharing knowledge, exploring tools, etc...

Shared Services: Specialists assigned from their respective areas from other parts of the business or external vendor that provides support to accelerate squads' development progress. You can read ore about it in another blog on Shared Factory Services.

DevSecOps Toolchain: This is a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a system. You can read more about it in another blog on DevOps In A 21st Century Enterprise IT Estate.

Defining Various Roles We Need In This Model

Program Management: Represents the internal voice of the customer and works with customers and Product Owners to understand and communicate their needs, define system features, and participate in validating results. They are responsible for the program backlog and overall governance. 

Solution Architect: These are typically natural leaders that have extensive technical experience across platforms, systems, and modules. And even though cross-functional sub-teams often rely on solution architects to get direction in complex integration scenarios, the teams themselves still retain the responsibility of moving all their user stories and tasks forward. 

Release Train Engineer: A servant leader and the chief Scrum Master for the train. The RTE facilitates optimizing the flow of value by ensuring the ART events and artifacts function correctly, including the Program Kanban, Inspect & Adapt (I&A) workshop, ART Sync, and PI Planning. 

Business Process Owner: A small group of stakeholders who have the business and technical responsibility for fitness for use, governance, and return on investment (ROI) for a Solution developed by an ART. They are primary stakeholders in the ART and actively participate in ART events.

Product Owners: Is content authority for the team backlog and responsible for defining stories and prioritizing the backlog. Product owners are typically key business leaders who can make critical decisions about the need and importance of features within a particular release. They also help with the prioritization of user stories.

Scrum Master: A servant leader and Agile team coach that helps the team to remove impediments, facilitates team events, and fosters an environment for high-performing teams. They ensure the use of Agile practices within teams. They are the Project Managers.

Agile or Scrum Team: They are cross-functional groups of individuals who can define, build, test, and deploy an increment of value. The same team works on requirement gathering, configuration, development, documentation, training, testing, etc.  We typically build several such cross-functional sub-teams, each focused on a small number of features. The main objective is to build teams that are as self-sufficient as possible and that rarely need to step outside of their own team to accomplish a task.

----..oo0OXO0oo..----

9 ERP Implementation Habits That IT Managers Need Change To Being Agile

Large ERP implementation comes with a high level of business integration, inherent complexity in design, huge computing needs, a growing data footprint, and a large number of dependencies with other connected systems. They look too big to be nimble-footed. To thrive in the wild, speed is of the essence and a survival skill. How to speed up this bull is the purpose of this blog.

Traditional waterfall models provide a linear but structured path to a product with good predictability of the outcome. In this, project requirements are established up front, followed by design, then implementation, verification, and maintenance. They generally have a mega event of big bang go-live or complex rollouts. The project sometimes takes years to be realized, and by the time the implementation is complete, the original business requirements have long been changed. This results in complex custom development and adds to its technical debt. The new business requirements that get added over time, increase the gaps from standard, add customization, and add layers of complexity. The core becomes an application lifecycle management nightmare. This model also generates a large volume of documentation which in turn become a huge task in itself to be maintained, and eventually, most become a burden that gets preferred to be ignored than managed. 

Let us evaluate if the right focus on a different methodology, process, and tools can bring change. In that context, let's evaluate Agile Delivery methodology along with a DevSecOps toolchain for large ERP implementations to meet the omni-speed requirements of the customer.

The Agile manifesto sets the guidance to development teams. Scrum and Kanban are two lean methodologies that we will adapt. Without going into the details of how Sprint and Kanban work (the documentation around them is available abundantly on the internet), we will go into the study of what happens when we adopt this methodology in ERP implementation.

1. Iterative Delivery approach enables prioritization, proving value quickly (weekly, or even daily), while significantly reducing project risk. As opposed to the typical many months long waterfall delivery schedule, that waits until the end for user acceptance, Agile responds to specific, evolving needs with great agility in an iterative, continuous way.

 

2. Cross-functional Individuals are desired who can define, build, test, and deploys an increment of value. The interactions of team members focus on achieving the common purpose versus working together just for compliance with processes and tools. The team itself is a self-managed flat team called squads over a traditional pyramid that works in planned silos. The traditional project manager is now a scrum master, who must radiate the spirit of a servant leader.

 

3. Delivery Squad Teams in ERP projects are cross-functional and historically referres to cross-module skills (for example SD, FI, MM, etc.). This is not true, and has been confusing. In the context of an Agile team, cross-functional refers to the various functions performed by the project team – requirement gathering, process discovery, fit-gap, configuration, development, documentation, training, etc.  We typically build several such cross-functional sub-teams, each focused on a small number of systems/modules. The main objective is to build teams that are as self-sufficient as possible and rarely needs to step outside of their own team to accomplish a task.

 

4. Building Viable Products in small iterative chunks allows early validity of the solution at hand. The team focuses on iterative demonstration, which allows early feedback on product viability and focuses on value add-ons.  Instead of always thinking about the end state, the teams should continuously ask what value they could bring to the customer. The product owner manages the product backlog and works with process owners to help prioritize features to work on.

 

5. The Statement Of Work should be written in such a way that it encourages collaboration between businesses, product owners, and scrum teams. This has to have the flexibility to accept requirement changes and allow minimum viability products that can be demonstrated to businesses early. It should help allow incremental value in iterative successions. While structured contracts are needed, contract negotiations should not be the topic of discussion in governance but value realization. 

 

6. Quality Assurance needs process documentations to be in place. When Agile focuses more on collaboration than process adherance, it may appear to ignore this critical quality aspect which is not true. The ART (Agile release train) ceremonies ensures quality control happens. Iterative development brings in the right balance of documentation, quality gates, performance metrics reviews and backlog prioritization. It is true that Agile doesn’t encourage very detailed blueprint documentations upfront, but it has defined exit criteria in DOR (Definition Of Ready) and DOD (Definition Of Done) process to account for the relevant documents needed as per software development lifecycle requirements.

 

7. ART Ceremonies of the Agile release train focuses on allowing the team to communicate and improve the product along with its development. Thus, instead of one big planning exercise at the beginning of the project, they plan for the sprint in iteration. They continuously get feedback and redo planning, invariably more than waterfall, but because they do it frequently and for short sprints, they can adapt to changes easily.

 

8. DevSecOps Toolchain makes IT more responsive to business needs by connecting cross-functional, multi-skilled teams in a collaborative ecosystem that integrates development, testing, quality, operations, security, and business stakeholders throughout the project lifecycle. This, in turn, supports continuous testing, integration, delivery reviews, and deployment of stable, high-quality software, guided by continuous feedback and automation. This supports shift-left and brings variable speed to value realization to meet various customer needs.

 

9. Delivery Organization needs to re-model into a Tribes-Squads-Chapter Matrix Model. A large amount of organization change managment is required when adapting to Agile. This adaptation itself is iterative and is necessary for an organization to go from onboarding, to doing, to becoming, and achieving the end state of being Agile. This is a cultural change.

Without DevSecOps, deploying even small changes to SAP systems can be time-consuming, often resulting in long release cycles, complex application lifecycle management, and introducing risk. Lack of proper software tooling brings inertia to the workflow and that adds a large overhead to operations, thereby creating friction, and reducing customer satisfaction. With DevSecOps, teams are connected, processes are error-free, and product backlogs are visible. 

In an ERP environment, DevSecOps built on an Agile framework enable one to fail early and respond to change quickly, delivering requirements at the speed that the business needs. Stakeholders are engaged early on and are part of the development cycle. Business process owners become part of the build process, engaging them throughout the application life cycle. It reduces the business risk that those changes bring in, by demonstrating their impact early. Splitting releases into smaller batches helps bring visibility and control to an otherwise complex change and release management process. This addresses the stress that big-bang deployments bring in. Testing is continuous and it encourages a culture of adapting to automation. With iterative sprints, repeated tasks get automated. Temporary workarounds introduced in the maintenance of applications are avoided as one can move a permanent fix early due to the lean omni-speed delivery process. 

Together, Agile and DevSecOps provide IT teams with the means to deliver change quickly, in response to customer omni-speed demands, creating sustainable 21st-century delivery teams for large ERP deployments. Are you ready to relook at how you manage your delivery today? 

Related reading materials from the author:

Implement Tribes-Squads-Chapter Matrix Model For Your Organization

DevSecOps - Embedded Security With Omni-Speed DevOps
DevOps Value Chain for SAP Estate
DevOps in a 21st Century Enterprise IT Estate