I hadn't really thought Transparency as a Lesson until I got to the end of the week and still haven't written about the Product Owner.

It's better to admit the failure - I have no posting ready, than to either ignore the problem or dash off a poor quality post.

Scrum forces transparency on us in the review meeting when we demonstrate working software. What ever we have achieved (or failed to achieve) becomes apparent at the moment. For a Product Owner who is used to hearing back seeing software once every 3-6 months this will be a breath of fresh air. But transparency can be taken further.

• Admit when Stories or Features are at risk for an iteration. Sometimes the burndown chart suggests that everything is good even when we know that a story is at risk. Tell the product owner, expose the problem.
• When decisions are made without the presence of the team (never a good idea). Communicate not only the decision and the reasoning behind it - but also an explanation as to why the team was excluded.

By being transparent about decisions, mistakes, failures etc. we will earn more trust from the people who depend on us.

My confession: This iteration my team took on a very ambitious sprint goal. For the next two weeks most of my energy will be focused on meeting that goal and not on writing.

Where have you found that transparency made a difference for your team?

If you enjoyed this post, subscribe now to get free updates.