The Mailowl Scrolls

Hello again, and let me add to the numerous voices in wishing you a happy 2007. I know January is nearly half over and maybe you feel I should have done this earlier; but with a refreshing holiday, the excitement of starting on a new project with work and, more importantly, a buggy pc I haven’t been able to bring myself before the word processor.

So I’m going to skip the seasonal formalities and dive straight into a topic of interest, things to be careful of in the Scrum agile process.

The team I’m with has started using Scrum process fairly recently (after being successfully used in another team) and we’ve got Scrum for Team System running our project (you can find out more about the actual implementation of VSTS on Willy-Peter’s and Jean-Pierre’s blogs).

I would say the development team is fairly excited about it and the meetings are short enough not to impede on anyone’s day. We have a whiteboard where developers track their tasks for the current sprint and we have a burn-down chart pinned up to see the overall progress of the project

But any process methodology will fail if its principles are not followed and the methodology as a whole is not accepted responsibly by all parties. Managers can not dump a methodology on developers and leave it for the developers to manage themselves; and developers must make practical use of any methodology to plan their workload and not see it as “satisfying report-hungry managers”.

That said, I want to point out 3 things to look out for when you’re in a Scrum session.

1. Scope of tasks
Only assign tasks that are relevant to the current sprint; don’t write down all the tasks you’ve got to do for the foreseeable future or for the whole module. Also, don’t add tasks which you know you can not finish by the end of the sprint; one of the aspects of sprints is for managers to see where work is starting to slip and they should step in to re-assign tasks to developers with less work.

2. Granularity of tasks
Don’t put down a task that encompasses every possible item you have to do for this sprint and every other sprint until the end of the project. Writing “Build Backend” or “Manage Database” defeats the purpose of sprints which is to compartmentalize completed sections of work which can be delivered or tested or handed to another team. This also swings the other way and don’t have lots of little tasks that need to be micro-managed and depend on each to be completed.

3. Completing tasks
I think it’s a software development faux pas that just as any task is started people are already saying “I’m nearly finished, I just need to” right up until the last minute of the deadline. Be definite about the progress of a task; and rather keep it “not started” or “in progress” than marking it Complete and then having it appear embarrassingly in the next sprint.

Here are some questions you can ask if your sprints aren’t succeeding.

• If you seem to have lots of tasks for a sprint, are they applicable right now or can some be left for the next sprint and be removed?
• If you still have lots of tasks check if some of them aren’t dependant on others being completed first. You might have a granularity problem.
• If you only have one task for a sprint, could that be broken up into a handful of tasks? It’s more satisfying to have a handful of tasks and look busy and avoids a single big task being carried over to the next sprint.

To end off, everyone must take the meaning of tasks and sprint seriously; especially developers who manage their own tasks. Poorly managed tasks will cancel any benefit you hope to achieve from implementing the Scrum process.