Posts Tagged ‘analogy’

The Baby and the Bathwater

Tuesday, June 1st, 2010

Every now and then people get so fed up with software failure they reckon it must be a systemic problem and they throw the collective knowledge in the bin and start again. This is the hunt for the silver bullet. The magic weapon to slay the vampire. This happened with use cases when user stories came along. It’s a shame. It’s lucky that use cases got stuck in the U-bend, and somebody used the plunger to suck them back up again.

The problem is not, and never has been, with developers being unable to cut code. Programmers do a good job with what they are given. It just happens that what they are given (the software requirements – user stories, whatever…) aren’t very good. Programmers don’t bother going back to the business and asking for something better, because they don’t get it, so they become resigned and get on with doing the job as best they can.

Agile delivery works fine. But user stories can be just plain silly. Just because it’s hard to define a good software requirement does not mean you don’t have to do it. If a user story isn’t properly fleshed out, you will find yourself trying to get to the details in programming time, not in investigation time – and that is wasteful and very expensive. It is going to lead to a lot of frustration.

‘Make things as simple as possible, but no simpler’. I wish I’d said that, but I’m just quoting it. (Apparently it wasn’t Einstein.) User stories with no structure, user stories that have no sense of wider context, are just too simple to be relied upon in anger. Hey, it’s not the delivery team that’s broken, it’s the requirements team. It always has been, and it still is.

User stories are a technique that in the hands of a good analyst are going to give the business a nice warm feeling that they are participating in the process. That’s a good thing. That’s a great thing. But you still need the analyst. This is not a process that can be de-skilled. It just can’t.

As Alistair Cockburn puts it “it’s much easier to write user story tags on index cards [then apply use cases] and let the project blow up later.” Agile project fail all the time. Practitioners claim failure is a kind of success. No, failure is failure. There’s no silver bullet, that’s true, there’s a whole box of silver bullets, and they only work when they are applied in a coordinated manner. Read: http://alistair.cockburn.us/Why+I+still+use+use+cases

Tags: , , , ,
Posted in Big picture | No Comments »

Humpty Dumpty putting it all back together again

Monday, May 24th, 2010

Say you are a Scrummaster walking along, minding your own business, and you come across a pile of user stories lying on the pavement. You pick the first one up, then the second one, then the whole pile of them and get yourself a stick of glue and begin to paste the stories together, hoping to get a view of the whole that ties all these stories together.

Or, imagine for a minute that these user stories are instead pieces of a jigsaw puzzle and it’s your job to make them into a big picture. The problem is that somebody has lost the box – you don’t know what the finished picture is supposed to look like. Suppose you use up all the pieces, but there’s something wrong. The person who lost the box, also lost some of the pieces.

What I’m talking about really is stories at different levels of decomposition; the hierarchy of stories, the project, release, iteration, of stories. If we haven’t got the project stories, we can’t make much sense of the lower level stories because we are unsure how the parts are supposed to hang together. If we have the project stories, that’s a different thing because we can break them down into lower levels that can actually be built in an iteration.

So we are agreed then that project stories break down into lower level stories, and it’s pretty straightforward to do that, but it’s still really important to make a picture of how those stories are related (their hierarchy of decomposition), because if we don’t know that, it’s just like having a smashed up humpty-dumpty at the bottom of the wall, and putting him back together again is just not going to happen.

Tags: , , ,
Posted in Storytime | 1 Comment »

How big is the elephant?

Monday, May 24th, 2010

A colleague of mine likes to ask the question “how do you eat an elephant?” The answer is “one mouthful at a time”, which isn’t really that funny, but it’s supposed to illustrate the Agile principle of ‘baby steps’. It kind of reminds me of an episode of the Simpsons where Homer is determined to eat this massive steak, and if he does it, he gets the steak for free. At least the restaurant tells him the steak is 16lbs. so he knows what he’s letting himself in for – kind of. Where am I going with this?

With an Agile project, we suspect we’re looking at a big steak, and we’re going to break it down and eat it bit by bit, but we have no idea how long we’re going to be at it, because we don’t know how big the steak was in the first place. Now say you had eaten a 4 pound steak before and you knew what that was like. If you set yourself up to eat a 16 pounder, you’d probably not eat for a few days beforehand to work up an appetite. You would at least have an idea about what you were letting yourself in for. But with Agile, nobody is saying how big the steak is. Nobody knows. Couldn’t somebody at least weigh it? OK, so maybe some of that weight is bone and some is fat and we don’t have to eat that, but it would be really nice to just have some kind of ball park figure. Know what I mean? Otherwise I’m not sure I want to get involved with this competition. I don’t need to know everything about that steak, but I’d be very grateful for a head’s up.

Maybe the analogy doesn’t hold. Say you haven’t got enough room in the fridge. Maybe I’ll just eat until you tell me I’ve eaten enough and can stop. Afterall, you are paying me to eat the steak (thanks). But you are not going to know whether I’ve eaten enough until you see it for yourself. What happens if while I’m busy eating the steak, you realise you really wanted me to have the chicken. Look, I can’t give you back the steak, that part of it is already eaten. What happens if I just eat whatever comes out of the fridge first, say it’s some bone (I’m going to find that pretty hard) or it’s some fat (pretty tasty maybe, but of no nutritional value). It’s a minefield. Perhaps I’ve taken this analogy as far as it will go. What I’m trying to say is I’d like to know what’s on the menu. That’s sensible. How do we make that happen in Agile? It’s not going to happen in Agile Delivery, that’s too late, it has to happen in Agile Requirements. Give me accuracy – precision can wait.

Tags: , , ,
Posted in Big picture | 1 Comment »

Pulp Fiction

Monday, May 24th, 2010

Last month I sat in on a two day user story workshop in a big insurance company, with 9 (!) analysts responsible for writing user stories. I saw the stories they were writing and didn’t think very much of them. The project they were trying to feed stories into had no sense of the customer, no sense of the product they were trying to sell, no sense of the overall purpose of the project. It was a mess. And this team had a backlog, but no idea of whether the stories in the backlog were ‘implementable’ in a release/iteration sense. There was no hierarchy, no project stories, no sense of the big picture. Just a lot of mush. The team was suffering from analysis paralysis! Or maybe I should call it ‘writer’s block’.

Everybody is a storyteller. Everybody has a voice, and wants to be heard. That’s how it should be. It’s also true that some people tell better stories than others, you meet them at parties, or conferences; people other people enjoy listening to. The master story teller is really an Agile way of describing the business analyst. The master story teller goes all around the village collecting everybody’s stories. Some of them are the same, some are parts of stories, some people can’t remember how the story ends. It’s like that with stories. The master story teller brings them all together and makes sense out of them. He then tells the story back to the village, and depending on how the story goes down, he might change it or leave it just as it is. Not everybody can be a master story teller; it’s a vocation. First of all you have to be a good listener, then you have to drill down into the essence of the story to find out what it’s really about, and finally you have to put all these disparate story threads together to come up with one compelling narrative. I think that’s a good way to understand what the business analyst does on an Agile project. He’s the keeper of the big story and he’s able to drill down into the story to come up with the detail when one of his more attentive listeners really wants to know.

Tags: ,
Posted in Storytime | No Comments »

Dogmatic Agile – discuss…

Monday, May 24th, 2010

Does Agile really work? Well, it works for some people. In reality any project will deliver successfully with any methodology if the people on the team are really motivated and talented. So if a great coach comes in and and gets the job done using Agile the conclusion is made ‘hey, this Agile thing is effective!’ Then the coach goes off to pastures new and the team tries to do it themselves and the project falls apart. So the Agile community talk about knowledge transfer and cultural change as being the key. And so it is. But cultural change is really difficult – and most people are average, by definition, and they like to be told what to do. People feel comfortable being told what to do. That’s reality. What do we do about that?

So Agile, a great set of ideas, becomes a dogma in itself when people stop thinking critically for themselves. ‘We can’t do that – it’s not Agile.’ So what?  Then we get dogmatic Agile – could there be a greater contradiction? There are lots of ‘Agile’ projects that fail. The community does a really nice trick here by saying ‘failure is success’. And in a way that is right, it’s better to fail early then fail late. If the project fails under Agile principles, we assume it would have failed under Waterfall, only later and costing more. This may be true, or it may not. We can’t tell. What we can say, is given there was a reasonable business case for the project, and given the project really would have delivered measureable business value, the fact it failed is a bad thing.

Tags: , , , , ,
Posted in Evolutionary Agile | No Comments »