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?
No comments:
Post a Comment