Doing Agile, Going Nowhere

In a recent State of Agility Survey Report, the majority of respondents cited Accelerate Software Delivery as the most important driver for agile transformation. Many organizations attempt agile transformations by adopting practices like Scrum, Kanban, or SAFe. They hire consultants to train and coach their teams in these practices, spending heavily along the way. After a year or two into a transformation, 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 scores. In their view, the needle has not shifted in a meaningful way for any of these measures.

When we look at some of the underlying causes for lack of progress we typically see:

No committed performance goals for delivery teams.
No framework in place for continuous improvement.
Disengaged employees.

Successful teams have clear, measurable targets for their delivery performance, and everyone on the team is committed to achieving them. Lack of goals means lack of direction, and no way to measure progress. Agile delivery teams should have goals for things like: achieving stable and predictable throughput, cycle time reduction, and high quality delivery leading ultimately to improved value for the customer.

These goals will not be realized via ad hoc changes – there must be a systematic and continuous effort to improve. The Lean model of continuous incremental improvement through Kaizen is an effective approach that can help teams achieve their goals. A Kaizen approach can be incorporated into the retrospective process to help teams pursue long-term goals vs ad hoc changes.

Without full engagement from the team nothing substantial is likely to change. A healthy team is a prerequisite for change. Progress is accelerated when the team is healthy. Issues get solved, not avoided and information flows freely. Trust exists at all levels. Collecting feedback from teams on a regular cadence is essential to ensure team members are sufficiently engaged and energized, and for prompt action to be taken to address any issues effecting team performance.

We have just touched on some of the most common challenges that prevent teams from transforming their performance into something that looks like true agile delivery. In the chapters that follow we will take a closer look at these topics and propose solutions that teams can leverage to get themselves onto a path of sustainable improvement.

Agile Team Design

If organizations are 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.

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.

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.

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

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.

Product Backlogs That Enable Agile Delivery

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.

Establishing a Predictable Delivery

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.