Stabilizing Teams for Agile Practice

First published in The Agile Zone, 13 February 2014

"No civilization...would ever have been possible without a framework of stability, to provide the wherein for the flux of change".

- Hannah Arendt

Introduction

A few weeks ago we looked at how to build transparency - the first step towards agile transformation. We saw how an elementary Kanban board can be used to promote visibility in three key areas of team-based production: 

1. the work the team expect do in the near future. This is added to a Backlog (essentially, a "To Do" column) on the leftmost side of the board. 

2. the work the team members are doing right now. This is shown in the Work In Progress (WIP) column. 

3. the work team members believe they have already completed satisfactorily. This is shown in the Done column on the right hand side of the board.

We also considered why this application of a Kanban board is controversial. Essentially it's very limited in what it can achieve. All we can expect out of it is a logical flow of items from left to right on the board, as work is brought out of the backlog, into progress, and finally completed. A cynic might argue that it reduces the board to nothing more than a glorified "To Do" list.

Nevertheless, this usage can help make a messy situation more clear, and I consider it invaluable for providing the transparency that is needed in agile adoption. Beyond that immediate visibility however, we must accept that such a board does not in itself provide any of the disciplined techniques or benefits that underpin Kanban or other agile methods. So, what we need to do next is to "up the game" of the nascent agile team whose work the board is intended to represent. The first thing we must do to help this aspiring team is to find out who should actually be on it.

Stakeholder identification

In practice, identifying who is and is not a member of a team can be surprisingly difficult. This is because the stakeholders involved in a project or workstream typically exhibit varying degrees of commitment. What we essentially need to do is to separate out the producers and consumers of value in the stream of work that is represented on the board. This will give us candidates for development team members (the producers) and the consumers of value who need to be represented through product ownership. We also need to identify any parties who the team are dependent upon in order to complete their work, but who cannot be regarded as team members themselves.

Let's get started by having everyone examine the Done column on the board. Ask the various stakeholders how they know the work is completed. Who did the work and who accepted it? Who wanted it done in the first place? Was anyone else involved in the process, and if so, how? What were the terms of acceptance?

You can probably see where this is going. We need to find out what Definition of Done is being applied, and whether or not the "team" have the skills and authority to take each item on their backlog through to completion according to those terms. This ability is fundamental to an agile way of working. If a team can't meet its own Definition of Done, then team members cannot account for what they are doing and that means they aren't agile.

Normalization of the team

Broadly, there are three things can be done to remedy such a situation:

1. Any others whom the team are dependent upon can be brought within the team, so the team has all the requisite skills and authority to do the work expected of it 

2. The team can acquire the necessary skills or authority some other way (such as by training), or

3. The Sprint Backlog can be restricted to exclude any work the team cannot wholly do themselves, thereby potentially limiting the usefulness of the team's output.

That's pretty much the order of options. If the creation of a fully empowered team isn't acceptable to the wider organization, or if it would create too large a team for agile practice, then the responsibilities of the team in value creation will have to be reduced accordingly. For example, if the creation of certain services is required in order to produce an increment...but the associated skills can only be resourced from outside of the team...then the team must refuse to accept any requirements that demand such service provision from them. If they don't have the skills or resources do the work, then it would be remiss of them to pretend otherwise and to be held responsible for a delivery they cannot make. Instead, the available output of the team will have to be integrated with externally provisioned services from another group or team. This will obviously carry some management overhead, including a shared Definition of Done and a shared release strategy.

Introduction of daily standups

What we have done thus far is to identify a core Development Team and distinguished it from other stakeholders. This team is fully responsible for its own process, and is able to select an appropriate backlog of work for completion, and for integration with any other resources that will be needed to make a release.

The next thing to do is to cultivate the team's sense of process ownership. We've already gone part of the way by improving transparency of the work they do by means of a Kanban board. Now we need the team to look critically at that workflow and to inspect it carefully, with a view to finding improvements. Perhaps the most common way of handling this is to hold a Daily Standup and most agile teams include this event in some form.

The canonical standup format is taken from Scrum where the event is time-boxed to a maximum of 15 minutes. Attendees address the work done since the last stand-up, the work they plan to do before the next one, and any impediments stopping them from doing so. While such time-boxing is unquestionably important to avoid drift, and should be observed, a focus on these three concerns will not in itself promote collaborative working in an immature team. The attendees are more likely to recant their activities independently as if by rote. There is a danger that no team replanning will occur at all.

A better option, at least with new teams, can be to "walk the board" by considering each item in turn. The Scrum Master, Kanban Leader or agile coach may facilitate the session. Start with any work items that are impeded. What needs to happen to unblock them? Now shift the team's attention to work in progress. What has to happen for this work, now in-flight, to be completed? Finally look at the work still in the backlog. Once impediments are removed and the current work in progress is done, which of the remaining items are ripest for development or most urgent, and should be actioned next?

"Walking the board" in this way is more commonly associated with Kanban standups than Scrum ones. As such, it doesn't elicit individual contributions to batched end-of-sprint delivery or to the attainment of a Scrum Sprint Goal. What it does do is to accentuate the importance of team focus on throughput and ticket completion, and makes plain the need to achieve limited WIP. This discipline is essential for any species of agile practice, and its development must be encouraged at the earliest opportunity.

Refactoring of tickets

The next thing to do is to rationalize the items on the board. We've moved them around a bit and perhaps even removed a few, but apart from that they remain unimproved and their quality could be poor. Ideally each item should be a ticket that represents a small and achievable piece of work, and which delivers clear business value. Each should be independent of other tickets so it can be actioned without impediment. Remember, the rapid handling of work in progress is important because it minimizes the opportunity for invested effort to depreciate in value.

Each item on the board should be challenged in these terms. What business value does it add, and is that value clearly expressed? One option is to write each ticket as a "User Story" which specifies who receives the value and why. Next, does it represent a piece of work that can actually be done by the team? If not, should it be moved to another team or should the scope be narrowed? What are the criteria for acceptance, and are they clearly articulated? Is each ticket small and independent enough to facilitate rapid handling? 

Drafting of a candidate backlog

So far we've allocated the tickets that have not yet been started to the "backlog" on the board. However, in agile terms we don't have a true backlog yet. This is because the items within it are missing an important characteristic: they have not been ordered. A lack of ordering is a problem, because team members will not know which ticket to action next once their current work in progress has been completed.

Do you remember when, during stakeholder identification, we identified "the consumers of value who need to be represented through product ownership"? Those Product Owners now need to start earning their keep. They may not be involved in actual product development (i.e. the work in progress), but they are ultimately accountable for business value and the return on investment of all work that is subsequently completed and delivered. The backlog really belongs to them because it describes what needs to be done and the order in which the various items should be tackled. In short, they need to turn it from a set of items into a queue. How they determine priorities is really up to them, but it is usually a function of cost, time, and scope where quality is expected to remain consistent. If clear product ownership cannot be established then a Kanban team may prioritize its own backlog, although the business value of the work being done should then be questioned. Does anyone truly want it?

The enqueuement of work promotes discipline not only within the team itself, but also in how it is perceived. It becomes clear to those stakeholders who are outside the team that there is an order and rigor to the process being followed. Work cannot be actioned at the drop of a hat; instead it must be prioritized and wait its turn. Team members know what work is currently scheduled to come up next, and they can flag any concerns ahead of time regarding its suitability or the likelihood of complications.

Starting to think about releases

In this brief article we've looked at how to stabilize a team so it can transition towards an agile way of working. We've found ways to clarify which work has been "done" and what that actually means, and we've established the priorities of work remaining. We've also tightened up on team boundaries and on the ownership of both product and process.

Now we need to shift our attention to the work that has met the team's Definition of Done and which is considered to be complete. What happens to it now? What does the Product Owner do with it, in order to achieve the "return on investment" he or she is responsible for?

What I'm driving at is this: work which has been completed has not necessarily been released to an end-user or customer. Admittedly in some cases it might have been, but these are an exception rather than the rule. For example, work done in a "business as usual" (BAU) context tends to consist of small changes that are of low business risk. There's typically no reason for any delay in such cases, and the development team may be authorized to deploy their modifications into an operationally live environment. This is sometimes referred to as a "DevOps" model and it can help facilitate a very rapid and agile turnaround with minimal cost of delay.

In the context of projects rather than BAU, however, it is rare for work to be released immediately into operation. This is because each item on a project backlog is typically just a small piece of a much larger effort of work, the value of which cannot be realized unless all of the constituent parts are brought simultaneously into play. This implies that work completed will have to be batched until sufficient and appropriate value has accrued in the product, and a coherent deliverable can be released to end users.

The project model can be criticized because of the cost of delay that is incurred. Moreover, batching work is essentially unagile due to the attenuation in feedback that results from the delay in releasing the batch. The ability to inspect and adapt is effectively compromised. This can result in a build-up of technical debt as problems accumulate in the batch undetected. A lot of risk ends up being deferred onto that big release.

Fixing the release model for projects is beyond the scope of this article. Solutions do exist, including the Lean Startup approach which emphasises the importance of delivering a "Minimal Viable Product" in order to validate business assumptions. Once a product is seen as a learning tool then batched changes can become very small indeed. The constraint on releases is merely the speed with which the organization is prepared to learn. Most organizations, however, are a long way from achieving such levels of business agility and many don't even understand the principles concerned. For them releases must continue to be planned. This means that larger batch sizes, and the concomitant accumulation of risk, must be expected. What we need to do is to minimize the exposure as far as possible, until such time as an enterprise agile transformation can be sponsored. A "rolling" release plan can help if it is constrained to a window of between three and six months. This usually strikes a fair balance between the stakeholder desire for predictive information and the agile delivery of value with minimal cost of delay.