Transparency in Agile Product Development

3 June 2013

The word "transparency" can be easily misused. Even dictatorship regimes are convinced they are transparent. Companies advocate transparency while they disempower their teams for mediocrity. I have more examples to share, but the point here is: What does transparency mean in Agile?

Is transparency used in an empty sense? Can we have an objective definition of transparency in Agile? Does this definition vary based on the culture of the group, the company, or even their country at large?

I notice how teams react when I start using this word. I have decided not to talk about transparency but instead to take specific actions.

Many failure scenarios can happen in Agile projects because of lack of transparency. Examples include the following:

  • The product owner or management reduces the estimates that the team has created.
  • The product owner does not want to include technical stories as part of his prioritization.
  • The product owner does not want to become involved.

I present here six specific actions that can promote transparency. These actions are for the product owner, while supported by the ScrumMaster and other groups in the organization.

1. We are primarily discovering, not constructing.

Even for the priority features you add to the product backlog, you may not be sure if they are the right ones. You need help from the team to go the extra mile to shape those features and deliver them incrementally and iteratively. Having that will help both the team and you gain the knowledge required so that the end user will use those features.

Product discovery has more complexity than Christopher Columbus had when he discovered the New World. That complexity is that the validity of feature discovery is time limited. If you discover a new land, you've discovered something that lasts forever. However, what you discover about product features will soon change or can quickly become obsolete.

2. Walk the gemba.

As product owner and ScrumMaster, invite the user community as well as management to walk to the place where the team works (the gemba).

  • Tell them to visit this place and talk to the team whenever they like.
  • Share with them the visual product backlog, release plan, burn-down chart, product vision, and other valuable artifacts.
  • Encourage them to listen attentively to the team, ask questions, and communicate their feedback.

These acts replace status reporting and management reviews with a much more powerful, collaborative, vivid, and authentic project picture.

3. Share bad and good news with the team.

Changes can happen in many aspects, including the market, user priorities, technology, and regulations, having an adverse impact on the valued features that the team is currently working on. As product owner, share even your doubts with the team. If the team realizes in the future that you let them continue working on features despite their being irrelevant, that can be a highly demotivating factor.

4. Partner with the team, don't subcontract it.

I always wondered how the product owner could create stories, let alone technical stories. This goes back to the transparency of the product owner: to be upfront that he does not know the requirements. Accordingly, the team is empowered to come up with what is required to deliver the valued features. This transparent behavior provides "permission" for the team to become a partner in product success instead of limiting its responsibility to that of a subcontractor, merely delivering what the product owner wants.

5. Develop interest in the team's technical activities.

As product owner, your involvement in the team's actual development activities is a good way to have the team transparent to you. This can allow you recognize team characteristics, weaknesses, and limitations that cannot be shared comfortably. These insights can help you understand risks related to the release schedule and shipping date. Also, you can become more informed before communicating commitment to management. The product backlog you own should be aligned to the team's characteristics, not just be a dump of product features. A product owner who disassociates himself from the team is in fact laying the groundwork to become unreachable if the team were to fail.

6. Acknowledge your limitations.

The product owner role has no direct equivalent. Rather, it incorporates aspects of product management, project management, business analysis, and leadership. As product owner, you should appreciate the involvement of your role. Take responsibility but ensure that there others who can fill in for you in addressing aspects that you are unfamiliar with. An example: Have the business analyst write detailed stories and acceptance criteria.

To summarize, without transparency we may not succeed in implementing Agile — and even if we can, the project can revert to command and control. Transparency implementation starts by leadership as represented by the product owner. This article recommends six actions, mainly owned by the product owner, for objective implementation of transparency.

References

Galen, Robert. Scrum Product Ownership: Balancing Value from the Inside Out. RGCG, LLC. 2009.
Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. Addison-Wesley Professional. 2010.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.