Slides for Tonight's Talk - Software without (so many) Tears

Here are the slides for tonight's talk - Software without (so many) tears.

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

Giving Yourself Some Options - Learned Optimism and the 'And' stance

It's far too easy call people names when they do things that you don't like, and it's very tempting.  There seems to be some kind of instant relief from saying
"He's just a bastard."
"She's just a racist."
"He's only behaving like that because he's very depressed"
"She's psychotic"

In fact, in my experience amateur diagnoses of mental illness are surprisingly common.  As with this casual diagnosis of Obessive Compulsive Disorder in an overheard conversation.

The problem with these labels is not that they aren't accurate – they might be, they might not be, but they aren't very precise.  Dealing with the difficult ways in which people behave in terms of character traits and diagnoses of psychological illness is the broadest of brushes and final and for all time. There is a certain kind of relief that you feel is from not having to think about the detail of the difficult situation now that person you've been arguing with, has been labelled.

This occurs to me having read Martin Seligman's book "Learned Optimism".  Seligman's definition of optimism is quite a technical one which covers some of the common sense concept of what we think of as optimistic, but not everything. Certainly Seligman's definition doesn't cover someone who regarded as "naively optimistic".  Who always imagines things will turn out for the best, irregardless of the evidence.  Rather Seligman's definition of optimism is concerned with the specificity of explanations of bad news.

For Seligman an optimist is someone who, when things go wrong, gives the most specific in time and specific in situation, impersonal answer that she can.

So, for example, if Sue goes to a meeting with her client Jim and before she even gets started on outlining the next steps in the project Jim yells at her, "I've just had about enough of you software people conning me at every turn.  Why can't you just do an honest day's work for an honest day's pay."

The central point of Seligman's book is that there are a variety of ways of dealing with situation and, in terms of what you think to yourself, these are better or worse for mental and physical health and welfare depending on how and to what degree you generalise over time and from situation to situation and to what degree you personalise.

So, for example, if Sue is to say to herself as a result for her conversation with Jim:

"Jim seems to be in a particularly bad mood today. Maybe it's this particular kind of meeting where he has to explain what he wants in technical terms that leaves him exasperated.  His complaints about 'software people' can't really be about me, I've only met him a few times before."

This would be regarded by Seligman as an optimistic response because it is local in time (it's just this time), specific in terms of occasion (it's particularly meetings like this) and it's impersonal to Sue (this isn't something about me, it could have been anybody who got this telling off).

On the other hand, if Sue were to say to herself:

"This is guy is just a nutcase." This is an explanation that's pervasive over time (people who are nutcases today, are generally nutcases tomorrow) and pervasive over several situations (nutcases behave strangely in a wide range of situations).

Or if Sue were to say to herself:

"I must be terrible at my job, I just don't have a professional demeanour.  Clearly there's something about my personality that's made him so angry." This is making it personal.

One of the problems of these kinds of explanation - which Seligman would term as pessimistic - is that they don't leave much room for progress.  If your boss really is mentally ill, or if there really is something about your personality that means people don't treat you with respect, there isn't much you can do about it.

This perhaps why Seligman's view is that, even if you would tend to come up with a pessimistic explanation is such a situation, even if you were to believe it were true, it still pays to try and see the optimistic view, because it gives you more options for action.

The "and" stance

In the field of negotiation and difficult conversations, there's a concept called "The 'and' stance".  It's outlined in Bruce Patton, Douglas Stone and Sheila Heen's book - Difficult Conversations.  The idea is to dispel fears and emotional reactions to situations by accepting that lots of things can be true at the same time.  Have you ever seen a person deny that they've made a mistake, even when it is obvious to everyone who is observing that this person has made a mistake?

Let's say that this person is Ted the Java programmer and that he's in a discussion with his client Clive who's just found a bad bug in Ted's software. Why would this person deny that he's made an obvious mistake?  The study of difficult conversations teaches us that when people's identity is under attack they will react emotionally and defensively, and very probably not rationally.  If it is a strong part of Ted's identity that he is a guru-level java programmer, the reasoning in his head might run like this:

• I am a guru-level Java programmer
• Guru level Java programmers don't make mistakes
• Therefore, if I admit to making this mistake, I will be admitting to NOT being a guru level programmer.

The result of this reasoning is that Ted refused to admit his mistakes.  This causes enormous amounts of difficulty, with clients, with his boss and with the rest of the team.  So much so that they no longer bother to point out his mistakes and fix things without discussing them behind his back.

Of course the truth of the matter is that the world is a very richly complicated and detailed place in which many things are true at the same time.  The approach of the and stance is to try to accept as many claims of the different parties to a difficult conversation at once using the magical word "and".

So, for example, in this case.

"Ted is a highly professional, guru Java programmer." AND "He has made a mistake."  We could perhaps add to this with a few more "Ands" - AND  "A mistake isn't the end of the world" AND "Now we've spotted it, it's easily fixed." 

In my experience, the effect of adopting the "and" stance is to take a great deal of the heat out of a difficult conversation.   Again, as with adopting an optimistic attitude to a situation, using the and stance opens up a set of options for solving the problem.

But remember, difficult conversations are hard.  You're not Chuck Norris - you will get your ass kicked (I got mine thoroughly booted just a couple of days ago).

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

Six Things you Really Need to Know about Your Customers

I'm running Introduction to Agile Courses in London on 9th July and in Bristol on 5th August.

This post is mainly aimed at people who are trying to write software for their customers, but it probably applies a lot wider than that. When I run training courses on how to handle difficult conversations, I try to get across the idea that you should try to move a conversation away from message delivery, to information discovery. But when you do that, what information are you trying to discover? Well, these six areas aren't a bad place to start.

Timing

Following on from yesterday's post, it's a good idea to understand as much as you can about your customer's timing issues and expectations. This doesn't just mean time-scales and deadlines for the projects you're working on, but also the kinds of timings that are important in their business. It means anything else that you can possibly think of related to time. When do they get in the office? How late do they stay? In their business what is regarded as a reasonable response time for a query? 2 days? 20 seconds? What's the planning horizon for their business? There might be lots of different answers. For example, in advertising, pitches might need to be knocked up over night, but billboard space needs to be booked three to six months in advance for a campaign.

What are the timing issues?

Comprehension/Comodification

For want of a better clumsy term or two, what I mean is, is the business that your client is in a new, pioneering innovative business, or is it completely understood, a commodity, where competition has to be on price and efficiency and organisation has be to perfect. People who work in industries that are comprehended and comodified can find web and software development utterly bewildering. A common recent example is the experience of producers from television moving over to "produce" (i.e. project manage) web development projects. The costs of producing a 1 hour documentary or a 30 minute studio-based sitcom are well understood. The costs of producing a successful social media website aren't.

Is your customer's business a commodity business?

Money

How do your customers make it? Which of their activities makes loads of cash? Which of their activities make hardly any cash? What is expected of your software in relation to making money? What are their margins? They may not know some of the answers to these questions. Even if they do, they may not want to tell you. But the more you know about this, the better placed you are to deliver them the software they need, within a suitable charge structure. For example, if they plan to do the bulk of their business using your software over long period of time, maybe a maintenance and licensing deal makes more sense than an upfront fee. If they intend the website to be more profitable than any other business that they've ever run, they might have a problem.

Suppliers

What kind of relationship does your customer normally have with suppliers? Are these relationships based on good personal contact or on contracts? Does your customer make money by playing one supplier off against another to get the lowest price (as do, for example supermarkets?). What sort of response do they expect from their suppliers in terms of responsiveness, exclusivity, even level of formality?

Identity

Who are these people? How do they see themselves? Are they ruthless business people? Intellectuals? Great craftsmen and women? Artists? Teachers? Curators? Healers? COmmunicators? A large number of people that you meet in business never wanted to be in business and aren't in their post entirely for the money (or at least that's what they're telling themselves). You need to know why they're there, otherwise you're conversations with them will make very little sense.

How do you customers see themselves?

Software Knowledge and Experience

What knowledge of the internet, the world wide web or of software is there in the business? What knowledge is there of what the internet/web/software can and cannot do? Does anyone in the business understand what bespoke software is? Does the business have any experience of commissioning bespoke web, or any other kind of software in the past? Was commissioning software a good or a bad experience? What was good about it? What was bad about it?

What kind of technology do your customers consider to be "state of the art?"

This is a far from exhaustive list, but the better the answers you have to these questions, the better the chances for the project as it progresses. I also hope it's clear how important it is to know how your own organisation would answer these questions. What are your timing issues? How you do you see yourselves? What is your identity? How do you make money? How do you want or expect to be treated as a supplier? More to the point perhaps, what's your experience of software and the internet?

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

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)

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)

In the Pub after my Difficult Conversations Talk

I was talking to this guy in the pub after my talk on Thursday.

"I've been the MD of two or three technology companies and I thought I understood what software was all about. I thought I knew all about technology. Then, just recently I started writing some macros in Excel, and then I got into VBA - and I thought - how hard could this be? And then after a couple of weeks it was like wow! Some things you think are easy are really hard - they take you days and other things, once you've got the hang of it, they're really easy. But when I'm doing this stuff - you'd better not talk to me, I can't be answering my phone or reading email of any of that stuff, when I'm writing code I've got to CONCENTRATE.

"And then suddenly it struck me - all these things programmers had been saying to me all these years..."

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

Feeback from my Difficult Conversations in Software Development Talk

This is the feedback I got for the talk "Software without (so many tears): dealing with difficult conversations in software".

Clearly I need to be more specific about how the things I talk about apply to software, but otherwise, I'm very pleased.

"covered a lot of personal conversational issues not exclusively software related. "

"Was an interesting talk on soft skills that are actually important for people in the software industry, lots of good and humorous points made! Perhaps there could've been some more direct software examples, but that's a minor quibble at best :) "

"This was a good presentation, refreshing to hear something on the often overlooked human angle of engineering/development. As someone who has had 'difficult conversations' in the past I enjoyed listening to Mark's no nonsense approach to reaching agreement. "

"Really got me thinking about how I react to others when having difficult conversations and Mark explained a diverse subject well in the short period of time. He also gave good direction for other resources regarding this topic."


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

Talking about Difficult Conversations Tonight

I'm talking tonight about difficult conversations and software development.

The beta version of my presentation is here (pdf). I'm very interested to see what the response is from an audience of Java Developers.

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

New Course - Difficult Conversations Made Easy

Talking Technical: Dealing with Difficult Conversations in Software and Web Development

Everyone in every walk of life has had experience of conversations that don't go the way they would like, or result in more anger, upset and frustration than they do in progress. These kinds of conversations seem particularly common when people talk about software or web development, especially when technical people and business people try to talk together about software of the web.

Research into the field of negotiation and difficult conversation by groups such as the Harvard Negotiation Project has revealed that difficult conversations can all be seen to be following the same fundamental pattern. Once the structure of difficult conversations is understood, it is much easier to learn strategies for approaching them that can massively improve the effectiveness and success of communication. At the same time, the chance of upset, anger and other negative and time-wasting responses are reduced.

Identity: It's always about you. Issues surrounding our identity are very often the drivers behind the most emotional difficult conversations. By understanding what identity issues are commonly behind difficult conversations,

What happened: What happened? Whose fault is it? What should happen next? This conversation is very often the aspect of a difficult conversation which is most obvious. We investigate the ways in which the ″What happened″ conversation can conceal the real causes of a difficult conversation and investigate the use of the ″And stance″ - a method for understanding the contribution that all parties have made to a problem without the need to apportion blame.

Feelings: Though many people think that there should be no place for feelings in the workplace. The uncomfortable truth is that ″If you don't have your feelings, they'll have you.″ Many, many difficult conversations which claim to be disputes over ″What Happened?″ and involve blame, finger pointing and accusations of bad intentions are in fact conversations about feelings. Unless these feelings are addressed, the problem can't be solved.

This one-day course covers the basic structure of difficult conversations and then covers a general approach to dealing with difficult conversations that can be applied in a wide variety of different situations. Throughout the day, participants are asked to take part in a series of exercises taken from real-life experience of the tutor of over fifteen years of software development. These exercises give participants the opportunity to develop skills in dealing with difficult conversations in a safe, supportive environment away from the workplace.

Mark Stringer is a trainer, coach and consultant. He has worked as a software developer and project manager for IBM and Xerox and for a series of small internet startups. He has also worked as a researcher and tutor at Cambridge and Sussex Universities.


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)

Using a Geometric Mean to Estimate a Piece of Software Development

I've just been reading a fascinating book about estimation:



My friend Tim was telling me about a problem he'd been having when talking to a client about software estimates and I found myself recommending using a geometric mean, although, right there and then over a deep-fried breakfast, I couldn't remember the precise details - so I'm writing them down here.

A geometric mean is another way of trying to get an estimate, slightly more complicated than just guessing, but not that much more complicated. Say you're trying to guess how long it would take to do a website. First of all, guess the maximum that it would take - say 3 months. Now guess the absolute minimum that it would take - say 2 weeks. Now, before we do anything else, put these things in the same units - 60 (excluding weekends) days and 10 days respectively.

OK, here comes the maths part, rather than "splitting the difference" i.e. taking the arithmetic mean between the two numbers. The book that I've been reading suggest that you take the geometric mean which is:

a = √bc

In our example, that comes out at:

ab = 10 x 60 = 600

√600 = 24.5 days

Of course, the arithmetic mean of the two estimates is:

(10 + 60) / 2 = 35 days

I think using a geometric mean may very well be a good way of "loosening up" people's estimating abilities. And also getting them familiar with landscape of possible outcomes of a software development project. Very often, people are just stuck with one figure and start to react with near hysteria when that line in the sand is passed.

Running a few trial numbers through a spreadsheet, it seems that one of the advantages of a geometric mean might be that terrible pessimism only has a mild effect on the outcome. For example for an estimate where the best case is a fortnight (10 days) and the worst case is a year (200 days), the geometric mean is 45.

By getting customers to think of the worst case scenario - maybe by using "yesterday's weather" of software development projects that they've been involved in in the past and then getting them to imagine the best case scenario, you're detaching them from one single figure and forcing them to grapple, just a little bit with the space of possibilities.

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

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.

Negotiations and Web Sites

After teaching a course last Friday I began to realise how important negotiation skills are to software development, and how powerful the combination of Agile methods and negotiation skills can be.

One of the stories I often tell on our Introduction to Agile course is about the first two projects that I worked on when I started out as a software engineer. Both projects were huge. Both projects were making good money from the company in their maintenance phase, they generated a steady stream of changes and updates which my company charged top rates to provide. Both projects had reached the end of their initial development phase on the verge of disaster. Both projects had got to the point where the customer was threatening legal action. In one case the customer was the British navy. If they had sued it would have probably been the end of the company.

In both cases, just when it looked like the projects were about to end in disaster, something very interesting happened. The projects brought in a negotiator. I think I saw him once on another project that I was working on that was about to reach its "Critical phase". He was short, (even shorter than me) and stocky with a totally bald head. They called him the Bulldog. All he ever did was go from project to project which had reached crisis point and negotiate with the customer. He would turn up to meetings with the customer and let the customer vent their frustration about not having any software, or about having software that could only run for five minutes without falling over or whatever it was. He would then try to get out of them what was the most important thing that the software had to do and also get out of them a little bit of money and a little bit of time in which to do that thing. He would also persuade them that moving the project little by little towards totally working was infinitely preferable to calling in the lawyers. If the lawyers were called in, all work would have to stop. After the dust had settled - in a few years maybe. The customer might get some of their money back, but they still wouldn't have any working software. Whatever the problem the software had been commissioned to solve would still be unsolved.

The theory of negotiation basically says that everyone who's party to a negotiation has something called a BATNA. I know, it's not a very pleasant acronym. It stands for "Base-line Alternative to a Negotiated Agreement". I think Agile methods, and especially the practice of delivering working software all the way through a project are very interesting. In their book Getting to Yes by Roger Fisher and William Ury, the authors recommend that negotiations move from positions to values. This is what happens when a project moves from talking about a specification document to working software.

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.

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