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:

  1. The task title
  2. The person assigned to the task
  3. The amount of remaining effort to complete the task
  4. 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

comments powered by Disqus


  • Clustering Non-Numeric Data Using C#

    Clustering non-numeric -- or categorial -- data is surprisingly difficult, but it's explained here by resident data scientist Dr. James McCaffrey of Microsoft Research, who provides all the code you need for a complete system using an algorithm based on a metric called category utility (CU), a measure how much information you gain by clustering.

  • So What's Up with Microsoft's (and Everyone Else's) Love of Rust?

    Microsoft already stewards several popular programming languages -- C#, TypeScript, F# -- so what's up with its love of Rust, along with the rest of the world?

  • C# Steps Up Programming Language Popularity Ladder

    Microsoft's C# programming language climbed a year-over-year notch on the TIOBE Index, which measures popularity among developers.

  • VS Code Java Tool Updates Debugging, Refactoring

    The monthly update to the tooling that boosts Java development in the open source, cross-platform Visual Studio Code editor highlights debugging, refactoring and more.

  • Microsoft Plugs Away at Blazor for Mobile in Preview 3

    Microsoft is furthering its work to target mobile app development with Blazor, the ASP.NET Core offering that originally was developed to allow for C#-based web development instead of JavaScript through the use of WebAssembly for the client side.

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events