Team Retrospectives Are Not Enough for Enterprise Agile

This post continues my exploration of what it takes to be successful with enterprise agile software development. The Scrum-of-Scrums only scratches the surface of what you’ll need to do. Let’s reconsider the role of the retrospective.

Everyone practicing any agile development approach should recognize that regular retrospectives are a critical success factor. Teams need to continually improve lest they fall into bad habits and stagnant routines.

There is an even bigger problem at the enterprise level. While each development team can conduct retrospectives and improve internally, the outward facing activities and team interactions may not benefit. Broad-based retrospectives covering multiple teams are needed to derive maximum benefits.

Consider this simple example.

A software application consists of three components, a graphics user interface, a service, and a device driver. For this simple example, let’s assume that we have three teams, one for each component. The teams may function well internally though no conclusions can be drawn regarding how they will work together.

Business people know nothing about system services or device drivers. They just want the application to work smoothly and reliably. They need the software parts to come together in a seamless and transparent fashion. If the GUI and the device driver are delivered on time and with good quality, but the service is delivered late or buggy, all three teams fail.

To get it right, the three teams have to work well together including a willingness to compromise. Whether a given software function belongs in the GUI, service or driver will, at times, be open to debate. The teams will need to figure it out on the fly.

It’s also likely that the three teams will operate somewhat differently. They may all be using Scrum, for example, but their definitions of done, their coding styles, and the rigorousness of their testing will likely be different.

Conflicts are inevitable. Joint retrospectives can help address them.

A good start is simply sharing information that comes out of the individual team retrospectives. There will be many ideas that span teams and can help everyone improve.

Next, conduct joint retrospectives among teams that work closely together and are heavily dependent on each other. These joint retrospectives will focus on team interactions and hand-offs. Again share the results so other teams may benefit.

Also consider broader retrospectives covering all the components of an enterprise application. It won’t be possible for all the members of every team to participate, but the teams can send representatives. Such broad retrospectives will focus on application-wide pain points likely to include software quality, output consistency, system performance, and team dynamics.

Retrospectives are great continuous improvement tools. Take full advantage of them and share the knowledge. For more information on retrospectives, take a look at my prior post on the topic called “Retrospectives Make Agile Teams Better”.

Updated: February 12, 2012 — 10:06 pm