Question: Is it better to start scaling before you have alignment across executives, business units and products or is it best to first get alignment and start your agile transformation with a process that is designed to keep the entire business in alignment?
Starting with good alignment is an absolute no-brainer for the rare few but that is not the reality that most large organizations live in. So the question then more realistically becomes something akin to: Is it better to get started before we have alignment and try to iterate to alignment knowing it will be a big mess or do we wait and spend time trying to get everyone to buy in on a single framework and flow before you start. These days I see a lot of organizations landing on let’s get started and iterate to alignment as fast as we can. It is seriously messy and political for all involved but waiting for alignment is like waiting for an honest politician. It does happen but it’s like seeing the northern lights (rare and unpredictable).
With the deliberate intent of iterating to alignment in a complex and political system, in this blog we’ll take a look at the 5 steps that can get you there faster and help de-risk a vast transformation.
#1 – Set the Terminology - When bringing together many groups, it’s pretty common to have terminology used in many different ways. In order to set the enterprise up for success, terminology should be set across the enterprise. By doing this you will break down communication barriers from the teams through to the executives. Agile is acronym rich and confusing for business people with limited agile training to begin with. If the groups do not use common terminology this challenge is accentuated. This gets the enterprise speaking the same language from day one. This is true even if you have multiple methods and levels of agility at play. Finding that common vocabulary is worth the effort.
#2 – Connect the business to technology - A key part of the alignment is creating the connections between your business and your technology. The epic (also referred to as a project historically) should be consistently used to link business to development. The epic should require a base level of data to capture intake, budget, approval, high level estimation, business case and link to corporate strategy. By creating this link, all business units and portfolios are aligned for financial, strategic and progress reporting.
#3 – Fix the number of backlog levels and estimation models - An important step in the process is to fix the amount of backlog levels and estimation models. The enterprise should require a consistent level of backlog decomposition across all teams regardless of agile maturity level and a common unit of estimation across those levels (i.e. the enterprise uses the same method to estimate the epic - either team week, person week, points, WSJF or t-shirt size). A common structure is Strategy -> Theme -> Epic -> Feature -> Story. The flatter this hierarchy the easier it will become for the portfolio, programs and teams to right-size their backlogs and become predictable. Other levels can be added but the complexity and estimation accuracy will likely be affected. The task level below the story can be optional depending on level of agile maturity. Often a portfolio will work with tasks until the teams reach a high level of predictability and are able to break stories down to low point levels at all times. Once predictability is achieved, tasks can be removed and the teams can rely on story points alone. A standard depth of backlog and method to size the backlog improves predictability, visibility and communication across the enterprise.
#4 – Get a common planning cadence - A key step of driving towards alignment is ensuring your enterprise is on a common planning cadence. Seems like a pretty basic concept however a common planning cadence is needed to drive consistency across the enterprise and enable cross-program / cross-portfolio planning. Decoupling planning from delivery is virtually the only reliable way to help all of the teams align risks, objectives and dependencies. Getting all teams to line up around quarters, for example, is a common way to get everyone planning together. Although not required, getting the teams on a common sprint cadence increases efficiency and productivity with another frequent alignment mechanism across teams.
#5 – Implement dependency management - The last step is to implement dependency management. You must have a team to team dependency management process for all feature level delivery. This process enables the teams to plan their roadmaps and delivery schedules. Without a firm commitment of teams that is strongly aligned to the calendar, it is near impossible for teams to commit to dates if they are dependent on another team. Best practices once this is in place is to analyze dependency clustering activity then optimize programs and teams to reduce the amount of dependencies. Dependencies are an agility killer and the best way to reduce them is to modify the technology or the structure of portfolios, programs and teams (or a combination of both). This is very difficult to do so the first step is strong management of dependencies.
A few runner ups include:
- If possible align the states and workflow across all teams to streamline reporting and communication.
- Create risk definition and regular risk management for all feature level delivery items where a significant impact on variation in outcomes is advised for better outcomes.
- Once the backlog is delivered, implement acceptance criteria to be used at the Epic, Feature, Story level.
- Put constraints on acceptance criteria to add guardrails for compliance by program as needed.
- Aligning the work to strategies and themes for all business units (with placeholders where definition does not exist) provides invaluable reporting at the executive level that can be used in the future to place better bets and ensure that we are working on what will impact the business the most.
The items above get us to a level playing field where all work is visible. From there I submit that agile practices with dedicated teams will prove superior in delivering quality with predictability. That fact will be very transparent and hard to dismiss. Positive results accelerate the move to agile and build excitement to further invest in simplifying software at scale. Transformations are not for the timid but out innovating your competition through the use of technology is the prize.
Can that really wait another day?