Transparency as an “Inclusive Force”
Visibility alone simply provides data. One can still be disengaged or a back-seat driver with data. However, the agile mindset couples visibility with collaboration and engagement. Stakeholders are encouraged--no almost required--to get in the game and become an active part of the team and participating in all aspects of the project.
Standing on the sidelines is no longer acceptable. Was it ever? Not only do you need to be engaged, but you need to be a contributing force within the context of the team -- showing your worth and demonstrating value. A good example of that is how you interpret events within the project and suggest alternatives to still meet the project's goals.
I'll give you a quick example. I find that stakeholders often don't properly consider the challenge of technical complexity and level of difficulty when requesting and prioritizing product features. They sort of take a simplistic and naive view -- considering every feature as being created equal. If developers break out into a cold sweat or turn pale when discussing certain features, they discount that as a lack of confidence or some sort of conservative response.
I would argue that they should instead begin to understand more of the dynamics of their product development environment by considering all aspects of what they're asking for when requesting work of their teams. For example, they should:
- Understand what's truly hard within their systems versus what's straightforward. Realizing that work needs to balance across these dimensions for effective planning and risk management. Of course, challenge and difficulty needs to be front loaded. However, it needs to be sensible as well.
- Understand the capabilities and capacity of their team across all dimensions--development, testing, documentation, and deployment -- so that when requests are made, they're actually feasible. Understand their teams strengths AND weakness, then align work accordingly.
- Truly understand your business needs, from a context of minimalist, high impact, high need features. We need to put the days of asking for features simply to fill in a marketing sheet behind us. Agile teams strongly focus on removing "gold plating" at every level of the project. Think of Pareto and only look for the critical 20%!
- Understand that software is hard and excellent solutions emerge from trial and discovery; therefore, decisions need to be informed, multi-faceted, and realistic. You need to allow the team time for emerging understanding of system architecture and for innovation -- flow time and slack time are critical in measuring this.
- Understand that you need to learn to listen and trust your teams. Either that or get another team, but to sit in the middle and push or complain against what the data is showing you is not acceptable.
Transparency is the facilitative tool that allows the agile stakeholder and customer to achieve this state of engagement. It creates a collaborative partnership between them and the team where the teams' realistic capability to produce products is balanced against the needs of the business. Instead of pretending that this is more capacity and insisting for "everything," visibility into reality is an incredibly powerful force for today's software managers and project stakeholders.
Previous Post:
Transparency as a “Leveling Force”
