Layered Transparency

November 12, 2007 by Artem

Glasses

One of the corner stones of the agile methods is transparency. Working software over the documents is one of the primary agile values. All the agile methods are explicitly based on making things explicit and clear.

Release and monthly level

There is always some form of a product backlog present with very clear priorities that leave no chance for listing all items as "absolutely mandatory". Product owner or customer have to make hard decisions and throw away something old if they want to do something new. There is not or at least should not be any way to silently sneak he extra work in. Teams compute their velocity per iteration and together with the product backlog it allows the stakeholders for seeing the real project status very early, allows for actually making the decisions on the release content and schedule without having to force the team work overtime.

Daily level

Transparency in agile methods goes to the daily and hour-after-hour work level. Daily transparency related practices often include the daily stand-up - mini-meeting typically timeboxed to 10-15 meetings, where everybody has to stand up and tell all the team members about yesterday accomplishments, today's plans and problems on the way. The purpose of such a short and focused meeting is exactly to allow the team see into itself, to be transparent without diving into the non-important details.

Hourly and minutely level

Hourly or even minutely transparency is supported by the code level practices of test-driven-development and continuous integration. Test driven development forces developers to actually specify the small piece of code they are going to work on, continuous integration allows for detecting problems right at the moment, when they are introduced.

All these methods allow virtually everybody in the company to see very clearly the status of the project at any level, from the release plan, to coding. Such transparency allows for making decisions based on the actual data and not guesses.

What about your company? When does the management usually discover the potential problems in the release and take the corrective action? When does the developer typically notice the critical bug introduced by his fellow mistake?