Agile Lab - Training, Coaching and Consultancy

Wednesday, 30 April 2008

It's not called the model T for nothing

I don't think it's a good idea to talk about Web 2.0. It's a very tired term. The real insight about web 2.0 is that the technology didn't change (well not much) in the last 10 years, but our understanding of what can be done with it has changed radically. It's what people do with the existing technologies that's going to change what we do, even who we are. As with the Ford model A, model B isn't the interesting one. Although I'm sure a lot of people made a fuss over that. Model T is the interesting one. The runaway success, 19 iterations in. What will the Model T of the internet look like? Web Version 20!


Labels: , , ,

Tuesday, 29 April 2008

Baby Steps: Agile and the Small Creative Business

The founding idea of Agile Lab was to take innovative thinking from Agile methods such as XP and Scrum and introduce them to a wider constituency.

We worked together with an organisation called Creative Northants to understand the issues facing five small creative businesses in Northamptonshire. None of these businesses had any connection with software development or computing. We visited each business at their premises and interviewed them about the challenges that they faced as creative businesses in Northamptonshire. The resulting report was described by our client Will Pearson at Creative Northants as "excellent" and "very helpful".

We identified three areas in which these small creative businesses were having difficulty: business networking, marketing and knowledge of IT. We are obviously not the first to identify this kind of problem, especially with regard to marketing. A great deal of arts funding seems to require the businesses to produce a "business plan". Several of our interviews had been required to produce such plans to get government funding. None of them had delivered on these plans. In one case we heard of a major arts organisation that had been required to produce a detailed business plan in order to get funding, but had then not taken any steps to execute the plan for over two years (and counting).

At Agile Lab we felt that there were ways of helping these organisations without the need for a detailed long-term plan. Using the extreme programming principle of "start from where you are" and "you can always do something" we ran a workshop for our five interviewees. For each category of business networking, marketing and IT knowledge we asked them to write a short statement of something that they would like to do in that area - in Agile we call these statements "stories". We then asked them to write a "test" - how they would know when they had done that thing. This is something that is very different from a test for a piece of software. A piece of software either works or it doesn't, a conversation at a networking event make take years to pay off. We also asked them to estimate how much effort each task would take. Then (if you know anything about Agile, this won't be a surprise) we asked our workshop participants to prioritise their stories and come up with a set of stories that they feel they could deliver on in a period of three months.

Three months later we ran another workshop. In one-on-one interviews we carried out a retrospective on the iterations that our interviewees had put together. We were pleased to see that each of our participants had made progress in line with the iterations that they'd outlined. Each of our participants had done some marketing and some networking. Using the Agile concepts of story writing, prioritisation and iteration planning we managed to break an intimidating task that was at risk of not being done at all into manageable pieces.

Labels: , , , ,

Monday, 28 April 2008

No cappuccino required: how to develop functional peer to peer networks for rural creative businesses

One of the key challenges facing those charged with supporting the development and sustainability of rural creative businesses is how to achieve the benefits of the urban creative business clusters in the rural setting? Urban creative clustering provides a range of formal and informal benefits that include access to new business opportunities, the provision of support services, access to networks and collaboration opportunities.

A key quality of these clusters is prolific peer to peer activity. So much important interaction takes place in the pub or coffee shop. The ease at which a marketing and sales transactions can take place at a moments notice over a cappuccino in Hoxton is something that is difficult to reproduce in the rural setting. This is reflected by the fact that a common characteristic of many rural creative businesses is that the individuals involved were once located in urban environments and continue to work with, and invest time in sustaining the relationships they built up during their urban pasts (including periods of study).

One of the benefits provided by these urban peer to peer transactions is the way that the small or micro creative business can enjoy a bolt-on effect in which they can get business development outcomes with no investment made other than half an hour and the cost of the coffee. The cost of achieving the same outcome to the rural creative business can be much higher. It includes investing in constant networking activity just to keep up the level of visibility that often comes for free for businesses within urban clusters. The added time commitment and travel expenses that must be invested for such activity alone should not be under estimated, particularly given the speculative and potentially high risk nature of such activity. In the rural setting these additional costs become prohibitive.

To reduce this increased cost and risk it is essential that rural creative business development and support agencies consider the nature and characteristics of successful and sustained peer to peer interactions, regardless of whether they take place in the rural or urban environment:
  1. They are peer to peer collaborations (e.g they do not involve a hired in expert that imparts wisdom and knowledge)
  2. They are outcome orientated (e.g "lets meet for coffee to discuss a pitch I have been asked to respond to that you may want to come in on")
  3. They have a co-dependence nature to them in which one party needs that bolt-on capacity, skills, knowledge or contacts provided by the other party
  4. There is a clear business imperative and benefit to both parties underpinning the interaction
Therefore if those involved in supporting and developing rural creative business want to go some way towards making up for the lack of peer to peer access common to the urban cluster and reduce the risk factor when considering new models for developing these networks they should treat these 4 characteristics as requirements. If such activity can not achieve collaborative peer to peer relationships that are genuinely co-dependant, outcome orientated and address genuine business need for both parties then they are probably a waste of time and money. There will be a range of different ways that this challenge can be addressed but cappuccino is not required.

Labels: , , , , , ,

Thursday, 24 April 2008

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

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: , , , , , , , ,

Thursday, 17 April 2008

...without theory

The title - spread across this post and the previous one, is a paraphrase of a quote by W. Edwards Deming, management guru and statistician, who the Japanese credit with giving them the ideas that revolutionised their industry after the war.

A lot of Agile's power comes from its simplicity. It is a different theory. A theory that allows you to make sense of a ton of experience that previously, with your old instinctive project management methods, you were either throwing away, or even worse, getting depressed and feeling bad about. Did this task take three times as long as you thought it would? OK, don't beat yourself up about it. Don't wail and gnash your teeth because that wasn't in the plan. Feed that information into the next iteration. Get better at estimating. Did the priorities of the project change all of a sudden because of a boardroom reshuffle. Make sure that's reflected in the next iteration. Deal with change and get paid for it.

From the date of the previous post (when I first started thinking about it), you can tell how long this post has been troubling me. Maybe it's taken me so long to respond because there's a lot in this post, and I can't possibly comment on all of it.

The tone of the whole post is slightly depressed. My guess is the author (Mike Griffiths) had just got off the phone to a sales prospect and the news hadn't been good. Or he'd had some energy-sapping conversation with somebody who'd tried some bits of Agile and then rejected it out of hand at the first sign of trouble. We all have those days.

When things go bad, we fall back on our instincts, we try to do the "safe" thing. For project management this tends to be some form of waterfall planning - "OK, the chips are down, the pressure's on but if we just think of everything, plan every little detail and don't make any mistakes...". It doesn't work. This is one of the central ideas of Agile - although it sounds like something from a Kung Fu movie - "Don't trust your instincts - they're wrong. Learn some new ones."

The way that Mike muses in this post about writing a book sounds to me like a similar kind of instinctive reaction: "where my passion lies and where I believe the greatest leverage resides, is in effectively describing this balanced approach to leadership and project management. Strategies and visuals for finding that ever changing balance between people skills and process mechanics, order and adaptation, detail and intent." - if I just think of everything...

Two hundred pages of havering and hedging? That doesn't sound like a book that I'd want to read. The books that I tend to find most rewarding and instructive are the down and dirty ones which report ways that the author tried out a theory, took the experience, good or bad, on the chin and went back and modified the theory. Rinse and repeat as they say. There's some of this in Kent Beck's Extreme Programming but the best example I've read regarding Agile is Henrik Kniberg's Scrum and XP from the Trenches (also available free on-line).

Tuesday, 8 April 2008

Experience is worth nothing...

Tuesday, 1 April 2008

Pitcher's Poker - Part 4: The Other Side of The Table.

How does all this look from the side of the customer?

Well, I'm the customer. We looked at 6 pitches. Surprise, surprise, they all looked great. Music, visuals, promises, promises. But unfortunately, I've been here before, I've seen fabulous pitches in the past and selected the company with the most fabulous pitch. That project cost us a lot of money – twice what we budgeted for it. In the end it got canned. We don't talk to that company any more. In my head, now, when I think of the budget for some new web project, I'm thinking – yes, but that's actually going to cost three times that isn't it?

So this guy turns up. He doesn't have a laptop. He doesn't have a pen drive. He doesn't have a presentation! He has a flip chart and a marker pen.
“In one sentence, what is it you want?” He says. There's four of us watching the presentation. It doesn't make me comfortable that we all say four different things. He writes them all down.
Now things get really weird.
“Who's the pig?” he says.
“We beg your pardon” we say.
He explains the difference between pigs and chickens. It's like bacon and eggs. The pig is committed, the chicken is only involved.
“Who's the pig?” He says again. Who's bacon is on the line? My boss starts preening himself. But the finance director and the HR director point at me. My boss doesn't say anything. They're right. It's me.
He makes me put stars next to the four things on the flow chart. Then he draws a ring around the two with the most stars.
“Give us X amount of money and we'll demo something that does these two things by the end of next week,” he says.

Then he picks up his flow chart and leaves.

Labels: , ,