Transforming Application Development Teams to a Factory Style Agile DevOps for ERP

This will analyze how one redesigns their ERP Application Development teams into an agile factory-style DevOps team.

Let us begin by defining the factory vision statement:

Application Development Factory will deliver an industrialized way for the realization of custom development for ERP Digital Core and surrounding Ecosystems in a repeatable and cost-effective way, maintaining quality and integrability. The scope of service will include technical work in the Realization or Build phase in a System Integration and Application Development Project.

Defining the Scope

List your capabilities. Look at your historical data. Pick up multiple sample projects that are successfully delivered. Break up the project cycle into individual phases. Map people and skills that were mapped in each phase. This will identify the capabilities. Map capabilities in 2D metrics of usage adaptation and impact. All that is P1 and P2 are candidates for adaptation as Capability Towers. P1 is the priority on which the pilot phase will be executed. Capabilities P3 are sparingly used and sometimes specialized skills. They are not a good fit for being treated as an independent Capability Tower, but to be considered as Subject Matter Expert (SME) pool. Capability Tower work as a factory, equipped with multiple hands of similar skills. They will be the factory. Their deployment to Epic is decided by demand forecast. Capability Towers will carry utilization targets. Each Capability Tower will have a Capability Leader who is responsible for Capability and Capacity functions. SME’s are investments and thus preferably multi-skilled and deployed on requisition. They are special forces para dropped into a Story for specific purposes.  The delivery factory ecosystem is led by a Service Delivery Manager (SDM).

Usage↓ Impact→	HIGH	MODERATE	LOW
HIGH	P1	P2	P2
MODERATE	P2	P2	P3
LOW	P2	P3	P3

 Metrics to Prioritize Capability Tower Investments

Prioritize Capabilities

It is important to test that a factory-style model will work for your organization. We need to test it through a pilot. This needs us to prioritize one capability area to invest in. A big bang adaptation of all capabilities is generally too fast a change, which fails, as there is too much inertia to traverse. It is better to start small, bite-size, through a pilot factory adaptation. Start where you have high usage adaptation and high impact. A selection of high-impact scope is important to stress-test the tools, processes, and change management. One should thus do this pilot with P1 capabilities. It is too critical an impact to fail, and if this model is to fail, let's fail early. Once the pilot capability factory is up and running, other P2 capabilities can follow the model swiftly. For most software-related programs, code development is the capability that is most used and has the highest impact. But this is not a rule.

Process Adaptation

Let us assume the code development factory as an example to understand the process adaptation. The requirements will be for multiple programs, that will come all together or spread out over time. Each requirement is captured into Epic. The factory architects will work on defining the Features and Stories and defining the Backlog. The development team will work on the Sprint, do unit testing, and send integration tests to the Quality system. Once the System integration test is done for the configurable item, a customer demo will be done. A story will be sent to a user acceptance and planned for release or deployment. The defect management, backlog, debt, and burndown will need to be done by a tool. A developer focuses on developing the enhancements or features while the tester will do an integration test. Deployments in ERP estates are done by cutover go-lives. The project ends with a transition to support the team in operations. Knowledge management is going to be the key, where assets are harvested and estimates are improved. The below diagram pictorially represents this idea.

Agile Factory Delivery Flow

Defining the Scope

Continuing with the code development capability, we see that this capability gets engaged in various kinds of activities. Listing some of them would be as below.

• Configuration

• Documenting the solution, including business process models

• System change management and transport management

• Data loads and data migration

• Testing

• Delivery of training and enablement

• Managing the project work

• Extending the solution

• Integration

Again, going by the way to address it, we need to break each activity down to its individual artifacts.  This will help prioritize the adaptation. For a large team, this exercise will help. The priority action is the minimum the team should start with and then go to the follow-up activities. The chart below is representational of one such assessment. Every scope assessment story will be unique to its organization. 

Representation of Capability Scope Assessment

Qualification of Factory Work Package

Eventually, everything in the organization that needs to be built through the Application Development team needs to go through the factory. But till then, when we are in transition (that could take me many months to stabilize), we need to have a mechanism that stands in as a gatekeeper. This workaround is called Solution-led Due Diligence. 

Solution-led Due Diligence will determine and qualify the work package that will be delivered by the Factory-led Delivery team. A factory-assigned architect will need to be part of the diligence team. The diligence exercise will be signed off by the service delivery manager of the factory. The factory will define the input and exit criteria at every phase, adapt the factory tool chain and conduct quality gates. 

Solution-Led Diligence Approach

Deployment of Virtual Squads

Factory PMO will deploy virtual squads comprising of a manager, architect, subject expert, developer, and testers. The factory will maintain a team based on capabilities towers. Monitoring and measurement of backlog and debt will be done by the project manager assigned for the engagement. 

Demand forecasting would be done and capabilities towers will staff up for it. Resource utilization will be the key measure and job scheduling will be managed centrally. a program management office will be there to support the team in operations, monitor, measure, and manage.

Applications Development Factory Organizational Structure with Virtual SQUADS

An Agile delivery factory workflow is discussed in the blog Agile Development Factory For SAP.

Application Development Factory Roles

Find below an indicative table with various roles in the application development factory and their responsibilities.

Factory Roles and Responsibilities

Conclusion

The constituents of what make any Application Delivery team are Process, People, and Tools. Traditionally we have a project staffed up to meet the purpose and the program management office is focused on the net outcome. We overlook or do not prioritize the right kind of focus on the utilization of our investments, be it people or tools. Over time this customization becomes legacy, too complicated, and gathers lathery. To address the needs of 21st Century IT, we need an Omni Speed IT.

People bring in business knowledge, skill, and continuity to a program. No process can replace all people. While we can automate, shift left, and fail early, people are still pivotal to any execution. Talent is also a huge cost. And over time their fullest utilization can speed up value realization many times over.

Tools are the foundation of any project team. They are also easiest to manage as tools OEM keeps pace with delivery methodology. Its adaptation in the organization is about tailoring or configuring it to the delivery process. This is not a big challenge. Its adoption and successful usage determine its success. 

Process changes are the most difficult. While one can adapt to the change in the delivery unit, its adoption is not always up to our desired outcome. Thus, we will look into how we can redesign the process. Here we studied a typical agile delivery process, and how we adapt our application development teams to it at scale.

---x---