The Road to an Agile Project – Visualize!

Hello and welcome back! In this series of posts I am trying to give other teams of developers out there some path to embracing agile methodologies, such as Scrum. Previously, in my Prequel post, I described how you could start doing regular standup meetings in any type of project to increase your teams awareness about each member’s work.

Assuming your team has now incorporated standup meetings, preferably on a daily basis, it is time to take the next step. Agile methodologies generally rely on a rather simple notice: Visualized Management! Now don’t get scared, the word ‘Management’ here does not mean you need another manager. When done right, this visualization can eliminate the need for a manager. Now doesn’t that sound sweet? :)

Probably the best known example of this visual management is the Scrum Board, or Activity Board, or ToDo Board. However you call it, it’s a big board containing lot’s of post-its all describing work. Some of this work is yet to be done, some of it is in progress and hopefully, some of it is already done. What status a particular piece of work is in should be apparent from its location on the board.

Most boards contain three columns: To Do, In Progress and Done. These columns are however not mandatory, you can make any set of columns you like. You could for example also create columns for each expertise in your team, like To Do, In Design, In Development, In Test, Done. The possibilities are literally limitless, all you need to do is find a set of columns that work for your team. (And don’t be afraid to modify it if you are missing something, or feel a column is not required).

You could start by asking your team members to write down what task they are working on right now and put all those post-its in an In Progress-column. Ask them to move the post-it to the Done-column when they complete the task and then write a new note for the next task. The next step would be for people to write things they know still need to be done, or things which are discovered along the way down and put them in a To Do-column. Slowly but surely, you will begin to see progress!

If you are already working in sprint-like increments, you can cleanup all the Done work at the end of a sprint and (re)populate the board with work at the beginning of a sprint. If you have not yet incorporated such increments in your work style, then you could make sure a certain minimum amount of work is on the board. Don’t put an entire project’s worth of work on the board or you might risk your team members feeling overwhelmed.

Why is this important?

Why does this help you be more agile? For one thing, it helps during the daily standup meeting since you can now talk about the things that are on the board. It helps people remember what they were doing and hopefully takes away the number of “let’s see, what did I do yesterday?”-questions during a standup :).

It also provides a very visible way to demonstrate the progress of the project. Anyone interested in the progress of the project can simply walk up to the board and see what is currently being worked on. Ideally this should stop management from continuously asking your developers what the status of the project is. If they still do, simply explain the board to them and refer them to it. Let your developers do what they do best: write code.

A very nice extra piece of visual management would be to create a (burndown) chart which displays the rate at which tasks are being performed. We all know how much management loves to look at charts, but with a burndown chart, they might need require some ‘training’. You see, management is used to the paradigm that an upward trend is good and a downward trend is bad. On a burndown chart we display a line of work that still has to be done. Usually this starts out at some arbitrary number of tasks and goes down over time as work is completed. Make sure management understands this 😉

If you are looking for some more pointers on creating your own board, check out some of these links:

Try it sometime. Just pu

Posted in Agile and tagged , .