Learning Lean, the Final Session

I've been attending a web-based course from Alan Shalloway on lean. Here are some of the highlights from the final session (focused on Product Coordination and Release Planning). See this link for the previous session (which contains links to the other sessions as well).

In general, delays are caused by taking things on in too big of chunks: large projects, large stories, large queues, or too many projects. These delays cause inefficiencies since the amount of work in progress is higher. By breaking things into smaller chunks, productivity increases as does flexibility (the ability to change based on what you've learned).

Where waterfall encourages larger features with phased delivery of those features, lean encourages smaller features where the phases occur simultaneously. Many of today's engineering practices encourage this simultaneous delivery. Test driven development brings together design/code and unit test. Acceptance driven development brings together analysis and functional test. Continuous builds bring together analysis and system test. Fast deployment brings together analysis and deployment.

If you have multiple scrum teams, how you coordinate them can make a big difference. Cordination involves: working together on design, pulling from the backlog, reducing redundancies, coordinating changes to the same code, etc.

In my experience, scrum of scrum meetings can help with this. First, you want to reduce the dependencies by organizing the teams such that each can take on features end to end. Second, you want to work off a common backlog (since this unifies the priorities). Third, you want to synchronize the teams so that they're working at the same iteration and release cadence. Finally, have a scrum of scrum meeting (should be quick and run similarly to the daily scrum). The frequency of the scrum of scrum meeting will vary depending on how much coordination needs to occur. I've seen scrum of scrums work very well.

In Alan's experience, he's rarely seen scrum of scrums work well. Instead, he recommends a cordination team. This team identifies the overlap between teams and coordinates them working together. A member from this team attends each team's sprint planning. They then meet after all teams have planned and ensure that the teams are in synch. The coordination team is a service organization: its members rotate (to avoid ivory towers), it includes technical leads / architects, it is constrained by business value, and its size is as minimal as possible. They elevate stories involving multiple teams and manage dependencies and emergant design. They help to avoid redundancy, promote reuse and spread lessons learned. They create buy in and improves efficiency.

To maximmize business value, organizations should maximize customer feedback, defer commitment, and eliminate hand offs (no functional teams). Some risks are building more than is needed, building it wrong / poor quality, architectural risks, wrong resources, discovering things too late, and delays. All of these are made more likely by attacking things in big batches. Big batches tend to hide priorities, allow us to build stuff we don't need, require more administration / organization, hide defects / technical debt and slow time to market.

The goal: the business must continuously prioritize and decompose features across the organization, management must organize cross functional teams that can deliver incremental end to end features, and teams must work together to deliver fully tested and integrated code daily.