- Lean Software Engineering - http://leansoftwareengineering.com -

We can’t afford to trust everyone on larger teams

Posted By Bernie Thompson On December 7, 2007 @ 1:55 am In agile,lean,management,project | 6 Comments

This is part 3 of 10 Pitfalls of Agility on Large Projects [1]. In part 2, we talked about how effective small teams need coordination to make an effective large organization [2], and what to do about it.

When cycles get shorter and our teams become more empowered to react to change, one fear is that accountability will get lost in all those changes.

Specifically, when something goes wrong, what is the root cause? Are my people failing? our processes failing? our plans unrealistic? How can management learn how to head off these failures in the future, if we aren’t making commitments and measuring progress against them?

Step one is to take some of this pressure off — in fact, to embrace failure as a path to learning, and taking a statistical approach to making the most of it.

Like a pharmaceutical firm screening new compounds, or venture capitalist building a portfolio of investments — a manager in a high-risk domain needs strategies to spread the bets to maximize opportunity while minimizing overall risk. This is basically Set-Based Design [3] (Toyota’s Set-Based Concurrent Engineering).

Software development, in particular, is a research and development activity suited more to this approach, and much less of a traditional production activity.

Step two is creating an environment with much more transparency — it’s not about trusting people to execute to plan, rather it’s about trusting people to be transparent about the true progress and status of the project, so that everyone can adjust accordingly.

[4]One mechanism is a public kanban board [4] like the kind Corey has been exploring on this blog (from work with David Anderson at Corbis). By watching the board over time, throughput of the team and bottlenecks within the team become clear.

An electronic version is important if there are people (dependent teams, remote teams, or upper management) that can’t huddle around the board.

 

Cumulative Flow Diagram [5]A Cumulative Flow Diagram is an electronic alternative that can be a great way to both summarize the flow of value, gain visibility into the history, and see important management events (like estimation troubles, or WIP getting out of hand, or new priorities causing the plan to grow out of control). This CFD is again from David Anderson, as described in his 2004 BorCon presentation.

In a future post, we’ll look at a way to create and manage by CFDs, even when each kanban (or feature) is not similarly sized — this involves also collecting time data (which then has other uses).

And, of course, if rework and bugs are tracked separately (as they usually are today), then traditional bug charts are critical to management.

Should a small team of 4-6 developers with a strong process like Extreme Programming layer this kind of data collection on to their process? Probably not. But as teams grow to 15, 50, or beyond — this kind of transparency is critical glue to keep management and teams coordinated, even while allowing each individual and each small group to work on short cycles and be highly responsive to change.

On your projects, have you seen other forms of data collection that are both lightweight, keep everyone in touch with reality, and help build trust?


Article printed from Lean Software Engineering: http://leansoftwareengineering.com

URL to article: http://leansoftwareengineering.com/2007/12/07/we-cant-afford-to-trust-everyone-on-larger-teams/

URLs in this post:

[1] 10 Pitfalls of Agility on Large Projects: http://leansoftwareengineering.com/2007/11/12/10-pitfalls-of-agility-on-large-projects/

[2] effective small teams need coordination to make an effective large organization: http://leansoftwareengineering.com/2007/11/19/effective-small-teams-need-coordination-to-make-an-effective-large-organization/

[3] Set-Based Design: http://www.agilemanagement.net/Articles/Weblog/SetBasedDesign.html

[4] Image: http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/

[5] Image: http://bdn1.borland.com/borcon2004/article/paper/0,1963,32096,00.html

Copyright © 2007 Lean Software Engineering. All rights reserved.