Reading about Noel's day, I wondered a few things. I would be most grateful if anybody with more agile experience than me would offer some explanations.
1) How do you get the user stories correct? It seems to me that in order to develop any large piece of software using these sorts of methods you need to be bloody confident that the stories and their prioritisation are correct. A lot of the discussion I see is about getting the coding right and doesn't talk much about getting the correct stories to drive the coding. Mal has mentioned before that this is fundamental to the whole process. Do I need to buy that book he links in order to understand this?
2) A really felt like the success of Noel's day hinged on him over-hearing some important conversations going on near him. If he hadn't heard the chat and jumped in to assist then the relevant stories would probably have been implemented in a much less optimal way. Surely this can't be the best way? Does that mean that agile development discriminates against the hard of hearing? I know I'm being facetious but hey, it's my blog. How does this actually work in practice?
3) This passage really did make me wonder:
1:25 PM
Sean stops by my desk. He's ready to go back to work, but the programmer he was pairing with in the morning got pulled to work on some last-minute issues with Darkwatch, which is about to go gold and has priority over anything we're doing.
Sean quickly brings me up to speed on what they had been working on that morning, which was to display the exact memory usage for our physics system. I remember them mentioning that in this morning's Scrum meeting. I also worked on the physics system last week, so I'm pretty familiar with the code. In a couple of minutes we're already making progress.
I can definitely see how having people essentially choosing arbitrary tasks would be great for getting everybody familiar with a wide cross-section of the code. But can this kind of thing work when you have a group of people working on a group of tools? In other words, if Noel was working on a PS2 model previewing tool but he ended up pairing with Sean on his Xbox subtitle generator, which was most important? Do all of the stories go in the pot and whichever are the most important out of the whole lot get done first? It seems like it would be very hard to predict a delivery date for any particular tool in a situation like that - "You'll get your subtitler features delivered in the next iteration, assuming no stories that are more important come up for the PS2 model viewer"?
I know the whole point is being able to embrace change but it seems almost too fluid to be able to estimate effectively.
Posts
3 comments:
First of all - you did realise that the Waterfall conference page was a joke, didn't you?
As for writing and selecting stories - yeah, it's hard. I think think it's easier than writing a spec though - in a spec you need to know exactly how everything will work, with stories you just need to know what they achieve.
Now - managing multiple projects is a whole different kettle of worms. Your example is going to be very difficult to work in real life - you have one big tools team working simultaneously on different tools for different platforms, presumably with different people "owning" them? First of all, don't forget that you're running fairly short iterations (1-6 weeks, depending on preference and methodology...) and you have all the people responsible for prioritisation in the room at the same time at the start of the iteration. It's THEIR responsibility to debate and determine the relative priority of the different tools and to manage the cross team relationships at their level. What I personally would do would be to have a separate release burn-down for each product, so they can see how each one is doing at these meetings.
Now, within an iteration, you don't have a problem, even in your example. Neither of these stories is of higher priority - you get them both done in the iteration and that's all there is to it, so it doesn't matter which order you do them in.
For me, one of the main strengths of agile techniques isn't that you finish sooner or have higher quality (although they are
*generally * true), it's that you have much better visibility of what's going on - you can *see* that your XBox module is suffering in favour of the PS2 module early on and decide what to do about it.
In other words, I think that even in your example it will be easier to predict an accurate release date using agile methods - that doesn't mean the release date is going to be one that management will like...!
I have to get dressed and go to work now - hope I've made sense!
But just out of interest Chris - can you tell me how you would handle the situation you described using waterfall? To me, it seems like it would be even worse!
Of course I knew it was a joke, hence the "irony alert!" tooltip on the link. Give me some credit man! ;-)
As for using waterfall, well, that was just an example. I don't know if what we do has a name, it's just what we do. For the sake of argument, I'll call it "The Chris & Pete Model", since it's what me and Pete have come round to doing in the last couple of years.
We have 5 permanent developers working for us on our tools team. Each one is responsible for a particular area (e.g. level building tools). That person drives the development of those tools. When major work needs doing, they liaise with the customers and me and Pete to produce a feasibility document listing the requirements in reasonably basic form. It also includes a basic architecture showing how they intend to develop software to meet those requirements. Me and Pete sign off on that (acting in the place of the customer) and they go ahead and develop a more complete design that is sufficient to explain to me and Pete what work they need to do and that we can be reasonably sure it is going to be well structured, extensible, reusable, that they've thought about error handling fully and so on. Pete and I sign off on that too, again acting as the customer. But we are also customers in another sense, since it is our larger codebase that the developed features need to integrate with and that's a big part of my job - from technical, reuse and integration standpoints, will the developed software be good enough? Then the various steps involved in implementing that design are estimated and entered into the project plan and implementation begins.
Each person on the team does this for their particular area and Pete and I spend a lot of our time making sure all the different ongoing developments fit together and meet the needs of the customers.
The system has many benefits. Each person becomes a domain expert on their particular area, with me as the person who has the broad knowledge of a bit of every area. It also means that anybody who has a problem with a particular tool knows exactly which person to go to and ask about it - our customers have a name and a face that they know they can go to who will care about what they are saying. There are other benefits and no doubt a great many costs as well.
I think in any system that was story-driven then me and Pete would end up being the people writing the stories, so I guess in that sense we would have as much chance of getting them correct as we have now. I sort of feel that it would take some ownership away from the team members, who currently get to champion their particular area. I know we'd get collective ownership out of it and maybe that's not a bad thing...
I don't know, it seems like there's some good stuff that I should be taking on board but it's hard to see quite where it fits in.
What you're already doing sounds pretty good to me, Chris. And if it works, well, you know the rest.
For me, the big thing about stories is that they get at the *requirements*. Comparing them to writing specs simply isn't valid, IMHO. Requirements and specifications are two very different things. Stories simply address the requirements in a very simple form.
Regarding the format of the stories, I've heard some debate about this lately. In my last job, a single sentence of the following form was espoused:
"As a [role], I want to be able to [perform some action] so that I [get some benefit]."
The three things in square brackets are all you really need for a good requirement: knowledge of which stakeholder it's for; knowledge of what their goal/need; knowledge of how it benefits them. Knowledge of the benefit, in particular, gives a great insight to their work and the priority of the requirement.
That, for me, is the power of stories. By aiming to record those essential bits of domain analysis, it forces you to look into requirements from a goal point of view. Or, at least, it should. :)
Post a Comment