Doing Agile, Going Nowhere

In the most recent State of Agility Survey Report, the majority of respondents cite Accelerate Software Delivery as the most important driver for agile transformation. Many organizations attempt agile transformations by adopting practices like Scrum or Kanban, and may even embrace scaling frameworks like SAFe, LeSS, and the like. They hire people to train and coach their teams in these practices and methods, spending heavily along the way. After a year or two into a transformation however, you may hear many leaders express frustration that they are not seeing the kinds of improvements that were promised, namely, getting new software capabilities to market faster with better quality, happier more engaged employees, and significantly improved customer satisfaction reflected in high NPS scores. In their view, the needle has not shifted in a meaningful way for any of these measures.

If Accelerate Software Delivery is a fundamental objective of the organization, then building an Agile Delivery System must be at the core of the transformation. Achieving this goal requires a couple of basic prerequisites:

  1. Teams designed around creating value.
  2. Establishing team-level agile delivery capability.
  3. Transitioning to an organizational architecture that enables teams to practice agile delivery methods unconstrained by legacy structures.

Team-Level Agility

If your organization is not agile at a basic team level, it’s going to be really difficult to be agile at an enterprise level. The ideal agile team is small (5-9 people), and has all of the skills needed to deliver increments of the Product Backlog on a repeatable, reliable basis, sprint after sprint. The Product Backlog from which the team derives its work comprises an ordered list of everything needed to achieve the Product Goal. The backlog items are written in a way that enables a productive conversation between a Product Owner and a delivery team – the ‘3 Cs’. Backlog  items represent increments of value,  and are sliced small enough so that they can be estimated accurately and can be delivered reasonably predictably. Predictable delivery requires the team to have achieved a stable velocity. The team can estimate and size backlogs and make reasonable forecasts about the rate of backlog delivery. Agile delivery teams must be able forecast the rate at which they can translate their backlogs into working software. Establishing a stable velocity must be a primary goal for any new team. (Kanban delivery teams can measure throughput). Business leadership from Fortune 500 companies  wants to know either: when will we achieve the goals reflected in the backlog, or, how much of the backlog will we have done in the next quarter. Not unreasonable expectations as they try to make plans and steer the business. It is critical that businesses can make plans with reasonable confidence based on a record of predictable delivery. No business leader wants to hear “we’ll let you know when we’re done.” Teams must know their production capacity and must quickly learn how to estimate. They need to be able to plan and deliver working product increments that meet a definition of done every 2 weeks, consistently and repeatably. Its in the Manifesto.

Of course some teams may need to operate in a highly empirical way where the nature of their work means planning beyond the next sprint is difficult. The plan for the next sprint depends entirely on the outcome of the current sprint. Teams in Lean Startups or in research-intensive environments are not usually operating under the same time and cost constraints.

Thus, delivery teams must be able to:

  • Define, refine and estimate product backlogs
  • Have the ability to produce a working increment of the Product Backlog every 2 weeks to a Definition of Done.
  • Operate with a stable velocity or throughput

If the delivery teams in an organization are unable to do these basics, then the organization will be incapable of anything that resembles agile delivery.

Many teams do manage to master agile delivery practices but delivery performance is held back by legacy organizational design constraints.

Agile Organization Design

Referring back to the same State of Agile Report referenced earlier we read that 4 of the top 6 barriers to agile adoption are organization-related:

  • Organizational culture at odds with agile values
  • General organization resistance to change
  • Not enough leadership participation
  • Inadequate management support and sponsorship

Teams cannot by themselves enact the kinds of organizational design changes needed to make Accelerated Delivery a reality. Getting the right organizational structure in place and creating the conditions where agile delivery practices can work effectively is critical to the success of everything else. Traditional functional silos create flow-impeding dependencies between teams. This can be the single biggest impediment to agile delivery at team level. Thus, organization re-design can be the work of largest consequence in any agile transformation, and should be prioritized as a first step. The State of Agile survey responses suggest that many organizations pay scant attention to setting up their organizations for success. Change for many means giving up power and control.

Changing an organization takes time. This is where we need leadership focus and commitment. Education can be a significant part of it. Leaders must understand that achieving team-level (leading to enterprise-level) agility is impossible if teams are strangled in dependencies.

Typical Program Board
Typical Program Board

Dependencies are the single biggest roadblock to enterprise agility. The primary focus of a transformation should be to break the dependencies between teams. That is, to create the conditions where team-level agile practices can actually work.

A value stream mapping exercise can help ensure teams are focused on customer value delivery, have clear missions, and can operate with maximum independence and autonomy. The best delivery performance in terms of throughput and delivery cycle time is achieved with small, autonomous, cross-functional teams that can independently deliver deployable features.

 

 

Print Friendly, PDF & Email

Similar Posts