Tools for Agility – A white paper by Kent Beck

Ajoy Krishnamoorthy, a product manager on our team, recently worked with Kent Beck to publish a great white paper on tooling for the agile team. The section on transparency really resonated with me especially this passage:

A transparent team can more cheaply and effectively coordinate their efforts towards shared goals. Acting transparently sends a signal to others that they can trust you. Trust, when realized, reduces the friction of development as people focus more on what they are accomplishing together and less on avoiding blame. Just as TDD allows me to trust my code and do more with it, trust on a team allows them to be more innovative and experimental.

I like the notion that transparency makes a team more effective, innovative and experimental.  I’ve certainly run into my share of teams that claim that they can’t tell me what they’re doing because to do so would slow them down.  Of course we still have plenty of work to do in order to make it easier for the tools to support transparency but I’m totally convinced that this is the right direction to go. 

What do you think?

Comments (2)

  1. I think transparency is a cornerstone of Agile.  Agile promotes better communication with the customer.  Hiding behind a vale of secrecy means you’re not communicating with the customer is many ways.

    I think transparency allows customers to "talk" to the development team–talking to them about what they want, not telling them what to do because the team is nebulous.

    Innovation and experimentation can come out this communication; but I don’t think it falls out of simply being agile.  Effectiveness and efficiency are improved through Agile; but projects only get more effective and more efficient through transparency because of this increased communicability.

    I would say that a team saying they can’t detail what they’re doing because it would slow them down isn’t truly agile–they’re not communicating effectively with the customer.  Agile isn’t simply an excuse to avoid the traditional artifacts that aren’t the software deliverables…

  2. Carl says:

    Transparency goes beyond the team members’ communicating to management and outsiders.  It involves telling your fellow developers what you’re doing; putting UML diagrams on a Wiki or white board to show what your code is going to look like and how it’ll behave and regular, tested commits of code.