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 blogs.msdn.com/aaronbjork.

comments powered by Disqus

Featured

  • C# Slides in Usage Ranking of Programming Languages

    "The fact that C# lost three places in the ranking of language communities during the last three years is mostly explained by its slower growth compared to C/C++ and PHP."

  • Telerik UI for Blazor Updated

    Progress announced an update to its Telerik UI for Blazor components, targeting Microsoft's open source Blazor framework that lets C# coders create web apps without having to rely upon JavaScript.

  • Infragistics Unveils UI Components for Blazor

    Infragistics, specializing in third-party UI/UX controls and tools, unveiled a new offering targeting Blazor, Microsoft's red-hot open source framework that allows for C#-based web development instead of traditional mainstay JavaScript.

  • AWS Open Sources Tool for Porting .NET Framework Apps to .NET Core

    Leading cloud computing platform Amazon Web Services open sourced the it announced in July for helping users port old .NET Framework applications to the new .NET Core framework.

  • Uno Platform Ports Windows Calculator to Linux

    Uno Platform has ported the famed Windows Calculator, open sourced last year, to Linux as part of a continuing "proof point" effort to demonstrate the reach of what it describes as the sole UI offering available to target Windows, WebAssembly, iOS, macOS, Android and Linux with single-codebase applications coded in C# and XAML.

Upcoming Events