Transforming organizations for speed

The influence of organizational structure on successful delivery

Organizations aligned rigidly around role and discipline cannot fully address customer need, as these organizations are optimized to advocate for their own existence. Too much focus on the nuance of a particular job function can hinder groups or individuals from fully addressing customer needs.

The full value of each role is not solely in its ability to execute, but rather in its contributions to a cross-functional team delivering meaningful customer experiences. Any time an investment is made into a digital experience, a matrix reporting structure is erected. This often leads team members to prioritize concerns of their core functional group over the concerns of the product and its customer.

The challenges of balancing product need and organizational considerations is not new.

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”

This revelation is commonly referred to as “Conway’s Law,” coined by computer scientist Dr. Melvin Conway in 1967. The challenge he identifies feels as relevant as ever to modern software delivery and extends beyond designing meaningful experiences and systems.

Conway’s Law is fitting when applied to digital transformations: For digitally transforming organizations, operational areas left untouched (or allowed exemption), will actively resist and passively revert your organization to the old ways of business. In other words, operating successful pilot teams is easy in isolation. However, value at scale cannot be realized without extending best practices beyond the pilot team.

One way organizations scale this value is through Agile software practices. Ron Jefferies, an early advocate of Extreme Programming (XP) and Agile software development, once stated that the structure and teaching of Agile to an enterprise is “relentlessly top down.” For Agile product development to be successful in the long term, a company’s culture—the way it operates and how it thinks—must change. The highest levels of leadership, from the CEO to the front lines, must defend and protect their empowered delivery teams.

For digitally transforming organizations, operational areas left untouched (or allowed exemption), will actively resist and passively revert your organization to the old ways of business.

Leadership can enable success by decentralizing decisions to the Product Owner through an empowered ownership and authority model. Product Owners then bring business objectives and opportunities to small, cross-functional teams. The teams, focusing on these specific desired outcomes, work to solve those problems. This approach is fundamentally different from classic project management. Instead of centralized authority, decentralized decision-making allows those best equipped to make decisions to affect change more efficiently.

Align on corporate goals but let each delivery team make decisions based on its own data.

When organizations evaluate the cultural or structural changes they’ll make alongside transformation, they would do well to remember Conway’s Law. The way companies shape reporting, responsibility, and funding will directly influence the output of teams and the value of products they build. An effective ship’s captain trusts their crew to keep the vessel moving along its charted course.

The right metrics keep teams on track

The most common cause of failure in enterprise transformation is, perhaps ironically, the fear of failure. A hierarchical chain-of-command structure stifles progress. It’s difficult—if not impossible—to obtain exponential business value quickly when product teams need six levels of approval for each decision. When organizations relinquish centralized control and traditional layers of reporting, they empower their teams to make decisions, fail, and succeed—and to do so quickly.

We’re not suggesting that metrics and executive leadership take a back seat. Quite the opposite. A transformation without established KPI’s is a ship without a captain (or, activity without progress). A product delivered to market on time and on target can indicate a successful team, but a full picture of progress becomes clear when the product achieves its desired outcome. Effective enterprise portfolio management steers organizations through setting and adapting product teams’ goals and objectives. It does not micromanage specific backlogs and feature releases. The use of KPIs and team performance metrics indicate which areas of the portfolio require executive attention.

When organizations relinquish centralized control and traditional layers or reporting, they empower their teams to make decisions, fail, and succeed—and to do so quickly.

The need for tracking metrics in Agile product development cannot be overstated. With this need in mind, we developed the PowerUp app, which shares product health reporting data with our clients. PowerUp aggregates data from Jira entries and time-tracking software to report on the status of an enterprise’s entire product portfolio. All aspects of the Agile delivery process are tracked in real-time—from team velocity to the time entries of individual contributors. A key step in adopting Agile at scale is building a transparent process. Maturity, familiarity, and expertise are essential across teams. PowerUp provides the fundamentals for such reporting. The tool also creates trust and transparency among internal teams, delivery vendors, and integration partners via a single, actionable ecosystem.

Product delivery metrics

Velocity is a measure of your team’s predictability over time. It’s not easy to compare velocities across teams, as various rolling factors contribute to a team’s weekly velocity. It’s best to calculate this in a rolling, three-week window.

Volatility is a measure of the accuracy of your team’s predictability over time. Highly volatile teams do not provide the business with confidence in predictability. After 3-5 weeks, the accuracy of a team’s volatility should emerge. Review teams with high volatility. This metric can compare teams to determine success and identify problems.

Burndown and burnup charts reflect your team’s progress toward completion and progress against rising scope, respectively. Both are helpful metrics to understand a team’s accomplishments over time, especially on projects that are trending beyond initial estimates. You can use low-volatility velocity and a burndown chart to determine the estimated date of completion.

Team strength is an additional factor you can consider when planning your team’s velocity. If a set of vacations are coming up, or if the regular ebb and flow of a team’s days in the office fluctuate, consider updating your calculations to reflect it accordingly. This also impacts your budget, velocity, and volatility.

Product KPIs should drive a larger priority level above all else. A highly predictable, productive team building a product that doesn’t fit the market should quickly be refocused on new initiatives.

Overall project health is more than a single metric, although a specific metric could indicate deeper issues to pursue. With all metrics in place, the application’s path to success can be measured. Decision makers can determine the tolerated burn rate, budget, and schedule. Learnings and delivery rate can be tracked against expectations. The availability of this data can expedite many processes, but don’t discount hard-earned experience. Ruthlessly prioritize product portfolios against outcomes.

Velocity is often used as team’s success indicator. Velocity is not a measure of success, but rather a predictive metric that can be used to estimate future progress. Similarly, the volatility of a team’s velocity is an indicator of that team’s predictability. With it, you can predict and plan according to its progress. If teams are incentivized by the number of stories they ship or points they close, their stories will get smaller and their point estimates will rise without any additional value delivered to the business.

Organizing around product optimizes for delivery

Organizing around product thinking—and most importantly, product delivery—is a hallmark of becoming a customer-focused organization. Customer-focused organizations are better poised to respond to change in the market, and as such, maintain their advantage. The added benefit of Agile in transformed delivery is often oversimplified as merely the speed at which a product ships to market. A more complete view of the Agile methodology focuses on delivering the right thing to market, with the most resilient code, in the most efficient way possible.

A transformed organization prioritizes people and product over tools and process. Design thinking isn’t a shortcut to product-market fit. Test-driven development and paired programming cannot alone ensure a resilient codebase. Agile ceremonies such as sprint planning, retrospectives, and scrum of scrums, are merely ceremonial without action. These documents, methodologies, and artifacts provide clarity, but are not intrinsically valuable. Great products are delivered by cross-functional teams aligned to a business goal and measured against desired outcomes. The value of a team’s effort is not fully realized until a product is in the hands of a user. A true captain navigates through the rocks, ensuring the crew safe passage.

Organizations optimized around delivery embrace iterative, measurable progress, and rapidly integrate feedback into product direction.