Many of us have been solo developers for many years. I personally started working on customer projects as a one-man show. I was in charge of talking to the customer, gathering requirements, giving estimates, developing, testing and delivering the project.
My "guesstimation" process consisted of taking the requirements, breaking them down into tasks that I could somehow measure in terms of hours. This worked well for me. As time passed I got better at my guesstimates until they actually turned into estimates. I would end up with a task list like so (invented values):
| Task | Estimate (Hours) |
| Customer Management | 50 |
| Invoice Management | 100 |
| Reports | 30 |
| Total | 180 (4.5 weeks) |
Once I had the total number of weeks, I would then commit to doing x tasks per week, based on difficulty, priority, etc. At this point, the hours would completely fall out of the picture. I didn't care how many hours I had assigned to Customer Management. All I cared about was that I needed to get it done by a certain date (iteration).
As I would work on tasks, I wouldn't keep track of the number of hours I had worked on them. I would keep in my mind a global vision of how the whole process for that particular week was going and based on my progress I would know if I was going to reach my objective or not (burndown). If I was late, I would normally update my list of pending tasks and try and re-plan things for the next run. But again, I wouldn't keep track of how many hours I had worked on a particular task.
Does this sound familiar? I'm sure many of you who have worked solo have done something along these lines. I wasn't doing anything special.
So what has all this got to do with Scrum? In Scrum, the team works together to come up with a list of tasks they can cover in an iteration and get to work. They monitor their overall progress using the sprint burndown chart to make sure they'll reach their objectives. Tasks are marked as done when they are done. Team members don't have to specify how long it took them to get the job done, just like myself, as a solo developer never (not even once) wrote down how many hours it took me to work on a specific task. Does this mean that tracking the number of hours worked on a task should never be done? No. There are reasons for doing so at certain stages, but that's a topic for another blog post.
So if you think about it, all scrum is, is a bunch of solo developers working on a team. It seems simple, yet it isn't. Scrum isn't always successful. There are many reasons for it to fail, but nearly all of them stem from the same root: confidence. As a solo developer, I am not only the producer, but the stakeholder. If I don't do my job, my customer won't pay and it all goes to hell. I need to rely on myself. I need to have confidence in myself.
However, when working on a team, it's much harder to build up the confidence. Each team member not only has to have confidence in himself, but to have confidence with all members of the team and to be able to rely on them. There needs to be an understanding that it's no longer about individuality but about a team. If one fails, the team can fail. If the team succeeds, everyone succeeds.
There are many other factors that can contribute to a successful team and project and I'll be covering some of the things that I think are vital in later posts, but the first step is to build up the confidence in the team.