Posts Tagged ‘Agile’

Is Agile Broad Enough?

Friday, June 11th, 2010

It is widely accepted that Agile delivery demonstrateably adds value to software teams and their ability to bring software to fruition. There is however a question around whether Agile can achieve its full potential in the face of cultural resistance within the wider enterprise. For some there is now the acceptance that IT has the potential to be more than a cost burden; it is actually an avenue to compete more effectively in the market. IT is a strategic tool where projects with quantified business value deliver everything from streamlined internal processes to new customers through social networking sites. The better able the enterprise is in harnassing IT the better it will prosper, however it is not easy and they achieve varying degrees of success.

Set against a wider context of the end-to-end business process, actually delivering some working code comes far downstream. What needs to happen first? First ideas need to emerge in the organisation, gain momentum, become scoped, costed and valued and then, if all goes well, the initiative results in working system.

Given the project delivers a working service, we would be interested in a retrospective aimed at measuring success. For instance, certain assumptions were made regarding how much value the project would bring and how much it would cost to bring to fruition. We want to know whether it was ultimately worth taking this project forward once it has had a chance to ‘bed down’ because that information is valuable. Ideally a cycle can be established where the assertions and outcomes of initiatives are tested so that they may inform future estimation activity resulting in the ‘go/no go’ decision that governs all intiatives becoming more accurate. In this scenario, the estimates of future projects (cost and value) are compared with the resulting outcomes ultimately leading to the enterprise fully directing the IT function and reaping maximum competitive advantage.

Tags: idea management, governance, PMO, Programme management, Project management, effort estimation, value analysis, agile evolution

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

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 »

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 »

Café Culture

Monday, May 24th, 2010

Remember when they changed the alcohol laws and expected the British would start drinking like our European neighbours? Have you been into your city centre on a Friday night recently? It didn’t happen. It might happen but cultural change takes a long time.

If we are going to wait around for fundamental business cultural change before Agile can work it could be a really long wait. People will lose patience, the next big thing will come along, and everybody will jump on that bandwagon heading nowhere fast. No, no, no, there’s too much that is really good about Agile and what works – works, so let’s leave it alone. What I’m talking about is Agile Requirements – that’s rigour around user stories. Stories don’t belong in Delivery, they’re an input to Delivery, they’re the ‘requirements’, and they belong to the business. Yes, this goes against the status quo – all well – that’s what makes for a good conversation – right?

Does this violate the Agile principle of ‘cross-functional teams’. No, I’ve already said that what’s in Agile Delivery works and stays as it is. I’m just saying that it isn’t efficient to show up on day one of a Scrum for a planning meeting and expect all these expensive people to start writing stories from scratch, or worse yet, trying to make sense of a big mash-up of stories and fragments before they can get to work building something. It’s demoralising and it’s counter-intuitive. It doesn’t work. You show up on day one, you want some good quality stories to get your teeth into. That’s common sense – maybe not common practice, but it’s common sense.

I’m going to make the distinction between Agile Requirements(AR) and Agile Delivery(AD). So, to be clear, part of the story telling has to happen outside of AD. Once the iteration is underway, the two work together, but AR outputs stories and AD takes them as an input. This has a lot of ramifications – and they’re all good.

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

Agile Stress

Monday, May 24th, 2010

Why do people choose Agile? Is it because they are desperate? On the one hand Agile seems pretty straightforward – it’s a method that gives development teams more say in how they build software. On the other hand, Agile is hard because business people have to change the way they work coupled with needing a lot more trust. The business has to give up the illusion of control, and go for real control over a smaller planning window. They have to move away from the idea of fixed price/scope/timeline and embrace time and materials. No wonder management feel insecure. Wouldn’t you? And even though the Agile coaching community make it clear this is what is required, the business doesn’t want to hear it. It seems to me that people only hear what they are ready to hear – no matter how clearly you say something. That’s just the way it is.

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