Being Agile When The Business Isn’t – Transparency

In the last two posts, ‘Being Agile When The Business Isn’t – Requirements‘, and ‘Being Agile When The Business Isn’t – Team‘, I talked about how to be more Agile in an environment where the business is strictly Waterfall. I’d like to continue this theme with some ideas and practices to make the teams more ‘transparent’.

Inspect, Adapt, & Transparency

Most will recognize Inspect, Adapt, & Transparency as the three pillars of Scrum but they’re ideas that even the most Waterfall of businesses can use and take advantage of. These three pillars are the core to continuous improvement, building what customers need to solve their problems, and helping bring the greatest valued work to the forefront. I’ll focus on transparency as I believe once you have transparency, inspection and adaptation will follow naturally.

Perhaps the big difference between Agile Vs traditional project management is how these three items are acted upon. When I was doing big Waterfall projects our alleged transparency came from the project’s communication plan. This communication plan defined the reports the project team was responsible for generating. At or near the end of the project, we wrote project closure reports which often included lessons learned. While writing the closure report, we were being formally transparent but only after everything was done. The real problem with the closure report was the timeliness of it. Because this is traditionally done at the end of the project, nothing learned here can help the just completed project. We also suffered from fading memories. We remembered the specific events but often needed to speculate and debate over the causes. Interestingly, we also seemed to forget these lessons for the next project or determine the next project is different enough so the lessons weren’t considered applicable. I’m not suggesting nothing was learned but any learnings carried forward tended to be the exception.

The result is some learning is done but the changes haven’t been trialed or proven to be effective in solving whatever the problem was. To improve requires openness and transparency so you can inspect what has happened and adapt to new and better ways throughout the project not just at the end. To maximize the value of improving, the project team needs to be continuously inspecting outcomes and results including any new ways of doing things. Building in transparency from the start will help.

Transparency

Transparency is arguably the first step for improvement. Nothing will help a business improve better than seeing undeniable evidence that some work practices, processes, and communications are less than optimal or just plain bad. In the Waterfall environment, the project plan includes what practices and processes the teams will use and the order they’ll use them. Most project plans also have a communication section where and how the various project statuses and metrics are reported. However, it’s only an illusion that transparency exists by executing a communications plan. The reason is, communication plans dictate specific content and intervals, usually within categorizes like any of the following:

  • Current project status
  • Current risk assessment
  • Resourcing status
  • Requirements management status
  • Stakeholder management status
  • Change management status

This doesn’t provide any insights or linkages to bigger or widespread problems. There’s also the problem that the reporting is done by the project manager. This can lead to information being filtered and potentially skewed due to conflict of interest. Project managers are generally held accountable for the project plan which means they’re accountable for perceived progress or the perceived lack  of progress. And finally, after a while, the project manager is most often simple ticking the box on his or her reporting requirements.

Daily standup & transparency

Scrum Trainer Charles Bradley wrote in his article, “The Tao of Scrum – Transparency“, “the best transparency leads to the best collaboration loops”. To maximize the value of collaborative feedback loops requires transparency and to me, transparency implies anyone can quickly gauge what’s happening in a project with a minimum of effort. Although you might be stuck with an old-fashioned communication plan, there’s an easy ceremony you can implement with your Waterfall team that gives extra clarity to what’s happening on the project: a daily standup. Each day the team talks about how their plans for the previous 24 hours went and what their plans are for the next 24 hours. It also provides an opportunity for others with their own unique perspectives to make observations and comment.

In my Waterfall past, as the project was approaching the final stages of test, we had all the project managers, line managers, and the program office people sit together daily to talk about specific tasks the teams were doing and when we thought they’d be done. Although this worked quite well for the management team, the nuance of individual planning was lost. Had there been a team standup, the confidence or uncertainty was more likely to come through. As it was, what was reported to management was an interpretation of plans and status.

In a Waterfall environment, the full project team might be large since the team is built from specialist who usually don’t take on tasks outside their specialty. This can mean the daily standup is large if everyone goes so careful monitoring is essential. The daily standup must remain valuable and true planning must occur otherwise there’s no point to it. In Agile, one valuable component of the daily standup is the collaborative nature of getting the most important work done first. In Waterfall, the project manager and product manager might need to be a little flexible in their detailed project plans to allow the collaborative nature of the implementation team to emerge. Better still is for the project plan be aligned with getting functionality done in order of importance rather than based on components and skills of the team.

Plans & transparency

Another aspect of transparency will be the visibility of the plans. If the project is using MS Project or Jira for Agile teams, it is a huge mistake to think this by itself constitutes transparency. Both these tools track progress when properly maintained but in both cases, people often don’t take the extra steps necessary to open a file or log on to Jira or even learn how to use the tool. The real problem isn’t progress wasn’t tracked, it is, but the real problem is the difficulty of getting to this tracking data and properly interpreting it. These tools have their advantages but ease of use is not always one of them. It’s not that these managers and program office people are lazy but rather their time’s at a premium. Visualizing the project and sprint status on a wall is easy. Bits of sticky paper with notes, in columns is easy. I have used a big wall as a Gantt chart or User Story board to great success. It really doesn’t matter if you’re doing Waterfall or Agile, the advantages of this high visibility is the same: huge.

If your team and stakeholders are global then it’s a wise idea to set up a camera on the planning board. I had used a camera while we did standups to allow global stakeholders to see & hear what was going on. I had a second camera on our ‘story board’ 24/7. This was intended to add more transparency and to give our global stakeholders a bigger slice of the picture, allowing for more feedback and collaboration.

Transparency is a conscious effort

Agile isn’t immune to poor transparency and communications. As Scrum Master, I’ve been cornered by the product owner/manager and asked what the ‘real’ state of progress was in the sprint. Two things needed to happen: the product owner needed to attend the daily standup and the team (with some advice from the Scrum Master) needed to better present state sprint progress. In Waterfall, the project manager has their hands full too. While Agile implies the implementation team is involved and responsible for managing expectations and communicating value completed, Waterfall usually relies on the project manager to do these. It’s up to the project manager to move beyond the project plan and establish a collaborative atmosphere where visibility and transparency become natural within the project team.

Transparency can be scary as it will expose people, their work practices, and their outcomes to all. It’s not the natural state for developers who learned their craft in a Waterfall environment. The first time I had transformed a Waterfall team into a Scrum team, one of the team members told me that they were completely stressed out by the high visibility of their work. In his case, a technical decision had proved wrong in a most open sort of way. In the past, management would probably not know that a technical glitch had happened but Agile made it visible. In hindsight, the team member realized the focus was to identify and correct a technical decision quickly and not to allocate blame or ridicule, (he was unconvinced of this in the first days). Transparency became a tool to do better and improve but not without some pain on the journey. Making previously hidden work habits visible will be stressful for some but this can be countered by avoiding the culture of blame and ridicule.

Summary

By using transparency as an aid to see what’s working well and what can be improved, the opportunities for improvement are more likely to be seen. Transparency has two key accomplices: daily standups and the wall project planner. Both these can be used in Waterfall environments without too much effort beyond simply doing it. Having the implementation team being transparent and talking directly to their plans each day is a key element of Inspection & Adaptation. This daily transparency reduces the risk of going off on a tangent as illustrated in the earlier story about an unsuccessful technical decision.

Transparency also extends beyond traditional tracking tools. Although these tools help track and document progress, it requires both effort and training to use these to their full potential. Training all stakeholders and customers with these tools is hard and may be impractical. Using a simple system of sticky notes and a big wall can convey the same information in a visual way that transcends most communication roadblocks. If there’s no wall, then use a big whiteboard. No whiteboard, then use the windows. You can even put a camera in front to broadcast the planning board across the internet if necessary.

Author: Robert Boyd

I'm a CSP (Certified Scrum Professional), CSM (Certified ScrumMaster), and CSPO (Certified Scrum Product Owner). For 30 years I've been streamlining processes and systems. I've introduced agile methodologies to software and product management departments, resulting in a 300 percent increase in feature deliveries.

Leave a Reply

Your email address will not be published.