Don't save your PI. Smash silos, strengthen teams, and increase velocity - while delivering on your PI commitments.

Disruptions and constraints are common in project management, especially at the enterprise level. It is common for us to look for solutions to "save our PI", but what if we could do more than just save our PI?

Why settle for saving your Program Increment (PI) Predictability results, when you can also smash silos, improve adherence to Agile principles, and increase your Velocity? In this two-part series, we will discuss how to smash silos while increasing PI Predictability. First, let’s start with the basics – baseline details.

ART Baseline Details:

The Agile Release Train:

• 1 - Product Manager
• 1 - Solution Architect
• 1 - Release Train Engineer
• 5 – Product Owners
• 10 – Scrum Masters
• 10 – Solution Leads
• 10 – Senior Business Analysts
• 10 – Senior Software Development Engineers
• 20 – Quality Assurance Testers/Analysts
• 30 – Software Development Engineers

Your ART contains ten cars with each car having:

• 1 – Product Owner (Shared across two cars)
• 1 – Scrum Master
• 1 – Senior Business Analyst
• 1 – Solution Lead
• 1 – Senior Software Development Engineer
• 2 – Quality Assurance Testers/Analysts
• 3 – Software Development Engineers

Due to run-work and other planned constraints; such as discovery-work, your average PI capacity is 1000 story points. Your ART is using the ‘SAFe off-the-shelf’ model of two-week iterations, except on difference. Due to your enterprise’s focus on innovation, you only have three production iterations per PI and a four-week Innovation iteration.

The challenge scenario

The challenge is familiar: the capacity of a key team changes after PI planning as critical team members suddenly become time-constrained.

The team in question is committed to 200 points of stories/tasks this PI. PI Iteration1 had planned resource constraints which left a maximum capacity of 35 points. Net result, the team is left with two iterations to cover the remaining 165 points needed to deliver on their commitments for the PI.

You crunch the numbers; the results are still daunting. Even if this team targets to complete the bare minimum PI Predictability goal of 80% (160-points), the team still needs an average of 62.5 points during each of the upcoming iterations. To further compound your challenges, the team’s best velocity during the previous PI’s was 50 points per iteration. The team is resource constrained, and substantially over-committed.

This situation itself is challenging enough, but what happens when key resources have recent developments limiting their availability during the next one and a half iterations? What if those same resources existed in silos, and you are left with multiple ‘single points of failure’?

How do you solve for these challenges, deliver on your commitments to your customers, and save your PI? Time to start having some uncomfortable discussion with stakeholders. Or is it?

There are a couple of approaches which might save this PI for you and the team. You could use the entire ART’s resources to swarm to finish, but this readily becomes an anti-pattern. Moreover, doing so becomes highly disruptive – especially given the frequency at which such instances occur. So, the solution to this situation should come from within the team itself.

One approach seems obvious:

Swarm to Finish

Handoff work to those now limited-key resources, let them get through what they can – then swarm to finish. The challenge here becomes WIP, as the rest of the team will need to drop their WIP to finish the work started by your limited-key resources. 

This is an Agile antipattern, and with good reason, as it places several other pieces of work at risk due to the bottlenecks created by too much WIP. Best case scenario, everything gets done – likely at the last possible moment. Most probable scenario, the highest priority stories get delivered – leaving the others to be rushed and at-risk of being pushed with less than adequate testing (and all that implies).

Result? Still cannot assure the ability to deliver on enough commitments or salvage the PI.

The second approach:

Plan to Swarm (AKA: The Silo-Smashing Solution)

Like “Swarm to Finish”, the team focuses on specific stories, practicing “focus to finish” for those stories. However, “Plan to Swarm” differs as it proactively mitigates risks associated with the delivery of the most valuable products but utilizing the entire team to deliver those products first – and fast. Plan to Swarm begins with you and the Product Owner identifying the top two most important objectives for the upcoming iteration. 

Iteration Planning

The team identifies the tasks required to complete the objectives based on the high-level design and Acceptance Criteria. Then, with the support of the objective’s SME’s, the team identifies resources to take on each task/subtask. Upon completion, the tasks should be equally divided and assigned to all team members - except the story’s identified SME’s. Once the tasks/subtasks are assigned, the executing resources point the story based on their relative level of complexity.

Iteration Execution

During the iteration, the team members begin executing the tasks assigned to them. The executing team members are supported by the SME’s with the SME’s providing technical and process guidance. This process continues across all the top iteration objectives until they are completed. Once the identified objectives are completed, the team resumes working their remaining backlog as usual.

With Plan to Swarm delivering the team’s top objectives, the team delivers on 52 story points (at 13 points per story). Combined with the team’s previous iteration’s 50 story points, the team delivers top PI objectives and 102 completed story points (51% of your total PI points). More impressive, the team delivered these within the first three days of each iteration – leaving seven days per iteration for remaining work.

While work remains to secure delivery on your entire PI, Plan to Swarm provides the following benefits to help deliver the remaining PI objectives:

• Increased sense of team ownership of the Team Backlog,
• A heightened sense of accountability to one another,
• Increased transparency,
• Improved collaboration,
• Bolstered cross-functionality,
• Increased readiness to embrace additional swarming opportunities,
• Velocity gains, 
• The ability to deliver on committed objectives when resource constraints arise.

Next installment: Using Iteration Budgeting to Overcome Objections to ‘Plan to Swarm’ and Increase Velocity