Delivering Agile Projects on Time
By Ray Claridge
As a tester in the past I've worked on many large waterfall based projects. The one thing they've all had in common was that development overran and approx 70% of them delivered late!
You see, waterfall projects have requirements pretty much nailed down before development starts. You do get some scope creep, but the biggest failure is: understanding these requirements, estimating effort and taking test into account.
So what about agile I hear you ask?
With estimating at the beginning of each sprint and testing incorporated within development, you'd expect delivering projects late to be a thing of the past - right? wrong!
In agile you have a product backlog that's similar to a requirements spec (albeit high level). However, unless each requirement/story is prioritised correctly, the project becomes a never ending moving target and too often you lose focus developing functionality that has little business value. Before you know it, you've overrun the project.
Now I'm no project manager, but I do believe you should follow some simple rules (in no particular order):-
1. Before project development kicks off, ensure your environments are set up. If you don't, trust me this will come back and bite you!
2. Do not under estimate non functional tasks.
3. Develop the bear minimum in order for you to release. (You can always develop the 'nice to have' stories later if you have time).
4. Encourage the product owner(s) to put a business value on each story.
5. Don't let the product owner get carried away with features that are complicated to develop. Tell them so, and ensure you suggest a quicker simpler alternative solution.
6. If a project is over running, re-prioritize the product backlog and try to downgrade some stories.
Following these rules will help to keep your project on track.
Ray
I've been in some discussions surrounding 1 and 2 and the point has come up that these are part of the development effort (i.e.: 1 would not be done if there was not development going on) and that this effort be estimated same as a functional requirement: but they are not stories.
My issue is, as a PM, I'm not going to know the full list of tasks required for, say, setting up an environment, pushing to staging, merging branches, pushing to production/release code base, etc. and these are not stories. So how do they fit in and how are they estimated within the same process as functionality?