Background
A couple years back I started work as a high level engineer at company that had recently adopted an agile and iterative approach. It was some form of scrum – everybody seems to have their own version. In any event the scrums were working at a team level – as scrum is most focused at this level. A team was 3-4 engineers 1-2 QA people and 1-2 product managers. We had standups Tuesdays and Thursdays, and the members of each team knew what was happening within the teams.
The Problem
The problem with our setup was that teams did not know what other teams were doing. There was a scrum of scrums that occurred with the same frequency but at that level there were too many people to really get a sense of what was happening. We had about 30 engineers and 8-10 different projects going on at any given time. The scrum of scrums was roughly a status meeting for the Director of Engineering. However it was not useful. The reason was that with that many people in the room 8-10, all of whom do not know what the other people are doing (they are not working with each other the way that the individual scrum teams did), there was little opportunity for understanding and course correction.
At the same time we were using a tool called Target Process to manage our agile and iterative process. It allowed us to create products, features, stories and tasks (descending level of scope) and then assign them to teams and monitor the progress. In addition it could produce reports describing what the state of the stories were and what our task-hour burn down rate was. This was great stuff, but it was buried in the application and management was not using it.
The Solution
My solution was to print out a set of the following graphs and lists, for each team, and post it on the common hallway that the entire engineering team used:
Printed Reports for each Scrum Team
- List of Stories, with states of completion, for the release
- List of Stories, with states of completion, for a given iteration
- Graph of hours burn-down rate for the team for a given iteration
- Graph of story burn-down rate for the team for the release
Transparency
These sets of printed reports which were updated twice a week before the team scrums (sorry trees) allowed someone to walk down the hallway and see what the status of each team was. More importantly, it allowed quick identification of which teams were struggling to complete their work. This allowed the Director of Engineering to get insight into what was happening at a meta-level, and could then drill down further with the scrum master of the individual team.
It also informed the teams themselves of how far behind they were. In the absence of the displayed delays the teams could go several iterations before their slowness was identified. Now that it could quickly be seen, there was a distinct desire to either not fall behind at all, or to raise structural issues more quickly. Certainly some engineers, typically those who had established a cynical attitude toward their work or work products, were resistant to the heightened level of scrutiny that came with the displays.
In Your Face
It is important to note that all of the information that was displayed on the wall was completely available in electronic form (thus saving trees). However, in practice those reports were not run and were not viewed. The in-your-face aspect of public display was the critical missing factor in leveraging the power of the agile and iterative management software.
I can’t say the project status wall was loved by all, but I can say that it did what it set out to do, which was to create more transparency into team status. It was kept for as long as I was there.