Agile Lab - Training, Coaching and Consultancy Blog

Sunday, 6 December 2009 at

Building the Lean Web Development Team

20th January 2010, Hatton Garden, Central London


I'm running my course "Building the Lean Web Development Team" on 20th January 2010 in central London. Here are some quotes from people who've already been on the course.

"Great to learn about processes that we can directly take away and apply practically to our own companies."

"I like your analogies. They help me understand the concepts and how they relate to my business."

"The diagram of flow was really handy, sound. That made lots of sense."


Click Here to Book Online




For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , , , ,

Thursday, 13 August 2009 at

Why Agile Methods are Tip Top and EVERYONE should give learning them a go

This my 100 word entry for the School of Everything Paragraphs Mean Prizes competition:

I teach Agile methods. Agile is a set of project management methods that can deal with constant change. Everything changes. The people you work with change. The aims of the project change. The economic climate changes. Most important, our understanding of what we're trying achieve changes as we're achieving it. Agile provides a clear robust mechanism for dealing with this kind of radical change and for continuously assessing and improving performance. Agile is well-suited to complex fluid tasks like software development and website production but also useful to just about anybody who works in a world where things change.


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

Labels: ,

Friday, 26 June 2009 at

Re: I'm your software developer, and I'm listening - PS

Following on from this morning's post:

PS When you're writing down what your clients tell you, be very careful to write down exactly what they tell you. Lots of books on communication tell you to re-phrase what people tell you to show that you've understood, but this can so easily turn into defensiveness and make the client think that you aren't actually listening.

For example:
CLIENT: This project has been a complete disaster!
YOU: I understand that there have been a few problems.

Translates to the client as "I don't think this project has been a disaster, I think you're over reacting."

Much better (though requiring much more self control) might be:

CLIENT: This project has been a complete disaster!
YOU: OK, let me write that down. "Complete disaster." Which bits in particular do you think were disastrous?

As an old colleague of mine (who I never listened to) used to tell me,

"Make sure you've got all the poison out before you try to heal the wound."


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

Labels: , , ,

I'm your software developer, and I'm listening

A lot of the people I work with have difficult clients, but I suspect most of them aren't really of the same calibre as the people that William Goldman has had to deal with. In his book "Which Lie Did I Tell?" he paints a brilliant picture of movie stars as very powerful, very rich and very very paranoid. As far as I can tell from the book, directors are pretty much the same, but because they get less public attention they can actually be even weirder.


Like this - only take notes!



So, imagine the scene, you've written the script for a movie which is going to be a vehicle for a big movie star and is going to be directed by an oscar-winning blockbuster director. You get a phone call, they want a meeting to talk about the script, what do you do? Well, what Bill Goldman does is he turns up at the meeting with a big legal pad and says "OK, tell me everything. Just tell me everything that's on your mind. Let it out."

And as the star, or the director, or the star and the director, or the star and the director and the star's astrologist make comments, he does nothing but write, write, write. No matter how dumb; now matter how insulting. Just because he's written it down doesn't mean he agrees with it. It does mean that he's taking the feedback seriously and dealing with it like a professional.

He listens, he writes.


Then he talks.



The point of this approach is that it works to take the heat out of the situation. Research shows that people are no where near as desperate to be agreed with as they are to be heard. The powerful temptation when people start criticising your work is to start defending yourself. But this is a temptation you should do your level best to resist.

Capture feedback, THEN process it.


If you try to process the feedback as it's being delivered, you probably won't be listening that closely. Whoever is trying to give you that feedback will sense this. Maybe they'll become more and more strident, maybe they'll become silent and sullen and you'll think you've won the argument. All you're doing is storing up trouble.








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

Labels: , , , ,

Monday, 18 May 2009 at

Timing - Time Lines

I remember walking back to Fife Park (I think now, thankfully demolished) when I was a Philosophy student in St Andrews and looking at people on the street and thinking "I bet those bastards think time's unproblematic." I'd been reading "McTaggart on the unreality of time." And it had seriously disconcerted me.

And I've been reading about time again just recently, with similarly disconcerting effects. I know this would be something that David Allen, a veteran new-ager (if there can be such a thing) would describe as Wah Wah Woo Woo stuff, but I've been reading about Time Lines and I can't but think that it's very relevant to project management, and to the difficult business of persuading people that Agile is a very useful approach to project management.

OK - just as a bit of fun. Sit down. Feet on the floor, arms are your side. Relax. Think of an event that happened in your past. OK, now can you tell me where this event is? Can you point to it? Right, now arms by your side again - think about something that's going to happen in your future? Where is that? Can you point to it. Try this with other people that you work with, try it with your friends, your spouse. Do they all see things the say way as you do? No? Interesting huh?

The basic finding seems to be that some people "see time" when they think of it, in front of them as a series. Very often running from left (the past) to right the (future). The present is just another slot in the series. Some other people experience time as something that they are in, with the past somewhere behind them and the future somewhere in front of them (that's me).


The road ahead - this is something like what I see (actually turning off to the right) the past is behind me, where it's hard to see.


Some kind of timeline - this is what I think many other people see - and many project managers (click for bigger picture).


I suspect the truth of the matter is that both perspectives are required (otherwise, why are they both so prevalent) and that managing projects effectively means knowing how and when to flip between the two (or maintain both views at the same time). I suspect a lot of project management problems come from being stuck in the wrong view, or insisting on only one view.

What do you think? Let me know, either via mail or in the comments.

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

Labels: , , ,

Wednesday, 13 May 2009 at

On blogging - a post that never was - and an elephant in the room

I tweeted this:

Ugh!Didn't like http://bit.ly/mIdJU Really? I should write my own blogging software? If I write a novel should I write a word processor?


Which resulted in this response from Dumbledad.

Mark, really I wanted to comment on this tweet of yours(http://twitter.com/Mark_Stringer/status/1762534980 ) but you haven't blogged about it! Anyway, surely if I usurp a post on your seriously undangerous picture you wont mind ;-)
Don't you think that in the early days of the novel writers were developping tools in tandem with the novels themselves. One thinks of Proust's layers and layers of stuck on corrections and rewrites. Even now some writers use old typewriters, some a mass of post-its in a shed.
So, we're close (ish) to the start of blogging wouldn't you expect bloggers to tinker with blogging tools. Some wont have the skills to build tools, but some will. Some wont have the skills to customise tools, but many will. And they'll all have the skill to customise their blogging process.


I understand Dumbledad's point - and I agree with it to some degree, of course people with all manner of abilities should carry on innovating, improving an customising tools - as if anybody could stop them. But that still doesn't stop me disliking that post. I think it tries to create the impression that you have to able to do this kind of tinkering to even start SEO'ing your blog. And this just isn't true. Surely, making this the first point in your list would tend to put of the 99% of people (maybe more) who can't write software.

I don't want to create this impression. I would like as many people as possible to know just how much they can do - how easy it is to say what the hell they like - and get people to read it via search engines, without knowing a single thing about the technology (this is why I think Darren Rowse's #31DBBB is a very noble pursuit). There's nothing wrong with people learning everything about the technical stuff later, but putting it right at the front feels a bit like a smoke screen.

Perhaps hidden behind this - let's not call it dishonesty, let's call it - "strange emphasis", might be a discomfort with the way the world of the web and blogs and SEO is changing. Certain aspects of the business of setting up and promoting a website and a blog - and some much more complicated sites - are becoming very cheap and easy to do for people who have a minimum level of technical skills. The person I know who knows most about SEO is a photographer. At the same time, the technical knowledge of the "not technical" people is increasing in areas that are directly useful to them. A friend of mine was just telling me yesterday that he tried to tell a film director that he couldn't have something that he wanted on a blog - the film director's response was "Why not? I can get that in moveable type - look just give me access to the CSS and I'll do it."

OK - this is how I manage to shoe-horn this post into a blog about Agile software development methods. The cost in time and money and skills requirements of knocking up a pretty darn good state-of-the-art website is falling catastrophically. The way things are changing is going to play havoc with "established" models of software development - even Agile ones. Talk to a lot of companies that try to make money from web development and they'll tell you that they only really make money on the "easy" bits - setting up, hosting, CMS. It's devlish hard to make money out of actually writing new software. What's going to happen when the punters can easily do all those bits themselves and only ask the technical people in to do the difficult bits? This is something that occurred to me when I listened to a 10-year retrospective talk "Agility in the UK" at SPA2009. Some of the speakers seemed to think that we were still in a world of "soviet style" 1-2 year development projects.

Web developers: are they?

(photo courtesy of Phil Guest)

or are they heading for?



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

Labels: , , ,

Thursday, 7 May 2009 at

This is just a list - but a very good one

Just sent this list of references out in an email to my students on the Managing Digital Projects course. I think it's a good list, so I'll share it here as well.

Difficult Conversations - http://bit.ly/17jqqB
Getting to Yes - http://bit.ly/8DBgb
Sources of Power - http://bit.ly/LcK9H
The Web 2.0 Paper by Tim O’Reilly - http://bit.ly/ICDiz
The sceptical Facebook article - http://bit.ly/2088J
Extreme Programming - http://bit.ly/H0JV1
Scrum and XP from the Trenches - http://bit.ly/20k7hl
The Strength of Weak Ties by Mark Granovetter - http://bit.ly/wGxX

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

Labels: , , ,

3 Ways to Loosen Up your Thinking

"Yeah, my thinking about the case, man, it had become uptight." - The Dude, Big Lebowski.

Here are three things that you can do to loosen up your thinking. Don't think about it - just do it. Go.

1. Take a plain piece of paper


OK, look at that blank piece of paper and feel the pain of writers the whole world over who have to stare at a blank and then somehow try to make a living by making marks on it. Then forget about that and scrunch that piece of paper as tightly as you can into a ball. That's it, really tight. Now. Place that balled up piece of paper on your desk, or somewhere down in front of you and get another piece of blank paper and a pencil or a biro. You've got 5 minutes, as accurately as you can draw every angle and every crease of the balled up piece of paper. Every detail, every wrinkle, every variation of shading.

Begin.

This is an idea taken from "Drawing on the Right Side of the Brain" by Betty Edwards. The idea is that by giving the "logical" part of your brain something really, really, tedious to do, you make it give up and go away and give the other part of your brain that sees the big picture and makes "illogical" connections a chance.

2. Go somewhere where you can be on your own.


Look around and start pointing to things and naming them out loud. Mug. Computer. Book. Desk. Speakers. Chair.

OK.

Now do the same thing again, but this time give things the wrong name. Point to a mug and call it a "turnip". Point to a chair and call it an "interim report". Try pointing to things and calling them by very concrete names - point to a wall and call it a "haddock" try point to things and giving them very abstract names - point to a biro and call it a "lifetime retrospective". Keep doing this for about 2 minutes.

This idea is taken from Keith Johnstone's book "Impro" - it's a marvellous book. I've no idea what the theory behind it is - I don't think Keith does theory. He says that after you've done this exercise, the world seems to be sharper and more vivid place - it works for me.

3. Read this



In Broken Images



He is quick, thinking in clear images;
I am slow, thinking in broken images.

He becomes dull, trusting to his clear images;
I become sharp, mistrusting my broken images.

Trusting his images, he assumes their relevance;
Mistrusting my images, I question their relevance.

Assuming their relevance, he assumes the fact;
Questioning their relevance, I question their fact.

When the fact fails him, he questions his senses;
when the fact fails me, I approve my senses.

He continues quick and dull in his clear images;
I continue slow and sharp in my broken images.

He in a new confusion of his understanding;
I in a new understanding of my confusion.

I'm a sucker for poetry. One of the things it does is use words in new ways to see the world differently. Just about everything Robert Graves wrote, poetry and prose is worth reading.

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

Labels: , ,

Wednesday, 6 May 2009 at

Seven things that you should know about Agile

Here are some thoughts I keep having about Agile which I don't think I've written down anywhere.

1. Agile Moves Difficult Conversations: Agile moves difficult conversations - it doesn't remove the need to have them, or the need to know how to have them. We're in the uncertainty and ambiguity business. If it was certain and unambiguous, there'd be a macro to do what we're doing and we'd be out of a job. Management of digital projects happens where the rubber of software development hits the road of actually business requirements, this is always going to be a point of friction that smells a bit of burning.

2. Agile is more convincing when it's running: Agile is much better when it's running, but a lot of the training, documentation and persuasion is (and has to be) focussed on what it's like to start up an Agile project. People are never really going to go for Agile until they "get" what it feels like to be in the middle of a well-functioning Agile project. One way of getting people involved in the Agile process is to ask them the favour to suspend judgement, or perhaps work against their better judgement. Not forever, but for an iteration or two(I wrote a bit more about why Agile looks better once you're actually doing it here).

3. Yeah yeah Agile - it's a People Problem: Talk all you want about processes, but in the end, it's always a people problem (I was reminded of this reading Gerald M Weinberg's "Secrets of Consulting").

There is an oh so seductive little delusion that almost everybody is susceptible to - if we talk about people using systems language and mechanical terms like "man month of effort" and "design resource" we can somehow magically get over the fact that our star Java programmer has BO and our lead designer needs to up his anti-depression medication. Sorry, not going to happen.

4. Agile isn't permission to start speaking Klingon or Elvish: If you start talking an entirely new language to your customers and your managers you're going have problems. Agile might show you that there's a way of writing software that really works. Great. That doesn't mean that you're not going to have a gargantuan task communicating this to other parts of your organisation and to your customers. This is an important part of your job as a project manager. It's no good giving people who want a planned project a "if you want a guarantee buy a toaster" attitude. To a large degree, you're going to have to at least *start* making Agile work within the terms that they already understand. You have to square this circle. That's your job - if it was easy, there'd be a macro for it and you'd be at home in your boxers watching daytime TV.

5. There is no problem: Everybody and everything works perfectly already. Yes, you heard me. Yes, I know, I know, I know. Shut up and listen! Deep breath. Imagine what I've just said is true. What are you not seeing, if it is true that the mess you find every morning in the office is the best that all those people can do when they're working perfectly? The status quo is some kind of equilibrium between a whole bunch of powerful forces. In many ways that are invisible to you, it's probably the best and safest deal that the people working within it can get (read some John Nash before you start arguing with me). When you start to change things you're going to find out what some of those powerful forces are. You're maybe going to find out why what looks like poor performance isn't so bad after all.

6. You're a Knowledge Worker - and you don't know what you're doing: If you're talking to me, you're probably not a designer, or a programmer, or a project manager, you're probably all of those things and none of them all at once. All that posturing about how you're not going to do something because it doesn't fit with how you see yourself or how you were trained or what your job title is is really tiring (although part of being a project manager is probably to have those conversations). You're a knowledge worker - which paradoxically means that you spend most of your time doing things that you're not trained to do and have no idea about. That's what modern work is like. Read some Peter Drucker.
7. If I hit you hard enough, you will cry: You are not Chuck Norris - and will therefore get your ass kicked, in difficult conversations, in your attempts to introduce Agile to your organisation. Your success will not be measured by the number of times that you got your ass kicked, but by how quickly you recovered from said ass kicking and what you learned from it.

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

Labels: ,

Monday, 6 April 2009 at

About this Blog

This Blog in a line: How to use Agile Methods to stay sane and in control when everything around you is going crazy.

This Blog in 150 words: How do you manage a software or web development project in a world that just keeps on changing? Technologies change in the course of a few months. Economies lurch from boom to bust and back again. Staff are here one minute and gone the next and there’s hardly a chance that their set of skills is going to be right for whatever’s coming. Old methods of project management just don't seem to fit. Agile methods, Scrum, extreme programming and others make more sense, and give us at least a chance of dealing with continuous radical change, but there’s a danger that they can be seen as a magic bullet, a one-size fits all solution.

But how do these methods actually work? This blog tries understand Agile methods and to understand what they mean on a human level – and that’s also what our training, coaching and consultancy is about.
For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , ,

Monday, 23 March 2009 at

Introduction to Agile Methods – One Day Course

Are you involved in the specification, purchase, project management or delivery of an IT or web-based project? If so, you need to know about Agile methods. Agile methods, are a group of new techniques which make it easier to deliver IT and web-based projects in environments of uncertainty and constant change. Did you ever try to plan a project but things didn't go quite as you expected?

Agile methods are designed to deal with that kind of experience. They emphasise the delivery of projects in short iterations: the end of each iteration, priorities can be re-ordered or new ones can be added making sure that you are always delivering to the client the things that they value most.

This introductory course will give you an immediate feel for the difference that working using Agile techniques can have for the IT projects that you work on. Attending this course will allow you to: Provide the most value in the work that you do for you client; plan your work in short iterations; deal with new and unexpected information and changes as a project progresses; improve your estimates of how long work will take; and deliver what you say you'll deliver, when you say you'll deliver it.

Suitable for people working as either a producer or project manger or software developer in any new media or software development environment. Also suitable for people involved in the specification and procurement of software. No programming skills required.

This entry as pdf

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

Labels: , ,

Tuesday, 24 February 2009 at

Iterative Development

Mark talks about the process of iterative software development. This was filmed at our "Introduction to Agile Methods" training course that 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)

Labels: , , , ,

Friday, 13 February 2009 at

5 Ways Agile Methods Help you Save Money on Software Development

1. Agile methods emphasize working software at the end of each iteration - conventional methods don't


This means that, if you're a client, after the end of each iteration, which might be a week or a month, you will have some tested, working software, which you can use in your business.

2. Agile methods prioritise aspects of development - they deliver the valuable stuff first


Using stories - short descriptions of the functionality that you want - rather than enormous, detailed, specification documents, Agile allows the client to work with the developers to prioritise which stories they should work on first. This means that at any point on an Agile project, the developers are working on the software that is of most value to you and your business. It also means that stories that consistently end up without high priority can be discarded.

3. You can change your mind while you still have time and money


Because development is done in short iterations, you can change the direction of development after each iteration. If new functionality/new stories are required they can be exchanged for old stories. By adding some new stories and re-prioritising some old ones, changes in functionality needn't cost extra cash.

4. If the developers get the wrong end of the stick, there's still time and money to put it right


If you've had any experience of software development, you'll probably have experienced that awful moment when the developers show you what they've done and your heart sinks. You think to yourself - "That's not what I wanted at all!". Agile doesn't promise that this will never happen, it just gives you lots more chances to put it right - and a chance to put it right before all the money is spent and time has run out. One way of thinking of Agile is that it moves difficult conversations to the places where they are most effective - and cost effective.

5. Agile saves developers money as well as clients


Agile gives developers a chance to test their understanding of what the client wants at regular intervals throughout the lifetime of a project - rather than in one very awkward conversation at the end of a project. This greatly increases the chances that the software you're working on is something that your client actually wants rather than just a waste of your time.

If you want to know more about how Agile Lab can help your company save money using Agile methods, email mark@agilelab.co.uk

Labels: , , , , ,

Wednesday, 31 December 2008 at

Because I can't afford sky writing...

...I'm just going to set this in big bold text.

Almost every difficult conversation will involve strong feelings. It is always possible to define a problem without reference to feelings. But that's not true problem-solving. If feelings are the real issue, feelings should be addressed.

This is from a book I'm reading: "Difficult Conversations: How to Discuss What Matters Most"


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

Labels: , , , ,

Thursday, 18 December 2008 at

Introduction to Agile Training Course in Central London

We will be running our "Introduction to Agile Methods" one-day training course in Central London on Tuesday 3rd March 2009. The course will be run in conjunction with New Media Knowledge (NMK).

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

Labels: , , , , ,

Tuesday, 16 December 2008 at

Aspects of Agile - Scarcity and Consistency

We're called Agile Lab - not Agile Museum. And that's because we're always working to develop our understanding of Agile, and especially, to understand how Agile thinking connects to other kinds of understanding. That's why in this lecture, given recently to final year product design students at the Edinburgh College of Art, we talk about some thinking from the field of social psychology which is powerfully relevant to project management and Agile thinking.

No Robot Dogs Allowed

This is a talk which joins up a bunch of things that I read a while ago about social psychology and the "science" of persuasion, especially in a book called Influence: The Psychology of Persuasion
by a Social Psychologist called Robert Cialdini. When I was teaching our Introduction to Agile Course, I found myself very often trying to deal with objections to Agile ideas by explaining the notions of Scarcity and Consistency. And I also began to realise that a lot of the objections that people who attended my course were raising were also motivated by the kinds of psychological influencers that Cialdini talks about. Cialdini actually talks about six different influencers, but today, I'm just going to concentrate on Scarcity and Consistency, maybe some other day, I'll talk about the others.


Can I have a volunteer?

So when I gave this talk at the Edinburgh College of Art - I asked for a volunteer, preferably someone who could drive. I asked my volunteer to sit on a chair, close their eyes and pretend that they were driving. And since I was in Scotland, I asked them to imagine that they were driving up country at the end of the day, perhaps to a little cottage somewhere in the highlands.

Snow

Then I asked them to imagine that, as they were driving, it started to snow. And it snowed and snowed until the snow was so heavy that they couldn't see the road. Then, I asked them to imagine that they suddenly realise that the road veers sharply to the left and doesn't go straight on as they imagined! What should they do?

On this particular occasion, my volunteer wrenched the steering wheel to the left. We then discussed what would have happened if she'd done this in real life. Would she have skidded off the road? What should she have done? Steered into the skid, pumped the brakes? Changed down to a lower gear? The problem is that what you do in these situations is instinctive, unconscious and - as in the case of wrenching the steering wheel to the left, not always, actually, the best thing to do in the circumstances. But of course, with training and practice, you can be taught to do something different in those split seconds. You can be taught to do the right thing, the thing that the experience of others and lots of research has shown to be better than your gut instinct. In many ways, this is what Agile Training is about - giving us better instincts.

Influence by Robert Cialdini

And I think that's why I started to come back to a book I'd read, maybe a couple of years ago, the more that I taught courses in Agile methods, because the psychology of influence is all about playing with your instincts. Most of the people who are trying to persuade you to do something (the ones who are any good at it anyway) aren't trying to make you think, they're trying to stop you thinking. They're trying to use the fact that you will, reliably wrench the steering wheel to the left and stamp both feet to the floor when you realise you've missed a turn in the road.

Fields

A long, long time ago, this was all fields. For England this was about three hundred years ago. And when England was all fields (and still some forests) how rich you were depended entirely on how much land you owned. England in the middle ages was slightly poorer than some other countries - for example Poland - because there were slightly more people per acre of land.


Malthus

And this idea that land, food resources are scarce and that if there are more people, there is bound to be famine, disease and disaster is a very powerful one. In England, as the population grew it was described most famously by Thomas Malthus:

"The power of population is so superior to the power of the earth to produce subsistence for man, that premature death must in some shape or other visit the human race. The vices of mankind are active and able ministers of depopulation. They are the precursors in the great army of destruction, and often finish the dreadful work themselves. But should they fail in this war of extermination, sickly seasons, epidemics, pestilence, and plague advance in terrific array, and sweep off their thousands and tens of thousands. Should success be still incomplete, gigantic inevitable famine stalks in the rear, and with one mighty blow levels the population with the food of the world." Thomas Robert Malthus (1766 – 1834)

Factories

The irony is that at the very time that Malthus was claiming that Britain couldn't support its population, it was suffering a labour shortage because of these things. The invention of manufacturing and mass production in England and the US shifted the balance of who was wealthy from the people who owned the most land to the people who could make the most stuff that people wanted.

Factories

For a couple of hundred years, the richest men in the world were people who figured out how to make things that people want - like cars. They realised that you can get round the Malthusian problems of scarcity by just making stuff up - as long as it's stuff that people want.

Then this guy came along...

Turing

This is Alan Turing. It's arguable whether he actually came up with the design for the first real, working computer, but even if he didn't, he did come up with the idea of a "Turing Machine" which was a theoretical machine that could calculate anything. And so we moved into a new era of non-scarcity. Soon the richest man in the world wouldn't make anything that you could even touch or feel.

Bill Gates

Yes - this guy is arguably the richest man in the world and he didn't make it from farming. Computers took us into a new age of non-scarcity.

And this guy...

First web surfer

Does anybody know who he is? He's arguably the first web surfer. The man who shared an office with Tim Berners-Lee.

So we've come a long way from the times when how much land you had was a direct measure of how wealthy you are. Almost all of our wealth now comes from making stuff up. But even though we live in an internet age, we've stone age brains...

Daily Mail

The idea that some scarce resource is being exhausted - as is implied here, houses, jobs, school places, hospital beds - is a powerful persuader. It's like the feet shooting out and the steering wheel being wrenched to the left. It's instinctive, it's primitive. And the people who are using it, in newspaper headlines like this - or in adverts that say things like "Limited Edition" or "Sale Ends Saturday" are relying on you reacting instinctively.

Wizard of Oz

And the scary truth is - we can never go back to Kansas, not even if we wanted to. We can't go back to everybody having their own bit of land, not without the famine, war and pestilence that Malthus promised. If we want to be richer (actually, if we want to just keep living in the manner to which we've become accustomed) we're going to have to make up new stuff.

I hear objections about scarcity all the time when we're trying to teach people about Agile. In fact, the most frequent objection that I hear is "But this is a fixed price project." In almost all of the cases where people have this objection, I suspect that the scarcity of budget isn't a real scarcity - like a scarcity of wheat or a scarcity of land. Rather it's a fake scarcity - like a scarcity of designer handbags or bargain sofas. Someone is artificially creating scarcity to persuade someone to do something that they don't want to. And when the scarcity isn't real, there are a lot of alternative ways of making progress.

Pie

"Good negotiators make the pie bigger." Good negotiators find a way out of the "scarcity trap" by discovering new things that are of value to the parties in a negotiation. And Agile methods present lots of opportunities for making the pie bigger and exploring what's of value to the client. When you're you're working using Agile you should be suspicious of any claim for scarcity, if there isn't a physical thing like a wheat field or an oil well involved the scarcity probably isn't real. Someone is just trying to use your primitive fear of scarcity to persuade you of something. And that's your cue to do some work to make the pie bigger.

Cialdini

OK, so that's scarcity taken care (for now), so we'll move on to another one of the "six influencers" mentioned in Robert Cialdini's book.

Who wants a sweetie? Ok, this works better in real life that it does on the web.

Cialdini

Imagine the following dialogue:

Me: Would you like a sweet?
You: Well, thank you very much, I'd like one of the purple ones.
Me: Well, I've changed my mind now, you can't have one.

How do you feel? Wronged? Betrayed? And how do you feel about me? After just this tiny bit of unreliability, don't you that I'm either a little bit untrustworthy or a bit mad, maybe a bit of both? Perhaps something a bit like this gentleman.

Lord Archer

This man went to jail for - actually not for telling a lie - but for making preparations for telling a lie if it were necessary. But the way people treated him after he'd been caught, shows why our second influencer - consistency - is so powerful. If you aren't consistent. If you don't always say the same thing, if you aren't a man or woman of your word then people are tempted to draw one of two conclusions, either you're mad, or you're dishonest. Nobody wants to be thought to be either of these, so the pressure to be consistent is very powerful.

Chugger

And the people who want to influence you to do things - like give them money - know that. Consistency can be used in all sorts of ways to make you do things that you otherwise might not want to do. For instance - collect for charity.

A sample of Bloomington, Indiana, residents were asked to predict what they would say if asked to spend three hours collecting money for the American Cancer Society. Of course, not wanting to appear uncharitable to the survey taker or to themselves, many of these people said that they would volunteer. The consequence of this sly commitment procedure was a 700 percent increase in the volunteers when, a few days later a representative of the American Cancer Society did call and ask for neighbourhood canvassers. - Robert Cialdini: "Influence - the psychology of persuasion"

Seven hundred percent! That's the power of consistency.

Korean War

During the Korean war, the Chinese were exceptionally good at getting American prisoners of war to say things that were critical about America, and also getting them to say positive things about the communist regime. The didn't torture their prisoners, but they did use consistency as a powerful weapon.

Prisoners were frequently asked to make statements so mildly anti-American or pro-Communist as to seem inconsequential ("The United States is not perfect." "In a Communist country, unemployment is not a problem."). But once these minor requests were complied with, the men found themselves pushed to submit to more substantive requests.

The majority [of American POWs] collaborated at one time or another by doing things which seemed to them trivial but which the Chinese were able to turn to their own advantage.... This was particularly effective in eliciting confessions, self-criticism and information during interrogation.

So you see, you agree to one small thing, and the next thing you know...

Washing Machine

...you're buying a washing machine. Yes the same principle used by Red Army interrogators is being used by the people who design competitions for washing machines. If you write down in your own handwriting that you really like this washing machine - then guess what? You're working hard for the washing machine company to convince yourself that you really like their washing machine.

Bob Dylan

"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." - Ralph Waldo Emerson

Consistency is especially dangerous for innovators and creative thinkers. How can you innovate and be creative if you bow to the pressure to do exactly what you've always done? When Bob Dylan moved away from acoustic folk music and "went electric" in the late sixties, someone famously shouted "Judas" at one of his concerts. Bob's response was to turn to his band and snarl "Play fucking LOUD." But it takes a lot of guts to be inconsistent especially if everybody liked what you used to do (anyone remember when Bob started wearing make-up in the 80's?).

Tony Blair

And maybe for some jobs, being consistent is well, just not consistent with being successful. It's rumoured that before he became Prime Minister Tony Blair was asked whether he was Scottish or English and he replied (jokingly?) that that was something that would be reviewed over the course of the next parliament.

And maybe being a project manager is one of those jobs. One of the most common complaints that I hear from project managers is that they can't negotiate when they're "on the back foot". They promise to deliver something for a certain budget, in a certain time frame and then they can't. They feel terrible. Because they've been inconsistent, their client, they feel, is entitled to think that they are either incompetent or dishonest. Not pleasant at all.

How can Agile help? Well, Agile can't stop, or even really fight the power of consistency, but it can offer some alternative things to be consistent. Firstly, if you're consistent in the way that you apply the agile concept of velocity, you're going to know very early on whether you're going to be able to deliver what you promised when you promise. Secondly, if you follow this blog, you'll know that very often - to quote my friend Tim - "the only projects that we make money on, are the projects where we admit up front that we don't know". Being consistent about admitting when you don't know can save you a lot of trouble - and make you money. Your client is trying to get you to promise the earth for the price of a pizza - does that me you should go for it?

Consistency is a powerful tool (remember the American prisoners of war - remember the seven hundred percent increase in charity volunteers). The only real way to fight it is to use it for your cause and to be consistently honest with your clients about what you can and can't estimate and honest with yourself (in terms of velocity) about what you and your team can and can't do in a specific period of time.

And so now to the star of the show...

Robot Dog

What's all this about robot dogs? Well, the story as Robert Cialdini tells it is that he meets his neighbour in a toy shop on new year's day. And they both think that it's quite a coincidence, since they met each other there exactly a year ago, and, since they're both busy men, even though they're neighbours they hardly ever see each other the rest of the year. What's even more of a coincidence is that they're both buying the same toy - lets say it's a robot dog. The must have toy of the year.

When he gets into work a few days later, Robert Cialdini mentions this to one of his colleagues and his colleague - who used to work in the toy industry laughs a low dark laugh and explains that it's no coincidence. The toy companies spent years trying to figure out how to make sure people carried on buying toys into January, they tried all the usual stuff - sales, special offers, finally they hit on the use of a powerful tool of influence - scarcity! Around Christmas, rather than making sure that there's a plentiful supply of whatever the must-have toy of that season is, the toy companies create an artificial shortage. Then in the New Year, they ramp up their advertising and lo and behold there are plentiful supplies of the must-have toy.

Cialdini is furious when he hears this. He feels so manipulated - and he a social psychologist who should know about these things. He shouldn't be so easily suckered by a straight-forward scarcity ploy . He resolves to take the robot dog back. But BOOM! KABAM! - here's the other half of the double whammy? As his cynical friend in the office points out, he's buying the robot dog because he's promised it to his son. Does he really want to be the kind of dad who goes back on his word? What's he going to say to his son? I would have bought that for you son, but I decided not to be a puppet of the capitalist system - cue wailing cries of betrayal from the apple of his eye. Yes, backing up the scarcity move, is a consistency move.

In the end, he takes the robot dog home to his son. Older, wiser and hopefully not so easily fooled next time.

"You said you could do this for this for this amount of money. Now you tell me you can't. Well, there's no more money. What are you going to do?"

Sound familiar? It's just the old robot dog double whammy in a different time, a different place but with just the same power. Agile methods and Agile training can give you some tools to deal with these situations. Negotiation strategies can help provide "wiggle room" where is supposed to be nothing but scarcity. Tracking velocity and being consistent with the maximum "don't lose money" rather than "stand by what I said when I didn't know what I was talking about" can ease the psychological pain of appearing inconsistent.

Merry Christmas and a happy new year to all our readers!

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

Labels: , , ,

Monday, 15 December 2008 at

Good Negotiators Make the Pie Bigger

A friend of mine runs a small (but very cool) web development company. He went a long to a meeting with a film company who wanted him to build a website but for a "fixed price" of ten thousand pounds. My friend tried to move them on the price because he knew that he couldn't do the site for that amount of money. But the clients were firm, that was all they could spend. Luckily my friend had brought with him his new office manager who'd had some experience of negotiations. She suggested that maybe they could develop some of the software for a fixed fee and then license some of the other software for a licence fee of three thousand pounds a year over three years. The clients agreed instantly - software licensing was a different budget and they could easily afford three thousand a year.

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

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

Labels: , , ,

Thursday, 11 December 2008 at

Agile Training in Plymouth - January 28th 2009

We know times are hard, so if you're anywhere in the South West of England, this is an opportunity to get our "Introduction to Agile Methods" course at a very modest price.

We are running our ever-popular "Introduction to Agile Methods" course in Plymouth on the 28th January.

This course will be a bit different - the fee is only £45! and we will be filming Matt and me so that we can use bits of the training as part of a video.

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

Labels: , ,

Monday, 8 December 2008 at

What we do - Agile Consulting

Which parts of your company would benefit most from the introduction of Agile methods? What aspects of Agile methodology would deliver value the quickest? Are Agile methods even right for your company at all?

Some managers are scared by what they've heard about Agile methods, they fear that Agile methods mean allowing teams to do whatever they like and to make it up as they go along. In fact, the reality is quite the opposite. Agile methods make a team far more response to the needs of management. Agile methods actually increase management control. They also make it easier for managers to report to their managers and to be confident in what they are saying rather than being forced to rely on vague promises.

The danger when looking for help from an Agile consultant is that you will find one who is tied - either philosophically or contractually, to one specific Agile methodology. The danger is that when you look for an Agile consultant you will end up paying a made-to-measure price for and off-the-peg solution.

Agile Lab draws on the years of experience of its consultants in development and project management, but it always looks at every new case as fresh and different. Together with our customers, either in the UK or abroad, Agile Lab works to understand the best way to introduce Agile methods. They can also work with you to explain the benefits, both to your staff and to your senior management and your board.

Finally Agile Lab can deliver the introduction of Agile methods, and their tangible and measurable benefits and roll them out through your organisation.

Labels: , , , , ,

Saturday, 6 December 2008 at

What we do - Agile Coaching

If you're thinking about doing some Agile training you're making the right decision. but you probably need some Agile coaching as well.

Training is great. It's good for getting everybody using the same vocabulary. It's good for introducing a lot of new ideas in a short space of time. But training has it's limits. The people who get the most out of our course are those who back them up with a programme of coaching.

Agile coaching is about helping people change the way that they work in their own work environments. This rarely happens quickly. Agile coaching is about giving encouragement when it's needed but also supplying options. Agile coaching is about providing you and your team with confidence to change whilst dealing with the real world, the real time constraints, the real scepticism and resistance of others in the organisation.

Labels: , ,

What we do - Agile Training

Our "Introduction to Agile Methods" training course has been improved considerably over the last year. We've added several new activities - the Romeo and Juliet activity which helps people understand the concepts of "working software" and "minimum iteration".

We've also worked hard on our explanation of "stories" which seemed to be the concept that caused the most trouble for people who attended our course.

Then, when we're getting near the end of the day and most of the main Agile concepts have been introduced, we do our stand-up meeting exercise. This is always an interesting experience. As with many of the activities that we do through the day, even though it's only "pretend", people get very involved! As much as you could in a training course, people get a feel for what it's actually like to use Agile methods.

Labels: , ,

Tuesday, 7 October 2008 at

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.



Labels: , , ,

Friday, 5 September 2008 at

How can we persuade people that Agile Methods reduce costs?

I've just read this article by my friend Tim Diggins. I think it makes very clear why he uses Agile methods and what that actually means for him - as he says - what he does do and what he doesn't do. I don't think it's so good at convincing people who don't really know anything about Agile methods that they really lower costs - so here's my attempts, in note form.

Lower costs are what they're interested in so that's what needs to hit them first. It's like the story about James Thurber - he had a job as a crime reporter and he was asked to cover a murder on his first night. He reported how he'd heard about the murder, how the police had been alerted, who'd actually discovered the body. When he gave it to his sub-editor, the sub-editor said "No, no, no! This is all wrong! You have to start with the most important detail, the most important word even, first and then give the details in order of importance rather than chronologically"

So Thurber re-wrote his piece and started it off - "DEAD - that's how they found him!"

So how would this start?

"CHEAPER! That's what your software costs will be when you use iterative development." Even this is better. It's to the point but it's not obvious how to bring in the arguments you'd need to convince the reader.

Another tack is the Minto method:

  • Bland statement nobody can argue with
  • Sophistication/Complication
  • Solution that deals elegantly with the Sophistication/Complication

So for Agile this might be:

Everybody wants to lower the costs of software development.
But this isn't easy because a lot of the costs are hidden.
They come late in the process because:
  • That's when the clients and the developers realise they weren't thinking of the same thing
  • That's when developers charge elevated prices for requested changes to recoup costs for wasted work
  • That's when it becomes obvious that some new technology doesn't perform as well as the hype would lead you to expect
  • These costs can actually be so high that the project is abandoned - the customers get nothing for their money - the ultimate high cost.

Iterative development [Here is where you would teach the concepts of iteration and working software] which produces working software throughout the lifetime of a project is aimed directly at reducing these late and hidden costs.

  • Every time the client is presented with a new piece of working software, the understanding of the clients and the understanding of the developers about what the software is for and what it should do is tested. The chances of terrible misunderstanding (and big late costs) are reduced.
  • Changes can be added throughout the project, because negotiation in an Agile project can be in terms of scope, as well as price, it may be that changes may have little effect on cost
  • The emphasis on working software means that trouble with new technologies emerges early in the process. Something can be done early to work round the problem and find and alternative solution.
  • Iteration by iteration the customers get closer and closer to actually having the thing that they want. At all stages they have *something* that provides the most important functionality. The chances of having to abandon the project are greatly reduced. Conversely, if a project just isn't a good idea, this will be obvious much earlier than with a conventional project, the costs of cancelling it will be reduced.

Labels: , , , ,

Thursday, 26 June 2008 at

Introduction to Agile in Cambridge on 30th July

We are running our ever-popular and successful "Introduction to Agile Methods" one-day course in Cambridge at the St John's Innovation Centre on the 30th July 2008. Course fee is £200 but if you're the founder or one of the senior officers in a small company, it may be that you're entitled to a full refund of the cost of the course under a government scheme (one person attending has already qualified).

If you wish to book a place, please contact Mark Stringer on 07736 807 604 or email him at mark@agilelab.co.uk.

Labels: , , ,

Wednesday, 18 June 2008 at

One Day Agile Training in Bristol

Introduction to Agile Training in Bristol, Wednesday 29th October 2008



Agile Lab are running our popular and successful one "Introduction to Agile Methods" course at the marvelous Watershed venue in Bristol on 29th October 2008. To make a booking please contact Mark Stringer.

email: mark@agilelab.co.uk
phone: 01273 726 030
mobile: 07736 807 604

Course Fee: £200 (Early bird fee - to 14th July, £150).

Labels: , , ,

Wednesday, 11 June 2008 at

A Matter of Principle

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble. Ralph Waldo Emerson.

I read this and thought it was a very appropriate response to the kind of objections we often get to Agile methods.

Many people's first response to hearing about how Agile is done takes the form of a quibble with a specific method. But Agile isn't really about the details of any specific method - or indeed any specific methodology XP, Scrum, DSDM. It's more about the principles: iterative development rather than big-design up front; short iterations; working code; writing tests first and tracking velocity. That's it. All the methods come from these principles.

Labels: , , , ,

Monday, 19 May 2008 at

RSS - Rogue Surgeon Sydrome

The surgeon model as advocated by Fred Brooks is the second most efficient method of developing software. The analogy is with the surgeon who is the focus of the whole show during an operation - the one that all the other members of staff are there to support. In many small technology companies, essentially, you have one surgeon/founder/guru who writes all the code himself, or certainly writes all the difficult stuff himself. Quite often the surgeon was the one who came up with the idea for the software or the business in the first place, it's his drive, his creativity and willingness to do something different from the herd that is the reason that there is business at all. If the surgeon is good this can be a very effective way of getting software written. For a while.

There's a problem though. The surgeon model doesn't scale. At some point a successful piece of software is going to need a lot of boring, non-charismatic things done to it, like multiple language support and multiple platform support. At some point the organisation is going to grow and start to hire people who aren't doing it for love, but for money. Somewhere around 10-15 people organisations can no longer be run charismatically (because everybody just loves being in the founder's gang) and have to start being run bureaucratically (because people do the job they are paid to do). Accounts staff, sales staff and business development aren't the kind of people that the surgeon/founder - as someone I know delicately put it - wants to go to lunch and eat noodles with. To avoid these problems many new media and technology companies get stuck at around 10-15 employees, vaguely hoping that they'll be bought out by some Silicon Valley conglomerate. With no other growth/exit strategy they stagnate. It can be unpleasant to watch and even more unpleasant to experience.

This is a very tricky situation to be in and there aren't many good solutions. Quite often the "Surgeon" in this model is a founder of the company. The kind of person who founds a company isn't the kind of person who wants to follow rules. That's how they got where they are, by not following rules. Sometimes for other employees this can be very inspiring. Sometimes it can be very tedious. People who have had to work with Steve Jobs have called this the "Hero shit-head roller coaster". At one company that I used to work for, the "Surgeon"/founder would resort to chanting "Ooh! Aren't we grown up!" whenever the issue of pensions was raised at board meetings. This was infuriating for the other board members who had grown up, had wives and children and would really quite like to not have to survive on Pot Noodles for the last 20 years of their lives.

You can bring in "professional" developers and "professional" project managers - these are people who rely on process rather than charisma to get the job done. But very often they don't sit well with the people who are already there, gathered around the surgeon. When I suggested to one company that I talked to that they deal with this problem by hiring in outside project managers they said "Yeah, we tried that - he got eaten alive." You can bring in professional management and then fire the founder. Apple did this and that didn't work out so well either. What companies really need to do is restructure in a way that allows the company to scale and remain creative. The surgeon/founder should be given a role where he can carry on doing what he's good at - doing new things, breaking the rules, in business speak R&D.

Agile processes can help ease the passage through this difficult period. Pair programming allows the surgeon/founder/guru to spread his knowledge of the software around the development team. Test driven development and refactoring reduce the demands on the surgeon/founder and leave him free to do what he's best at - thinking good thoughts, breaking the rules and coming up with new product innovations. But Agile can't be the whole answer. You're probably not supposed to say this, when you work for an Agile training and consultancy company. Things will only really move forward when the founder and others on the mangement team admit to themselves and each other what they actually want from their careers and make sure that this is something that their position in the company can really provide. Maybe this is an Agile process because Agile is all about having those awkward conversations sooner rather than later.

This isn't just a problem in software development. I've been talking it over with Dave Dawes who works with social enterprises in the Health sector and he recognises it as a common problem. In many fields, amidst all the hullabaloo about the need to support entrepreneurship, the need to support successful organisations that are ready for the second wave sometimes gets lost.

Labels: , , , , ,

Thursday, 24 April 2008 at

The Value of Something

"A house is a machine for living." - Le Corbusier

"Have nothing in your house that you do not know to be useful, or believe to be beautiful" - William Morris

The difference between these two quotations is one of the most important differences between Agile and other methods of project management. Beauty is a word that doesn't get used much in software development. But really what Morris is pointing out is that in any complicated project - such as decorating a house - there are competing values. Actually, by insisting on only utility and beauty, he's trying to rule out some of the other competing values that might have been in the Victorian and Edwardian mind such as "have this in your house because your neighbours have it" or "have this in your house because it is in keeping with your social status".

A specification document is a list of functions. Things that a machine will do. Perhaps not a machine for living, but a machine for booking airline tickets, a machine for allowing teachers to upload videos of their lectures. But lurking behind that list of functions is a mass of values. Maybe they're straight-forward business values, such as "make it easier for our customer to book airline tickets when we're all asleep". Maybe there are slightly more complicated values, such as "Our competitors got a system like this so we have to have one." Maybe there are values that no one will ever admit to out loud: "My rival for the top job has got his pet technical project, this is mine."

So what does Agile do differently? How does it deal with values? First thing is the planning game. The customer has to prioritise the stories. In order to prioritise things, you have to use values. If you're working in a strict Scrum fashion, then you've only got one person representing the customer - the "Product Owner". Maybe you haven't been quite so strict and you've got several representatives of the client in the room. Either way, listen to what they say. Pay close attention to the reasons they give for putting one story above another. Those are their values that they're talking about. This is the Agile process bringing them to the surface.

Second, Agile insists making something that works as soon is possible: at the end of the first iteration. Once you've got something that works, everything changes. When there's nothing to point at, when there's nothing to show, when there's nothing they can have people actually use, managers have no alternative but to stick with attaching value to delivering on a plan. The demo of the working code for that iteration - the "sprint demo" is the second important point to watch out for the customer's values. Once the customer has something that actually works, the "value landscape" completely changes.

Curiously, when all they had was a list of functions, the customer's values could be all over the place. Now the customer has something that could actually improve the performance of their business, that could make their lives easier, something that actually works, it's very likely that their values will focus around the functions that it actually has. Can we make it go faster? Can we make it secure? Can we do that for all file formats? Frequently, as part of this process a whole list of things that were in the initial specification as "nice to haves" will be completely forgotten.

But what if that isn't their response? What if the response to a demo is stunned silence or outrage and fury and the customer says "That is not it at all, that is not what I meant, at all." One of my clients took one look at a demo and then went and sat in a corner, arms crossed, staring at his feet saying "Well, I suppose that is what we agreed on. I suppose that's OK." I was inclined not to believe him. What if it turns out that story number 34 that didn't make the first iteration was the thing that was really important?

Well, you didn't get it right first time, but at least you found out early. The whole of the budget isn't spent. The deadline for presentation to the board of directors hasn't yet arrived. You can do something else. The awful truth that no one likes to mention is that few people - clients or developers know what they're talking about until they've got working software in front of them. A lot of the values around any project lie tacit and submerged not clear even to ourselves. Agile processes help bring these values to the surface.

Perhaps the most quotable man of all time, Oscar Wilde said that a cynic is someone who knows the price of everything and the value of nothing. If that's true, Agile is the opposite of a cynical process. The purpose of Agile processes, of story prioritisation, iteration and demonstration is to find out what is truly valuable and deliver it to the customer. Even if it is one painful bit at a time.

Labels: ,

Monday, 21 April 2008 at

Making creative and business sit together with less conflict

One of the big questions raised time and time again by those involved in supporting and developing creative businesses is why it is that creative people are so good (and prolific) at starting businesses but not so good at sustaining and growing them?

Many more businesses are started by creative practitioners than those from a business background. Creative businesses are responsible for more new job creation than any other area of economic activity in the UK. London is a world powerhouse of creative business and yet despite this the failure rate of creative businesses is very high and of those that make it past the 3 year mark, many never grow beyond a dozen or so employees.

While there are a multitude of reasons given for this, such as the unwillingness of those that run such businesses to break through the 'lifestyle' barrier needed to grow or sustain a business to the difficulty in accessing investment, there is an important factor that is common to most, if not all, such businesses. This is the conflict between creative process and business process. It is not an untruth to reflect that these two areas of discipline are simply very different and require different attitudes, skills and knowledge but to end the consideration here is also neglectful.

One way to consider the root of the creative and business conflict is to look at the way that the processes that traditionally underpin creative and business activity are shaped. Business planning and execution is understood as linear. To attract investment or secure borrowing in order to build a business so that it can be sold or can realise the long term exploitation of IP is understood to require 3 year projections that provide a month by month picture and use language that suggests risk reduction achieved through careful long term planning. Here change is to be managed rather than embraced.

Creative people are at their strongest and happiest when thinking and working cyclically, embracing risk and dealing with constant change. This is true of those engaged in the creative application of science and art. Such people make hypothesis, explore and test such hypothesis, review the results of this activity and then adjust their hypothesis accordingly. It also true that business planning should be constantly reviewed and updated in light of progress made and lessons learned. Therefore cyclical activity is also common to the ongoing delivery of such plans even if it does not make the initial research and preparation of such plans any more palatable to the creative person. It does however give us a very important pointer to finding new ways of addressing this challenge.

Clearly we need to continue developing new processes and practices for engaging business heads with creative practitioners in ways that allow them to develop long term sustainable relationships. One such process I will refer to as Agile Business Planning. By using Agile process as the basis for business planning and development delivery we allow the creative practitioner to use processes that are familiar as they are cyclical, embrace change and risk continually and yet deliver continual and visible outcome. Such process is also SMART (specific, measurable, achievable, realistic and time managed) and can dovetail with the long term visioning and projection orientated nature of established business planning practice. It is simply delivered week by week, month by month, using a set of tools that are owned and understood equally well by the business head and the creative head and therefore reduce conflict allowing the creative business to grow and become sustained.

Labels: , , , , , , , ,

Monday, 21 January 2008 at

What is Agile? Stories, Iterations and Dealing with Constant Change

1 Agile refers to a bunch of project management methods that are well suited to managing projects in an environment where everything is changing. Agile methods came from software development but can be used for managing all sorts of projects.

2 Using an Agile method, a project team organizes all its work into "stories". A "story" is a short description of one thing that needs to be done on the project.

3 The list of stories are prioritized in discussion between the project team and the client.

4 The team, in discussion with the client select a number of the stories to work on over a short period of time (from about a week, to about a month). This is called an iteration. Each story in an iteration is assigned to a team member. This team member estimates how long the story will take.

5 The aim at the end of each iteration is to have something working to show the client. The client then has a chance to give feedback, to add new stories to the list of stories still to do, or re-prioritize the stories that are already there.

6 The team go through the stories that they've finished and compare how long they estimated they would take with how long they actually took. They use this as guide to future estimation.

7 The client and the project team go through the newly-prioritize list of stories and decide on the next iteration.

Read More:

Agile on Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development

"Extreme Programming" by Kent Beck

"Agile Software Development with SCRUM" by Ken Schwaber and Mike Beedle

"Scrum and XP from the Trenches" by Henrik Kniberg

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]