Here’s a great presentation from Mary Poppendieck,  On the role of leadership in software. Mary has of course been very influential in the agile movement, and here she describes the early formation of her ideas, being derived from her work in JIT/Lean manufacturing.

In the factory where Mary worked, employees faced a very harsh reality. Improve the production of videotapes, whilst reducing costs, or face closure of the plant. Competitors in Japan were killing them. (40:30 min mark)

By identifying their targets clearly (the number of videotapes required per day/shift etc, and the cost limit), Mary and her colleagues were able to build a model of alternative work practices, solving bottleneck issues one by one until they were convinced they could achieve their goals. She has translated this kind of experience into the basis for a method of building software effectively.

Aside from the general ideals she suggests managers should aspire to (engagement, collaboration, empowerment), for me, the underlying message from this, is the need to identify a team’s required activities. Guessing just won’t do it. We do this in Release planning, and more granularly during Sprint planning, I believe the most important of Scrum’s prescribed activities.

The challenging part of software development, is that there’s likely to be emergent work, or challenges that lie hidden inside the work we plan. In other words, the time and money spent in the production of one videotape (although I’m no expert on videotape production!), should be about the same each time, given a process is followed. The time taken to deliver one software feature will differ greatly, depending on the feature.

Sprint planning, and the time a team spends actually discussing it’s plan for completing the increment is vital, and every minute will bear fruit. It’s a chance to model the production plan for the sprint duration, experimenting with different approaches and removing bottlenecks that might be identified.

There’s a temptation to give in to the feeling that talking is not doing, and you’re better off getting started without too much chat, but I couldn’t disagree more. The conversations that we have, the atmosphere during sprint planning, the extent to which software professionals are prepared to passionately engage with one another in laying out their plan, are the litmus tests that indicate the health of the team, and the likelihood of its success.