I’d like to tell you a story about how we manage tasks in my team…
Once upon a time (about a year and a half ago) I’ve started working in a new place. Since I’ve came from a company with very strong agile practice I wanted my new work place to be as agile as possible – and one of my first “missions” was to improve the way the team’s task tracking.
Task Board #1 – Sticky notes
I’ve convinced my manager to start using a “task board” which consisted of using sticky notes and one of the walls of the office. And as simple of that we had all of the team’s tasks in a simple, easy to read (and understand) display for the entire world to see. And the improvement was felt immediately. The team members could tell what are the priorities and their current and future work. And the team’s manager was happy because now it was clear what each of us were doing.
Some of the team liked the idea, some not so much… And over time it was clear who was updating his current progress and who’s tasks didn’t change on the board for the last two iterations.
Task board #2 – Distributed
I’ve done a quick check with the team to understand how we can improve the task board and one of the problem raised was that because the tasks were displayed on a wall that was less accessible to some of the team members they didn’t update their tasks as often as possible – instead of moving tasks from To-do to In progress and then Done they waited until several such “updates” were accumulated (or until they happen to pass by the wall) before moving the tasks on the board.
And so we’ve found a solution – each developer had his own task board right above his head. I know it’s not SCRUM but it worked for us.
And so we’ve continued working this way for a few months until another challenge presented itself…
From time to time a developer had to work on site which meant that he was out of the office and could not update his backlog another problem was that as the project progressed more and more top managers needed to know what the team is doing and whether or not we were reaching our goals. At about the same time the team has grown and we now were filling two rooms and looking to hire more developers and my manager had problems tracking the team’s goals.
Task board #3 – Excel spreadsheet in shared folder
Building upon past experience my manager came up with a simple Excel spreadsheet that was placed in a network share and that the team could update. The advantage was that Excel files can be copied, sent on email and shown at meetings a fact that helped explain what we were doing and how much time it would take to project managers, product owners and top management of our company.
We worked with the excel for a few iterations and it worked for us – we could move tasks between the team and everyone knew what everyone did. But the more we’ve used it the more it became clear that this “Excel task board” was holding us back. Since only one user is allowed to update the file – whenever two developers needed to update their progress it caused us grief – especially before start/end of iteration when all of us needed to update the file at once. Another problem was that once an iteration ended another file/book was created and the old iteration data was “archived” never to be seen again.
We knew we needed a better solution and we’ve found one just under our nose – TFS. We were already using TFS for source control and continuous integration (CI) server so why not use it to track our tasks as well.
Task board #4 – TFS + Work Item Manager
I was able to update the TFS Task using Visual Studio and we had a simple SCRUM workflow:
Using this task we were now able to use TFS as our backlog and task board. Another added bonus is that using Telerik’s TFS Work Item Manager we were able to see the old task board we were used to see on the office wall:
Now we had it all:
System that we can update easily – from the comfort of our Visual Studio
Easy to understand visualization
Statistics on iteration, remaining tasks and team progress
And this is how we work today.
The lesson of this tale is that you should not be afraid to change. Just because we were using a tool that worked for us in the past didn’t mean that that tool cannot be changed if a better alternative is available, or if he required functionality changes. Because being agile is embracing change not just in the product you’re delivering but also the way you deliver it.
One final note
Using a task board is a simple practice and yet many teams just don’t track their tasks properly. Showing my team to use a task board is only one of the ways I’ve used to make them more “Agile”. If you’d want to learn more about how to make your team more agile or looking for tips and tricks that I found useful – I’ll be talking about it on my session at the Agile Practitioners Conference at the end of this month.