Agile Advisor
Keeping Your Agile Team Safe
Agile processes should encourage your developers to work better -- not be looking over their shoulders.
I had an interesting email exchange this past week with a Visual Studio Team Foundation Server (TFS) customer that I wanted to share more broadly. My team here at Microsoft builds tools aimed at making it easier for teams to manage their work. In the current release, Visual Studio 11, we've put an emphasis on making sure teams adopting agile practices find real value using our tools.
It's not always an easy job, especially when you consider the first statement in the agile manifesto: "We have come to value… individuals and interactions over processes and tools." In some ways, we're building tools for teams that don't want them. I'm overstating this a bit, but hopefully you see where I'm going. There's a very fine line we have to make sure we're not crossing. If our tools are diminishing "individuals and interactions", we've failed.
This particular conversation centered on the new taskboard in Team Foundation Server 11. The taskboard itself is pretty straightforward: it shows backlog items the team has committed to completing in the current sprint along with a set of tasks (cards) representing the work to complete each item. See Figure 1.
[Click on image for larger view.] |
| Figure 1. The Team Foundation Server taskboard. |
Each task displays four pieces of information:
- The task title
- The person assigned to the task
- The amount of remaining effort to complete the task
- The state of the task
The idea is that the team uses the taskboard to drive their daily standup. Team members communicate their progress daily, and the team has an honest conversation about progress toward its commitment. The taskboard helps the team to visualize all their work. The goal is transparency, honesty and clear communication.
The customer in this situation submitted a request to change the taskboard and add two new bits of information. Specifically, the customer wanted the original estimate and amount of completed work added to each task card. The justification provided was that having this information on the taskboard would allow them to spot "bad estimates" quickly and easily.
This isn't the first time I've heard this request, and one that we've chosen not to act on before. I politely explained to the customer that we would not be adding the feature. I also pointed out my own thoughts on the feature itself. I'm of the opinion that adding this type of information would actually defeat the purpose of having a taskboard. Why? Because the taskboard is a tool for the team; it's designed to help the team meet its commitment. It's not a tool for management or stakeholders to hold the team accountable. It's a tool where telling the truth should be rewarded, not punished.
This was an example of a tool "crossing the line" described above. Displaying information that highlights bad estimates on the taskboard would do nothing to promote individuals and interactions. Instead, it would turn the taskboard into a "blame board". It would highlight negative behavior instead of positive behavior. As a team member, I'm much less inclined to be honest about how much work remains if I know that people are constantly measuring and advertising the accuracy of my estimates. Instead of reporting the truth, I'll revert to making sure my burndown and my estimates match every time, even if that means stretching the truth.
My point here is not to belittle the customer that asked for the feature. In fact, we had a great dialogue that resulted from the original ask. My point is to highlight how important it is to create a safe place for teams to do their work. If your team is tracking estimates and completed work, you can write queries to manage and track that data. But the taskboard needs to remain a safe place for the team, a place where honest conversations occur without consequences or side-effects.
About the Author
Aaron Bjork is a Principal Program Manager at Microsoft working on Agile experiences and tooling within Team Foundation Server (TFS). Prior to joining TFS in 2008, Bjork worked as a software engineer and development lead in Visual Studio. He is passionate about Application Lifecycle Management solutions and has a strong desire to see teams improve their software engineering practices. Follow Bjork on his blog at blogs.msdn.com/aaronbjork.