Trade-offs

A really good way of improving the exchange of information between clients and suppliers is to try to get them to tell each other about trade-offs. Every business has them.

When you're buying a car or a coat - do you buy the cheapest? Thought not. So what's wrong with the cheapest car? What's wrong with the cheapest coat? OK let's make a list: horsepower, features, handling, quality, style, having to wrestle someone for it in Primark.


Primark - Pile it high... (pic courtesty of adotjdotsmith)

Do you buy the absolutely best quality? No. The most possible horsepower no. Do you by any chance instinctively understand that when it comes to cars or clothes there are whole bunch of trade-offs? You can have cheap, but it won't be fancy. The faster it goes, the less likely it is that you can get a baby seat in it (or get baby vomit out out of the carpet). You can have top-quality cashmere haut-couture but it won't be cheap and you probably won't want to wear it when you go to the gym. You can have cheap, but don't expect it to fit.

Get the idea? It isn't just one trade off, there are lots. You don't really understand anything, until you understand the tradeoffs. And it's more complicated that that. In software development they're very often three way rather than two-way trade-offs.

I took part in a panel discussion where one of the other members - Chris Heilmann - said that whenever he starts talking to clients about writing software, he draws three circles and labels them "Cheap", "Fast" and "Good". Then he tells his clients that they can have any two - that's at least a start at getting his clients to understand that there are trade-offs.


Expensive? Yes. Stylish? Yes - but maybe not the right thing for the beach...(pic courtesy of Tammy Manet)

When we first started doing Agile training, we had great difficulty explaining the difference between the Agile concept of stories and terms used in other design methodologies such as "Use cases". Things got much easier when we started to talk about stories as "negotiations" (or trade-offs) between scope, priority and effort. Stories are dynamic. Each story is an exploration of a possible trade-off. When you start to think about things like this, you begin to realise what an improvished, static and inadequate thing a specification is.

For more about trade-offs, read from Gerald M. Weinberg - Secrets of Consulting.


For further information, contact Mark@agilelab.co.uk (07736 807 604)

The Trouble with Waterfall

Matt talks about his early experiences of waterfall project management methods - this is the first of a series of clips from a training course we did in Plymouth in January 2009.



For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

White Paper on Agile vs Waterfall, uncertainty and open loops

I've just finished a white paper that I've been wanting to write for a while on the differences between Agile and waterfall project management methods. The perception of many people who are new to Agile is that it actually makes the outcome of projects more uncertain, rather than less.

This is absolutely not true, but I think that sometimes, we don't do a good enough job of convincing people.

Lets Not Start at the Very Beginning (pdf, html)

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Marmite and Toast: an introduction to project management

Marmite and Toast gives people a chance to learn the basics of project management and to compare waterfall or industrial approaches to project management with Agile or iterative approaches.

This training was adapted from previous sessions run by Mark Stringer and Matt Gould for a half day for Wired Sussex's Brighton Internship Programme.

Feel free to check out the presentation.

Marmite%20and%20Toast.pdf

Marmite and Toast

We will be running a half-day introduction to project management workshop for the Wired Sussex intern programme on 22nd October down in Brighton. We decided to call the workshop 'Marmite and Toast' because we feel that when it comes to project management some people love it, some people hate it, some prefer it one way and some another, just like Marmite.

The intern programme is for new graduates looking to get into the digital media industry. Our aim on the 22nd is to give interns a basic understanding of how to recognise a waterfall or an Agile project approach and to understand the strengths and challenges of the two schools of thought. The interns will be spending 6 weeks working in digi-industry companies in Brighton and as we know from our conversations with local businesses, some of these companies will be working using waterfall methods, some Agile and some a mixture of the two. Therefore it is really important that people at the start of their careers have a basic awareness of the two approaches.

What's in a name?

[Sitting is Starbucks in Leeds - up here to run an Introduction to Agile Course]

Is your company Agile? Yes, I thought it would be. I don't think I've talked to anyone who didn't claim that their company was. Of course, further questioning would often reveal that they weren't actually doing fixed-length iterative development, weren't actually planning in terms of stories or any of the other things in the Nokia test. It took me a long time to realise why I wasn't getting an honest answer: no one is ever going to say that they're not agile. How likely is this?

Q: Is your company Agile?
A: No, not us, we're lethargic and arthritic.

The word "agile" perhaps betrays the movements American roots. It has lots of positive connotations: energy, intelligence, responsiveness. But (perhaps this betrays my British roots) this means that admitting you're not agile has all the opposite connotations: lethargy, stupidity, unresponsiveness. Nobody's going to admit to that - even if it's actually how they feel. And lets be honest, we all feel like that some of the time.

Trying to make people feel bad about themselves before you try to sell them something guaranteed to make them feel good is a standard sales technique. Whether you're selling soap powder of salvation it can be very effective.

We believe that (almost) all our potential customers are very clever people. They are doing a pretty good job with the tools that they have at their disposal. They don't need salvation - they need some new techniques. What we try to do is give them better tools, not software tools, not technological tools, but conceptual tools that allow them to do a better job.

Best feet forward?

Please don't anyone take this as advice of road safety. It's just an exercise.

Push your chair back from the computer. Just relax. Imagine that you're driving along in your car down a very familiar stretch of road. A journey that you've done lots and lots of times. Yes, that's it, mime holding the steering wheel. You can't close your eyes, because then you won't be able to read this, but in your mind's eye, imagine what you can see. Familiar roads, familiar corners, and junctions. Then suddenly, something jumps out in front of you. It's a toddler, chasing a ball. Stop! Stop! You have to STOP!

If you're used to driving a manual transmission car you probably wanted to stamp both feet straight out in front of you. One on the brake. One on the clutch. When we want to stop a car in a hurry that's our instinctive reaction. We tend not to think about it, there isn't time. But is it the best?

If the road conditions are good, it's probably the best, most effective strategy, but what if the road conditions aren't good? What if it's raining? What if it's snowing what if there's an inch of ice on the road? If the road's slippery, it's best to pump the brakes. But what do you do if you thump both feet to the floor and you start to skid? Apparently, you're supposed to turn into the skid to regain control even though this feels like exactly the wrong thing to do. People can learn to drive in wet and icy conditions, they can learn to resist their first instincts, pump the brakes and turn into the skids but it takes time and practice, rarely do people spontaneously do the right thing.

Someone was asking me yesterday why so many projects use a waterfall approach rather than an agile one. I think it's for similar reasons. In industrial societies waterfall methods are deep down in our brains. We just assume that the way that anything complicated gets done is by putting together a long, complicate plan and then trying to deliver on it. No matter how many times the result of this is the project management equivalent of skidding into a ditch, because this is our hard-wired, instinctive approach, we carry on doing it.

Agile is the project management equivalent of pumping the brakes and steering into the skids.