Putting a Process in Place
The first article in this series discussed some ideas for an optimized Agile Enterprise and how it may differ from an optimized Agile team. We walked through a scenario whereby the same amount of work could be completed in two fewer sprints by reallocating an Agile team that was already participating in that project. A nice result and on a clever notion. But how do we put that into practice? This article will address what needs to be included for a process to successfully adopt this strategy. There are actually two approaches that may be used – Individual Resource reallocation and Team reallocation – and we will take a look at both. (A future article will look at an implementation in action, and the tools needed to make it work.)
As a brief recap, we proposed a scenario where 4 teams would complete a feature release in 7 sprints (below), with each team solely focused on its primary area of expertise.
By creating awareness at a higher level, across teams, the project could reallocate resources to critical path tasks, resulting in the same work completed within 5 sprints (below).
In order for this approach to succeed the following are assumed:
Agile teams work solely within a program/product, and there are no issues with resource contention and no conflicting stakeholder priorities.
Skill sets and strengths of all resources/teams are known and accessible for decision making.
Cultural acceptance of team “flexibility”, allowing for temporary reorganization within a release exists and is embraced.
Agile success is already established at the team level (not just individuals who have worked in Agile environment).
Individual and Team re-allocations should always happen in full Sprint increments, no shorter than a single Sprint.
Reallocation can be planned during initial release planning or planned a sprint or 2 in advance. The just-in-time approach will benefit changing priorities and business needs throughout the release and should be evaluated regularly.
Paradigm Shift Away from Team Optimization
Before delving into this article further, it’s important to note that one of the key tenants of an Agile team is consistency and cohesion. In following an old adage, the team has advanced through Forming, Storming, and Norming, and are well on their way to Performing. And as many Agile practitioner’s come to know – it is common to see a team unify as trust is built across team members and the commitment to group success takes priority over individual gains. Moreover, the unification tends to set a platform for velocity and improved backlog management, planning and forecasting. Additionally, the establishment of a high performance team allows for advanced learning and the application of forward thinking approaches, methods, and tools, such as automation across development and operations (DevOps).
So noting all the above, and to bring the preceding notions back on point, when elevating the vantage point from the team to the enterprise level there may be cases where temporarily disrupting the consistency of the team may in fact benefit the overall program and product. Moving forward, we’ll examine a broader view of optimizing teams within the context of the entire enterprise, while balancing the impacts of team disruption vs. the benefit of enterprise gains when reallocating resources to ensure product delivery.
Optimizing the Enterprise
Optimization can take many forms depending on your organization, but it boils down to adopting a process that can effectively reallocate resources for one or more sprints, and to the development’s organization’s ability to adapt to change.
Both Individual and Team reallocation have a place in Enterprise optimization. Individual reallocation works best when there is a relatively small need for a particular skill that is needed on another team. This is frequently referred to as “Going on safari” or simply a “Safari team member”, and typically results in moderate gains in efficiency and effectiveness.
Shifting an entire Team may provide a much larger boost to the overall program, as in our original example, and the resulting potential increase in total program hours is likewise amplified. In either case, the reallocation strategy results in a higher total level of effort, but faster speed to release. It also has the benefit of trying to even out the workload across teams.
The following list contains some of the fundamental elements that should likely be in place to successfully implement an Enterprise optimization:
A common “estimation currency” (ensure 1, 5, and 13 mean roughly the same thing across all teams on the program).
Backlog items targeted into Sprints, based on each team’s velocity and areas of expertise.
A program “health” monitoring process that will use the current backlog for alerts.
A program/product or release level dashboard for easy visibility of the health/status of all teams and the overall backlog including alerts.
Ongoing communication between all Scrum Masters, including regular “scrum of scrums”, and a seasoned Release Train Engineer (RTE).
Each of these elements are equally important, and attempting to skimp or skip any will result in failure of enterprise reallocation. They apply to both Individual and Team reallocation, though some details may vary.
Establishing a Common Estimation Currency
In order to ensure all teams who are part of a program/product’s “resource pool” are speaking relatively the same in terms of level of effort, it is important that a common “currency” is established at the start of a release.
The first step is for all teams to estimate using the same unit (ie story points) and scale (i.e., Fibonacci). This may seem obvious, as most Agile teams estimate backlog items (epics, stories, etc.) in story points on a Fibonacci scale, though hours or other units may be used for various reasons. The program needs to ensure that the units and scale are documented and that all teams agree.
The second step, which is more difficult, is to ensure that 1, 5, or 13 points means relatively the same level-of-effort to all teams. To accomplish this, all known backlog items for a release should be estimated, typically by the team that is most likely to have the skills to implement it. Then, estimates are socialized between teams, and any significant surprises or glaring inconsistencies are reviewed in greater detail.
One other common technique is using a single “base story” that is estimated as an entire program, and used subsequently by each team when going through their individual estimation exercise. Each team will still most likely vary slightly, but remembering that we are discussing “relative estimates”, this should be enough to establish this common currency.
Some other techniques may include:
creating an initial definition for scale values (for instance a 20 point story is defined as taking an entire sprint to complete)
seeding team members on other teams during estimation (only the “core” team members get a vote, but allowing cross-pollination allows for better correlation)
Establishing a Program Health Monitoring System
A good Scrum Master knows the general state of the team’s “health” on a continuous basis. However, the other teams’ Scrum Masters and the RTE do not have this same visibility. We want to ensure that everyone is working for the “greater good” of the program/product and not solely focused on the individual team. A monitoring system that is transparent to the whole program can provide this view. Further, the monitoring should be based on the current-state of the program/product – the current release plan, sprint plans, and backlog.
Some scenarios that should trigger an alert:
A critical, cross-team dependency is discovered
A team identifies a skill gap or deficiency
A team is over/under performing (to Sprint Plan)
A release is at risk of delivering MVP (minimum viable product) functionality
Program level alerts are easier said than done. At its most basic, this system would simply reflect a subjective evaluation by an individual. This would be a case where someone enters an alert in manually. A more robust solution would integrate the backlog management tool, cross referenced with a team management tool which includes a skills database.
Once any alert is triggered, the dashboard should have an indicator at a minimum. Using the alert trigger to also send an email to all Scrum Masters would be even better. Either way, alerts need to be discussed on a frequent basis to ensure that they are resulting in appropriate actions.
Establishing a Program Dashboard
Scrum Masters often have a team dashboard. A dashboard for all teams across the program/product is now needed. At its most basic level, the release dashboard may simply be a consolidated view of each team dashboard, along with any alerts. A more robust solution would provide rollup/drill down, a separate dependency view, integrated sprint plans and backlogs for the release.
The dashboard should be reviewed on a regular basis (ie daily) by the RTE, all Scrum Masters, and available at any time for upper management/executives to review. It is very important that this is kept up-to-date and accurate, so that reality of the release is fully transparent to everyone.
What should we be looking for here?
Dependencies staying on track – even Agile projects can be subject to significant dependencies and resulting critical path. RTE and Scrum Masters will need to assess any risks and propose potential adjustments.
Team backlog items are completed on schedule (generally meeting sprint commitments) – again, potential adjustments may need to be made if one team is struggling.
Monitoring for upcoming availability (or under-utilization of a particular skill) of resources occurs throughout the release, but is especially important when business needs and priorities change. As we see this approaching, RTE and Scrum Masters should have an idea where the resource can provide the most “bang for the buck” for the overall release.
As you can see, focus and evaluation has become elevated from a single team to the release (multi-team). We take the same Agile team concepts and broaden them across teams. The whole program/product (all teams) succeeds or fails together, no finger pointing that Team A wasn’t able to get their tasks complete on time due to Team B falling behind on a dependency. Ideally, this results in a highly collaborative environment.
Communication between the Scrum Masters and the Release Train Engineer is obviously critical to the overall success of the release. It is critical to manage any just-in-time reallocation that may be needed, recognizing when it may provide value, and then making any adjustments.
The key elements the RTE and Scrum Masters need to be discussing are:
The health of the entire program/product, not just a single team.
Keeping a pulse on changing priorities, both newly introduced high-priority items and stale/no longer needed items, how that affects overall backlogs, release and sprint plans.
Recognizing when any reallocation is going to be beneficial, and an idea for what constitutes a successful reallocation.
Determining if reallocation should be at the individual or team level, which teams are affected, and the duration.
Organizations already practicing Agile should have open lines of communication, and that mentality is carried to the next level. Obviously, each Scrum Master is going to have detailed knowledge of what their team is working on and any challenges encountered, but everyone should have a good idea where other teams are.
Tying It All Together
There are probably an infinite number of scenarios where reallocation would be beneficial. We have decided to use three which we believe to be relatively common:
New business needs/priorities have demanded additional features be included in the release.
What was once required for the release has been de-scoped or removed entirely.
Unforeseen challenges/complexities are at risk of putting one of the teams behind schedule.
Keeping the priority of stories current will quickly and easily show when something is at risk via the dashboard. Individual and team utilization should also be available, which will be needed when deciding to reallocate. Most likely, it will be apparent when a reallocation is needed, the question is, “what’s the correct shift?” Depending on when the release is will help determine that. In scenario 1 above, if the new feature is important enough other features may be ok to push to the next release then a Team reallocation makes sense. In scenario 3, maybe the challenge is in a technology the assigned team is struggling with, and reallocating a SME from another team will get them back on track, with acceptable impact to the SME’s home team. As we say so often in Agile, “It depends”. The art is going to be identifying when the reallocation is going to need to be made before it’s too late. The entire leadership team will be involved in this process, but ultimately it is the RTE’s responsibility to manage resources across the teams.
An additional benefit of any reallocation over time: the program/product team should experience the same cohesion and benefit that is traditionally seen in a single Agile team. Domain knowledge will be shared to a larger pool of resources, so that eventually more people can work in more areas of the program/product. Ramp up time when shifting resources will become less of an issue, and a known velocity can now be seen at the program/product level.
In summary, the above identifies key steps in order to begin optimizing at an enterprise / product suite level, not just a single Agile team. By having a system to reallocate resources, with the health of the entire product release as the focus, we can bring Agile organizations to a new level of optimization. This system should start with establishing a common “currency” of estimation, easy visibility of the status and health of all teams with clear indicators when a release is at risk, when resources (individual or team) are becoming available to shift to another team, and last but certainly not least, constant communication between all Scrum Masters and the RTE.
Enterprise OptimizationThis is the 2nd in a series of Enterprise Optimization articles. A follow-on article will give examples of how this could look using both a simplistic approach (limited budget for tools) and a robust tool solution.
Share this Post