Why TFS Online Task board is Anti-Agile

I like Visual Studio, and I like a number of things about Visual Studio Online (VSO). However, there is one part of VSO that I think I very dangerous and can easily put your Agile project at risk. What is this terrible evil? Well I’m guessing you’ve read the title so it will be of no surprise when I say, the Scrum Work Item Task Board (see https://msdn.microsoft.com/en-us/Library/vs/alm/Work/scrum/task-board?f=255&MSPPError=-2147217396).

My experience of this task board is that it leads to a complete disintegration of the Agile practice. But it looks fine, how can such an innocent artefact lead to such problems? A number of Agile practices rely on a set of key overlapping points; 1. Transparency of the work 2. Collaboration and trust 3. Exiting with completed work. When you work on an Agile solution you will have a group of people with a set of specific skills, or at least wear the hat of a specific skill. Let’s assume we have a project owner, tester and developer. I firmly believe these are the minimum roles, even if you chose to only employ one person for all of them.

When you use a non-electronic task board you will, typically, go though a process that encourages collaboration. A note representing the ‘task’ will be placed on the board and those involved will discuss the issues around it. At first the team will agree what will be delivered and, crucially, how you prove that it has been successful. A common strategy here will be that at least the owner and test team will be responsibly for delivering an automated acceptance test for the task. The development team will be involved but perhaps not so hands-on, their main interest is to ensure the task is available for them work on. I.e. it is in the developers interest to track the progress of the owner/test team. Next the roles switch, the developers will implement the task to meet the acceptance criteria. The owner/test team play a lesser role but now they are interested in ensuring that the progress of the development is kept on track. Once development finish the owner/test team will then give the final yes/no on the result. Even without a Limited Work In Progress (WIP) strategy the team are always aware of the progress of the task and that it is their collective responsibility to collaboratively complete the task. Various process methods are used to help re-enforce this but the majority come down to a simple level of communication and, importantly, participation. So back to the topic, what is the problem with the VSO (Scrum) task board?

The first problem is that VSO wants you to separate out responsibility by creating a task per person. So rather than a task move through the team members hands, each person has their own task. Now when the team meet up each person has their own, pardon the overused term, story to tell. As their individual tasks progress it is an unfortunate human trait that the teams interest in individuals tasks wanes. Worse still, when a task completes in simply finishes and is really only of interest to that person. One task finishing does not trigger the start of another. What we have now is a system that purports to be agile but is really just a system crying out for a Gantt chart.  This is not VSOs problem per se. The task board is based, or bolted onto, old Team Foundation Server (TFS) non-agile templates. I.e. the agile processes, in this case Scrum, has be coerced onto a platform that doesn’t really support it. Happily the VSO team have working hard and have recently allowed more customisations that may offer a way out. Also this blog has been focused solely on VSOs Scrum process, you could choose Kanban instead. Whatever you choose, you should consider what are the human ramifications. Also try to keep the team, as a whole, focused on the progress of the work. It is everyone’s responsibility to deliver the work, that only ends when it is delivered. Ok, even that’s not strictly true, but lets keep those worms in the tin for now.

Be very careful of VSO Work Items, don’t be fooled into thinking you have an out-of-the-box agile process. Or just don’t use Scrum…

This entry was posted in Agile and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s