Taking an Active Approach to Transparency in an Agile Team

One of the driving philosophies of an agile approach is the idea of transparency. Agile teams strive to create transparency both with their stakeholders and within their teams. However, achieving the level of transparency necessary for an agile team to be successful is often more difficult than many teams believe.

Often times, a team will decorate their team space with burndown charts, burn up charts, and the like that convey the progress they are making to their stakeholders every day. And if that same team begins to fall behind then they’ll faithfully update those charts accordingly to ensure they accurately reflect their progress. Unfortunately though, simply updating their charts often is not enough.

However, the shortfalls of this approach are often not evident until the next Sprint Review when the team is frustrated that their stakeholders appear blindsided that the team’s progress was not what they expected. Of course we didn’t hit our velocity, they yell, it was right there on the burndown chart all along!

Taking Responsibility for Transparency

As an agile team, you have a responsibility to act in a transparent way, but doing so means more than simply hanging a few charts in view of your stakeholders and calling it a day.

In order to achieve true transparency with your stakeholders you must work to actively foster that transparency with everyone involved. This means regularly engaging your stakeholders in conversation, showing them the locations where you’re currently surfacing information, and teaching them to how to decipher and glean the information they need from each location.

For example, if your team begins to fall behind their forecasted velocity for the Sprint simply posting a burndown chart on the wall and assuming that your stakeholders have been informed isn’t a successful strategy. Instead, seek out your key stakeholders and call their attention to your burndown chart, ensuring that they understand what it conveys and what it means for your project. You can then use this opportunity for a deeper conversation of how your team and stakeholders can work together to still achieve your overarching goal for the Sprint, such as by removing some stories from the Sprint plan that don’t contribute to that goal or by reducing the scope of the remaining stories.

As another example, allowing your Sprint Reviews to devolve into a passive demo where your team simply demonstrates the work they’ve completed to a panel of disinterested and disengaged stakeholders is unlikely to garner the feedback you need to move your team forward. Instead, make an effort to ensure that the right stakeholders are in the room to decide whether your team is truly on the right track, and then work to force a productive conversation to identify what needs to change in the next Sprint in the event that they aren’t.

Achieving True Transparency

While simply working in a transparent manner in your day-to-day activities will garner a passive level of transparency, to truly achieve the benefits of agility you must actively promote transparency through every facet of your team’s process.

This includes actively engaging your stakeholders in your team’s delivery process, teaching them how to get the information they need from your team’s information radiators, and bringing them into fold so that everyone is equally vested in a successful outcome for your project. In fact, teaching your stakeholders to accurately decipher your team’s information radiators may even result in those stakeholders spotting patterns and or insights that your own team may have missed, deepening the value that those relationships bring to your team.

If you want to truly create a level of transparency between your team and stakeholders then simply hanging a burndown chart on the wall often isn’t enough. To achieve true transparency, you need to engage your stakeholders every step of the way and ensure that they are actively aware and engaged throughout your project.

Previous
Previous

Dividing and Conquering: Finding the Right Size for Your Team

Next
Next

Should A Manager Be A Scrum Master?