Agile Pipeline – How to scale agile delivery

There are many types of Scaling agile frameworks and organizations that started scaling early on have their own custom scaled frameworks.

The smallest unit of the developed software is delivered by the team. At this level the scrum or basic agile works beautifully as found by many successful projects. At a team level, the variability, complexity as well as team dynamics is limited to only that team. Its a misconstrued notion that successful Agile delivery is more suited to smaller projects. Its important to pick the right delivery structure for scaling agile practices.

While scaling agile, there are multiple models that are widely spoken about such as LeSS, SAFe, DAD and variations of the same.  What is the right framework? Or is there anything like a right framework at all. That’s the question I am trying to answer.

Structure follows Strategy is the prime management theory which talks about how you structure your team would be based on the strategic goal that the organization is moving towards. In the same lines, Conway’s law states

Organizations which design systems … are constrained to produce designs which are copies of the communication patterns of these organizations

— M. Conway

The answer to scaling agile would totally depend on the organization design and structures in place. Here are some of the well-known organization design patterns and the relevant scaling model that has worked.

Scaling a program

The program (by definition) is having multiple teams moving towards the same goals and has typically constraints around time, scope, market & regulatory conditions. In these cases, high level of cohesion and communication is mandatory.

In such scenarios, I have observed using SAFe® like model followed is successful.

Key aspects while implementing for SAFe ® release train are

• Every scrum team has specific objective with self-organized developers, product owner and scrum master
• Program Increment planning done regularly
• Scope is defined every 8-12 weeks with Innovation & Adaptation sessions
• Common tool such as JIRA/VersionOne used to capture progress
• Steering Committee is setup to take program decisions meeting every week at least
• Strong Program manager as an Release Train Engineer (RTE) who acts as a common conduit across teams

Best Practices that I have seen which works towards success are:

• Product Owners with every team and Analyst in case of PO is not available locally,
• Scrum of scrum meetings discuss environment, inter-team dependencies and ,
• Joint showcases and business stakeholders attending such demos so that its easier to see the canvas getting built out.

Scaling a product:

While scaling a product and program have similarities, their differences are the level of communication required once the modules are defined to a certain degree. Each product line while in inception phase, would work as a program for agile to be successful. Once a cadence is setup, scaling the product would require different types of principles

Some of the key aspects that are required are

• Having a strong engineering practice; It’s critical to have the same principles and proper dependency injections
• Having a common and current roadmap with rolling window for features
• Strong DevOps practices to manage frequent releases
• Local Product owner for each agile team to work efficiently

Best Practices that I have seen which works towards success are:

• Product council with all the product owners to ensure that features are prioritized on a timely basis
• Engineering huddles between teams with objective of aligned architecture
• Scrum of Scrum meetings with focus on common framework elements, environments and discuss new improvements
• Similar to scaling a program having joint showcases/demo for looking at progress as well as common retrospectives would be helpful to learn from each other

Loose coupling within modules but critical to have high coupling with respect to principles, feature road-mapping and engineering practices. In case of product its

Scaling a strategic initiative:

We have seen many strategic initiatives such as automation, CI/CD setup work very well during the pilot phase. While scaling initiatives, there are no silver bullets.

Some of the examples from our experience are

• BOT(Build, Own and Transfer) Way: Creating a Center of Excellence team that forms the core group that does the initial change to happen and as and when the relevant team is ready to take ownership of the initiative, transfer the same.
• Playground Way: Common training is given for all the team members and coaching is given individually for each team to move towards the initiative. This will help ownership for the initiative rest with the teams.
• KPI Way: Adding an initiative in a senior executives’ KPI and expect that the roll down of initiative across the enterprise.

We have seen the BOT way is the easier to implement and success rate is higher. However, need to watch for handover signals well. Some drawback is that original team gets the excellence in the initiative and the team that needs to own the initiative continues to be dependent or drops it completely.

Scaling as a product line: Vertical/Horizontal integration

Large engineering enterprise as an example that depends on upstream and downstream system. This includes large and hairy problems where the agreements are setup every 8-12 weeks.

Key agreements need to be in the Tools, agile processes, engineering practices for the benefit of movement of team members and achieve scaling only.

Best Practices while scaling Agile Delivery

1. Regular Roadshows after milestones are complete
2. Innovation days where the team work only on areas that they choose
3. Inter-team collaboration by way of invitation to participate in other teams’ release planning
4. Communities of Practices setup across teams within the location
5. Leadership buy-in for providing safety net for experimentation and innovation

Each and every organization brings a set of core strengths to keep the momentum upwards and onwards. Agile delivery scaling needs to amplify those strengths and customize the communication patterns in the areas of processes, engineering and management to make the agile journey smooth and successful.