Stories. Well, not always.
Stories, stories, stories, stories everywhere.
Someone at work suggested that all the team goes for dinner and beers tonight. Well, "dinner and beers" are already too many parameters.
Hey!! We have a problem, with requirements, LETS MAKE STORIES ABOUT IT.
1) as a vegetarian I would like to eat vegetables so that I dont spoil my diet
2) as a broke I would like to pay very few so that I dont have to wash dishes for my dinner
3) as a broken heart I would like to drink many many beers so that I forget about my pain/boss/boyfriend/girlfriend/mother
4) as a football fun I would like to be to a place with a big tv so that I dont loose any world cup matches
5) as a mediteranean I would like to be in a place where I can speak loudly so that we dont get shshhsshed again by the rest of the bar/restaurant
Well, it didnt work out. Stories didnt manage to find us a restaurant/bar that we could go.
Really now, lessons learned.
A coleague was asked to jump in and project manage a small project. Following the holy_grails/fashion of making stories, he did make stories about the functionality. The programmers did not buy in. The project was already half done, the functionality was not describing the tasks that had to be done, and obviously a different approach was needed.
So the good coleague went to the old school of tasks: He broke down the project to bits and piecies of code, and assigned each of the programmers to some of them. And the job was done (well, not finished yet, but still it is better than before).
So, what was wrong?
a) The project was too small: According to the gurus, agile planning is a process which you revisit a lot of times during the project in irritations. When the project is supposed to take a couple of weeks in total, you dont need to spend half of that time revising the schedule.
b) The project was already in the middle.
c) The programmers did not buy in
d) The clients were not part of the process.
e) The project manager could not fulfil the role of the requestors, since he just jumped in.
Comments
Hi Koyan,
I like your stories, maybe we should try out a few of them when you're around next week.
On a more serious note, I agree with most of your analysis of when not to use the agile story approach.. Or let me put it like this.
I believe the agile stories can be very useful in determining functional requirements for software.. however, they are not very useful when used with too much zeal; kinda related to your point 'a'. I, as the project manager in question, overshot and used the stories to describe little elements in far too much detail. The overhead becomes too big, and the stories do start sounding rediculous -- point taken.
Instead agile stories should describe higher level functional requirements. Translating these into specific tasks and processes is essential to solving the problem. Where this responsibility lies is another question. One might argue that agile estimates just uses black box 'points' for this and leaves it to the developers to work it out, while the project manager sticks to the general overview: 'How much does it cost, and when will it be done?'
Now, depending on your involvement as a project manager in the technical realisation it may be justified that you're involved in making the old fashioned task lists, assigns owners, deadlines etc.
Maybe this is indicative of two very different roles of an IT project manager:
- the client / acceptor of work
- the manager of the workers
The two seem to require different approaches.
Just my 2 cents as a techie trying to do some managing ;). Comments welcome.
Tim
Posted by: Tim Bruijnzeels | July 25, 2006 11:48 AM