Recently at work, I have been given a very thoughtful insight on why Scrum can be a better methodology than the traditional and popular Waterfall project management style.
See, the projects that I focus delivery on can’t necessarily have a fixed estimate, date and deadline – precisely what the Waterfall methodology expects of you. We work in an agile development environment, and this method clearly does not show or prove any visibility of the work being done on the production floor. I implemented the Waterfall style for a few weeks at work, and with all honesty while this is a popular method, it can fail drastically – and has failed in my opinion. Yes, I am admitting that I failed to use the right technique at work – but hey, you can only learn from reviewing and getting feedback of your own doings.
To give you a bit of background about the Waterfall style – you are required to have all your tasks broken down into sub tasks, have an good estimate (almost close to accurate), show all your dependencies and plan it out (I used MS Project). You end up with something like this:
Now as you can see in the above image, I have no room for being able to shift around tasks if say Task 4 (assume it was testing) requires back and forth bug fixing past the expected deadlines. A developer can say they need 4 days to develop, and the tester could say that he needs 2 days to test. But have I failed in assuming 2 days of bug fixing, or am I shooting myself in the foot of wasting 2 days of a developer’s time if there are no bugs to fix at all? It’s a risk I take. But when you have various other projects that need immediate attention, you need to ensure you make efficient use of your capacity, and I would therefore immediately allocate the developer to the next task or project.
More importantly, using this method can make you feel like you have planned too hard and that nothing could go wrong. On the contrary, you don’t get to see the real results of your planning until the closing end of the project. Should there be scope changes, well that’s your plan back to the drawing board. If your developer turns up sick – you’ve potentially missed your deadline. If you mismanage your capacity, you’ll hear the voices of your manager in your head.
From a cultural perspective, this method does not allow your developers freedom in the choice of task for that day – and that could turn out very frustrating for them. Hence there needs to be a change, a change that is hard to adopt at many work places after a process already exists. But luckily for us most of our team members have worked in a Scrum and agile environment and are quite adaptable to it.
So what are we doing, and how are we going to do it.
In my previous blog, I wrote a brief summary of what Scrum is. To kick of the process, we are going to take a fairly small project – one that has a 2 week timeframe. Hence we have a 2 week sprint and monitor how accurate our estimates of miscellaneous tasks are. By these tasks I mean, estimating time for our bug fix days, miscellaneous production issues, staff leave and so on. This will let me know what our maximum capacity per developer is per 2 weeks. We then break down our tasks to no more than 3 day estimates. So if something takes 6 days, try and break down to two tasks if possible. You then develop a spreadsheet to show each task vertically and a list of burn down days horizontally. 2 weeks equals 10 working days. If say your capacity for each developer is 60 hours in two weeks, you are responsible to therefore assign them tasks within that limit. You don’t want to shoot yourself in the foot by giving them more than they can chew.
On day 1 (i.e. day 10 burn down), the developer will update the remaining time left on their assigned task(s). NOTE – the remaining time left on the task NOT how much they have worked on the task.
Baring in mind, if the estimate for a task originally said 24 hours it could potentially rise to 28 hours if the developer realises that the work required to be done is more than originally estimated.
As you can already realise, the developer chooses their own priorities and are required to deliver the assigned set of tasks by 2 weeks. How they do it is their call – as long as it gets done. Flexibility and satisfaction achieved! 
As the burn down goes by, the task’s remaining hours should slowly diminish. At the end of the two weeks you can see how each developer performed and how the project performed over all. The graph will show the total remaining hours for each developer. If the graph is smoothly declining to the last burn down day, they have then performed well. If the graph stands straight the developer has either hit a roadblock or hasn’t made any progress on their assigned work. If you see this pattern for two days – you can quickly raise alarm bells and see what’s going wrong. Additionally during the daily scrum meetings you can see progress as each developer states what they did the day before, and what they are planning to do today.
As long as the developer’s burn down is kept close below the ideal burn down line, things are assume to be running smoothly. There is also an ideal burn down line – which well speaks for itself to show what should ideally happening to ensure smooth production and delivery of your tasks by the end of the sprint. Note: a project can have several sprints but you are seeing delivery at the end of each. Based on the graph patterns you get an understanding of you developer’s development behaviour and its helps you improve in your next sprint planning.
Take a look at the graph below:
In this example, the developer made no progress for 3 days. Road blocked or not progressing? That’s something you can question. Based on this, you can either remove the task from this sprint, bringing their task force close under the ideal line and letting them progress on for the remainder of the sprint. Additionally you can see if the hours for your miscellaneous tasks are appropriate budgeted or not by examining if the assumed capacity (in this instance 60 hours) was enough to both satisfy your sprint tasks delivery as well as assist in production issues, bugs or if they took leave.
It’s a long read, but I hope you’ve enjoyed the theory of it. Now time to put it in practice!
Recent Comments