However:
There are a few things that make me nervous about the process, I have worked with it at Yahoo, and seen some the ways its original goals can become subverted.
1. It can become the ultimate micromanagement tool, some aspects of agile are a PM's wet dream, being able to capture and track exactly the number of hours each team member spends on each each task in a sprint, gives the PM a unique view on progress etc. But it can also become very time driven, with team members feeling pressure to wrap up a task quickly to stay inside the timebox. It can make your team feel like a row of battery hens if not managed sensibly.
I prefer not to assign tasks on a number of hours basis, rather on a complexity and resource basis, in reality the time element is only required to aid in the planning stage for sprint, to ensure they don't bite off more than they can chew. Instead we will assign tasks to Tiny, Small, Medium, Large and Huge timeboxes.
2. What is it with the obsession with statistics and graphs that most agile implementations seem to spawn?, if the process is consuming considerable time in itself producing statistics on a continuous basis, then it is not full-filling its aim. If we are spending more time on documenting the process and its progress than actually doing the work, then something is amiss, so for small teams with good internal communications, you should reduce the stats produced to the bare minimum.
A good ticketing/issue tracker is an absolute essential, and if configured right should produce all the reports that are needed without the need to generate any by hand.
Especially if the PM/SCRUMM master is themselves a productive team member producing work towards the sprint goals.
So i'm currently designing a bare bones, pared down, minimalist SCRUMM agile process for fav.or.it, one that hopefully wont hit the pain points listed above.
I'll let you know how we get on.........
No comments:
Post a Comment