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?
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Leave a Reply