Agile Lab - Training, Coaching and Consultancy

Work isn't Your Dad

mark.stringer@gmail.com (Mark Stringer) — Sun, 07 Feb 2010 11:47:00 +0000

After I'd written the last blog post - a good while ago now - I was gently chided by a friend of mine for writing such a cocky article. An article that kind of implies that other people are stupid, but not me. He suggested that I add to it some examples of my own stupidity, preferably humorous ones.

OK. This is something I have done several times. I have opened a brand new box of cornflakes. And because it's a brand new box, the cornflakes tasted great. So when I come to put the box away, I've been worried that that plastic inner bag won't be adequately sealed, still keeping those cornflakes deliciously fresh. So I've taken the inner bag out of the box, and, holding one of the open corners with each hand spun the bag over and over to get a tight seal.

And the bottom of the bag has burst and I have found myself staring at a pile of fresh, lovely cornflakes, almost covering my shoes. This has happened at least twice, I hope I've learned.

But the real example of my stupidity that I want to talk about today is something that it's going to take a lot longer to laugh about. Here it is:

For years and years I thought that for some reason, I was entitled to work somewhere where I was treated fairly, where the people that I worked for were concerned for my career and my development and, crucially and most stupidly, where the things that I was given to do made sense. When I found, in job after job that this wasn't happening, my reaction was outrage and my solution was to move, looking for another job that hopefully did make sense and where I would (in my opinion) be treated fairly.

I first got this "Work isn't your dad" idea while reading Gail Sheehy's fascinating, fascinating book "Passages". Her point is that once we've fallen out of the cosy creche of university we tend to go through our twenties looking for a substitute for our parents. And where are the two places we look? Work and love life of course.

When all excited at this new discovery I explained my theory to a friend of mine (the same one that objected to the "On Stupidity" post) the dialogue went something like this:
"Work isn't your dad"
"What do you mean?"
"Well, work's unfair, it's capricious, it makes no sense, it doesn't have your best interests at heart."
"That sounds exactly like my dad."

Mmm. OK. So this might need to modified.

Work isn't your ideal parent.

Many, many of you might think that this is blindingly obvious, and if you do, that's fine. You can move on. Nothing more for you to see here. But for years and years it wasn't obvious to me. And many, many others don't see this. Clever people's lives are made agony because they don't see it. If that weren't the case, why would I find myself saying to close friends of mine things like:
"If your happiness rests on a committee of academics (who are all your rivals) making a just and fair decision, then you are royally fucked."

If this were obvious, why would a friend of mine invite my wife and I around for dinner, and then read us his 360 degree performance review? Desperate for us to agree with him about the unfairness of his bosses comments?

I know this now. But from minute to minute, that doesn't mean there isn't a serious danger that I might forget, and get all self-righteous and indignant that I haven't been treated the way *I* expect to be treated. One final slogan, may help me through, I read it in a nutty, nutty book, The Grunch of Giants by Buckminster Fuller, that reads as though it's been written by a man with a silver paper hat on his head to keep the aliens from probing his brain waves. But when I first read it, it was like a shot ringing out around the world.

You can either make money or sense.

PS This also ties in with the stuff I've been reading by Vankatesh Rao about the Gervais Principle. If you expect work to make sense your are probably one of the "clueless" as I was for oh so many years.

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

On Stupidity (and Web Development Project Management)

mark.stringer@gmail.com (Mark Stringer) — Wed, 16 Dec 2009 13:09:00 +0000

I was thinking about stupidity. What is stupidity? One way of looking at it is that it's when a model is being over-used, despite lots of evidence that the model might be inadequate to the task.

Here's an example. Say you arrived in France the first time – perhaps out of the channel tunnel and for some reason no one in your whole life had mentioned to you that they drive on the right-hand side of the road. You might be fine driving on the left-hand side of the road – for a while. When you meet the first car coming toward you on the "wrong" side of the road you might think "What an idiot!" But by the time you get to the third or fourth avoidance of a head-on collision, if you've survived that long, you might be ready to question your model of what's going on. If you weren't, then I think it would be perfectly OK to say that YOU were really stupid.

Stupid huh? Who lives for free with all the Whiskas they can eat? (photo courtesy Barbour)

This is very relevant to web development, since so many of my clients, who develop websites for a living, are so anxious to tell me that their clients are really stupid. Just stop for a minute and ask yourself.

"Who's really stupid here?"

Really? If you've had the equivalent of five or six, or twenty or thirty "head-on" collisions with clients, who is it who needs to change their model?

Building the Lean Web Development Team, helps you look at managing web development in a totally different way. Book now for the course on 20th January 2010.

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

5 things to do to improve the management of your web development projects

mark.stringer@gmail.com (Mark Stringer) — Fri, 11 Dec 2009 12:23:00 +0000

Here are 5 things to do to improve the management of your web development project. They all point to articles in this blog that go into each point in more depth. Enjoy.

First, don't catch your lemon:

don't take on projects that you already know won't make money.

Difficult, difficult, lemon difficult (picture courtesy of wikimedia commons)

Understand the importance of flow:

if you're going to count anything, count how long it takes for a project to get from start to finish.

Know your onions (and clients):

find out as much as you can about your client before you even start work.

Control your client using creativity:

stop moaning about your client and try to come up with new ways of dealing with the problems that he/she gives you.

Get control of the ″wildcards″:

understand the three main causes of delay in web projects that are outside your control - and how to deal with them.

Sign up for my course "Building the Lean Web Devlepment Team":

(I know, I know, this is six)

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

Managing Web Development Projects – the F word.

mark.stringer@gmail.com (Mark Stringer) — Thu, 10 Dec 2009 15:25:00 +0000

Today I was going to give you a totally rational argument about why you should do my course ″Building the Lean Web Development Team″ that's running on 20th January 2010. I've written that post, and that's here: Getting the Right Project Management method for Web Development. But then reading it back, and seeing all that talk about ″production of documentation″ and ″management principles″, I realised that I was committing a common failing – avoiding the F word – shhh - feelings!!!

One of the exercises that I do right at the beginning of my courses is to try to get a handle on the kinds of words/concepts/situations that make up a happy project and also the words/concepts/situations that make up a sad project. There are always some interesting points raised. But every time I do it, I can't help thinking that the real issue, what it feels like to be on a good project or a bad project is being hidden from view behind such weaselly business-speak words as ″poor communication″ and ″failure to reach goals″. And now I've caught myself doing the same and I want to put it right, right here, right now.

Bad Project Feelings

OK. Lets get the unpleasant stuff over with right at the beginning. Think back over your career. Can you remember a time, or if you're feeling brave, a few times, when dealing with a client made you feel bad? Just take a moment to remember how that felt. How did it feel physically? How did it make you feel at the end of the day? How did you feel talking to other clients? To your workmates? To your loved ones at home? Your fault, their fault, does it matter whose fault it was. The end result was that you felt bad and actually, as you're reading this now, I might be that that feeling of pain, injustice and impotent frustration is rising in you again. When we're doing this on a training course we give the person who embodies this ″sad project″ a name. So you might like to do that too. I don't know, maybe you could name it after a client or a company that made you feel that way.

Good Project Feelings

Enough of that. Lets move onto happier things. Can you remember a time when doing business with a client or working on a project actually made you feel good? When you really felt that you had the project under control, that you had all the skills that you needed to do a good job, make money and give the client want they wanted. I hope you don't have to go back too far. If you can't get all of that from just one experience, maybe you could collect the good bits from two or three separate ones. And just focus on the feeling. What did it feel like to be under control and getting it right? Did you find yourself smiling unexpectedly? Did you find yourself being more relaxed and joking with your workmates? Were you more confident when you were dealing with other clients. What did it feel like getting home after a long and successful day? What did it feel like getting up in the morning? And just like we did for the sad project. I wonder if you can give that collection of feelings that you get when you're on a happy project a name: the name of a customer that you really liked to work with, the name of a boss that you had a great time working for.

And now you've got both names I wonder if you notice the difference when you say the ″sad project″ name and feel all those feeling and then say the ″happy project″ name and feel all those feelings. Did you notice any difference between the two? Only you can know if you feel that difference. But if you can, that's why you should do this course.

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

Getting the right project management method for Web Development

mark.stringer@gmail.com (Mark Stringer) — Thu, 10 Dec 2009 15:19:00 +0000

Many web development companies would accept that their approach to managing projects could be improved. But the project management methodologies that are out there don't seem to fit well with the real experience of delivering web development projects:

PRINCE2 (initially designed for large government IT projects) seems to focus almost entirely on the production of documentation and seems to have almost nothing to say about getting things done.

Agile methods (initially designed for large corporate IT projects) have a much better focus on getting software written, but seem to have very little to say about the integrative nature of web development.

My own solution, based many experiences of helping web development companies is to derive inspiration from Lean. Lean is the name given to a set of project management principles derived from the hugely successful way that the Toyota Motor company produce cars. Car manufacture might seem like an initially unpromising place to look for ideas on how to run a web development company, but concentrating on the principles of the Toyota Production System, Value, Flow, Poke Yoke (mistake proofing) and What is it? rather than the practices, produces a powerful set of approaches for substantially improving the effectiveness of a web development team.

Find out more about my course, and book a place here: "Building the Lean Web Development Team".

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

Building the Lean Web Development Team: Flow

mark.stringer@gmail.com (Mark Stringer) — Wed, 09 Dec 2009 15:04:00 +0000

How do you make sure that you're team is most effective and efficient that it can possibly be? Well, of course you can start by making sure that they're all kept busy all the time right? Hmm. Consider the following diagram:

A diagram showing the Lean concept of flow

OK, the little balls represent little bits of work. The width of the "pipe" represent the capacity to deal with the work at different stages of the process. Here are some issues to consider at each stage of the process.

A to B for the customer - a long wait

What's important to the customer, what the customer experiences is end-to-end time. For the customer, all the blue dots aren't the same. Some of the blue dost are work that is being done for them and some of the blue dots are work that is being done for other people who they really don't care about. So for the customer, the speed that the individual blue dots get from A to B does matter. This is a big problem, because even if the system is working flat out, there's still a high likelihood of delays.

A to B for the team - it takes too long to learn

What's important to the team is end to end time. Certainly if there's to be any possibility of learning from one project to the next. Projects tend to take ages to finish, they're stopped and started, stopped and started and tend to end with a whimper rather than a bang. By that point, absolutely nobody is in a mood to go back over the project and see what went well, and what went badly. If a whole project could go from – say – start to finish in a couple of weeks, there'd be a lot more learning.

What's happening at C? The team.

Things which aren't good. The person or people who is trying to get work done at C is probably finding their work very stressful. No matter how hard they work, things don't seem to get any better. The person at C might be very tempted to try to cut corners and reduce the quality of their work as a way of reducing the backlog. This is far from good since, the bottleneck in many projects is the testing and/or release phases.

What's happening at C? The work.

And bad things are happening to the work that's piling up at C. Details of the work are being forgotten by the people who sent the work down the pipe, the situation outside the pipe that caused that work to be in the first place is changing. The work is "going stale". Even worse, it might be that work that's queuing up at C just gets forgotten and disappears.

Some solutions

Make sure you have ONE good definitive list of all the work. Get it out of emails, get it off of post-its hidden under coasters, enter it straight after telephone conversations into whatever means you use to capture the work.
Limit the work in progress. Have some kind of system for limiting the amount of work that is being dealt with by the team and ensuring that no new work is taken on until work that is currently in progress is finished. One way of doing this is to have a "Kanban" board which has only a limited number of slots on it for work that is being done.
Focus on end-to-end time. Start counting. Take notice of how long each piece of work takes to get from started to finished. What are the points where a piece of work is in the system but no work is being done on it? Is lots of work piling up at that point.
Change the process. A bit at a time. And understand that changing the process does not mean tell "everyone on the team to try harder" (especially the people at point C). Move extra people to stage of the process that causes the delay. Automate as much of that stage as can possibly be done (this works for both testing and deployment). Train addition members of the team so that they can help with this stage. Or [cue dramatic music] think about ways to remove that stage altogether.
Encourage people to do things "other than work". When the pipe is full, the last thing you want to do is to have your team filling it with more work in progress. This might be a very good time for them to learn new skills (so they can help out at point C) or to "tidy up". Work on that build script, install that testing framework, experiment with that continuous integration server.

I cover this, and the other three crucial aspects of Lean in my course which is running on January 20th 2010 – "Building the Lean Web Development Team".

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

Brownout on Agile Boulevard

mark.stringer@gmail.com (Mark Stringer) — Tue, 08 Dec 2009 15:12:00 +0000

Watching the tweets from #xpdays leads me to think that there is strong and growing interest in Agile and Lean Methods. I think this is a good thing.

But there is a problem, and the problem is confusion. There are a lot of supposedly ″different″ Lean and Agile methods and each one comes with an army Lean and Agile Coaches, Consultants and Trainers, all claiming that their method and their method only is the best.

The result of this confusion seems to be what I have called ″Agile Brownout″.

″Brownout″ is a term that used in countries where the electricity supply is less than perfect. A brownout isn't a black out. All the lights don't go off. But because too many outlets are drawing from the same source, all the lights go yellow and dim. And in the Lean/Agile field it seems that now there are more lights drawing on the grid than at Blackpool 'luminations. Scrum/XP/Lean/Kanban/TDD/BDD to name just a few.

The solution to this problem for many consultants seems to be to shout very loudly and insist that all the other lights should be switched off. Theirs is the one true light and it can only made to shine by extinguishing the others. My solution is a little different. To struggle on with the metaphor, my solution is to point out that:

depending what it is you want to see, you probably want to use a different light.

To my mind, each of the delineated Lean/Agile methods tends to have a niche where it works best. But for any kind of project, there's probably a bit of each that could be useful. Really, if you're a project manager, you owe it to yourself to check out what each of the methods offers. Since my specialist focus area is on tiny-to-small-to-medium sized web development teams, I'm just going to run over what I think are the good bits from a range of approaches.

PRINCE2

This is the language big organizations speak. You have to write the kind of documents that PRINCE2 recommends if you're ever going to have a chance of pulling down any big money for a project. And as a means of reporting progress on a project back to a big organization. But that doesn't mean you have to use this method to manage development for that, you should use scrum.

Scrum

Daily stand-up meetings, regular sprint planning, demonstrations and retrospectives are all good ways of managing actual development and tracking its progress. Extracting stories into a prioritized, effort-estimated backlog is enormously valuable by itself, if you institute no other Agile practice. Even if a team is working on multiple projects (as web development teams often are) the relief of stress and increase of focus that instituting this kind of basic management can produce is still powerful and heartening (and surprising).

XP (Extreme Programming)

Practices that are often labeled as Extreme Programming, such as TDD, Continuous Integration and Re-factoring are very useful if the software component of the web dev that you're doing is of any reasonable size or complexity. The thing to remember here is that any test coverage is better than none. And the emphasis on delivering working software at the end of iteration? That's gold.

Lean

For me, with Lean, it's the ideas and the huge benefits of an alternative view of what we're trying to do. Seeing web development as a value stream makes you focus on the value that you're delivering to your customer. This makes you look at the things you're doing day-to-day in a very different light. Focus on flow makes delivering (working? Right?) websites to the customer as soon as is absolutely possible a top priority and this in turn highlights obstacles. Remove those obstacles and you're in the money.

Kanban

Before you do anything else, limit the work in progress. I was especially impressed by David Anderson's point that you don't have to persuade anybody about the benefits of Agile methodologies to just start reducing the work in progress and seeing the benefits of that single move. Using a simple physical display to show everybody (including yourselves) what you're working on and limit the number of things that you're working on is almost equally simple and powerful.

John Seddon

This isn't a method, it's a person. It's worth reading his book if only to be introduced to the concepts of value demand and failure demand (slaps forehead). Why didn't I think of that? Seddon says you should try to solve the problems presented by the work and so, unless you're trying to make cars in Japan at the rate of demand, you're probably going to be solving a set of problems not directly addressed by the Toyota Production System.

I cover all of these approaches on my upcoming course ″Building the Lean Web Development Team″, running in central London on 20th January 2010.

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

If you care about improving the way you do Web Development, read one of these books this Christmas

mark.stringer@gmail.com (Mark Stringer) — Mon, 07 Dec 2009 14:29:00 +0000

I think that all of these books are important and useful reads for anyone interested in improving the way that they manage web development projects. Of course, if you just want the distilled best bits. You could always come on my "Building the Lean Web Development Team" course on 20th January 2010 ;-)

1. Organisation Man - James Whyte

If you're not self-employed, they you're in an organisation. And if even if you are self-employed, you have to deal with organisations. One of the things that I'm looking for in a non-fiction book is a completely different perspective that suggests to me a different set of actions for dealing with the problems that I face. I think this was the one that made me realise just how different talking to organisations was from talking to people.

2. The Toyota Production System – Taiichi Ohno

A fantastic book. Here's a man who really knew about car factories. But it has so much to teach anybody who is trying to do anything complicated in business. You get the feeling that the car factory, and beyond it, its customers and its suppliers had become somehow wired into his brain, that whenever anything went wrong he felt it instantly.

3. Learned Optimism – Martin E. P. Seligman

Don't give up. Some people never give up, and those are the people who when bad things happen to them ascribe problems to the system rather than themselves.

4. Scrum and XP from the Trenches - Henrik Kniberg

The sanest, least dogmatic book about how to do Agile that you'll ever read.

5. Freedom from Command and Control Rethinking Management for Lean Service - John Seddon

If software is a service, then maybe you need to know about how Lean works in a service industry environment. When I first heard about the concepts of ″value demand″ and ″failure demand″ it was like somebody had turned the light on whilst playing the Hallelujah chorus. If you're involved in web development or writing software, or getting web development done, or procuring software, you need to know about this stuff.

6. Lean Thinking – Womack and Jones

Fascinating follow-up to ″The Machine that Changed the World″. Some really interesting case studies of engineering firms that have adopted lean processes and a good account of the idea of a value streams. Some of the ideas in here (and particularly the way they've been sold as consultancy) have been criticised by Seddon, but this, and their previous book are still the best descriptions of Lean for a Western audience.

7. Getting Things Done by David Allen

Have a system to capture everything. Have a system for know what to do with everything once you've captured it. Do it. Simple huh?

8. Difficult Conversations by Bruce Patton, Douglas Stone and Sheila Heen

To quote Stephen R. Covey – whose books didn't make it to this list. ″Seek first to be understand, then to be understood″.

9. Getting to Yes by Roger Fisher, William Ury, and Bruce Patton

Explore the value landscape. Oh, you mean values, like those you try to put in a stream in Lean? Yes. Find out the importance of a wise deal and why such behaviour as ″trading on positions″ and ″low-balling″ are such a bad idea.

10. Zero Quality Control by Shigeo Shingo

Another book about the Toyota Production System, and other examples of manufacturing in Japan. I thought that I would be bored/put off by the actual mechanical examples. But this is such an intelligent book that

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

Stupid like a Fox (News)

mark.stringer@gmail.com (Mark Stringer) — Mon, 07 Dec 2009 10:06:00 +0000

Be careful what you wish for, but be even more careful what you measure.

I was amazed to read this. It's a very, very sorry and instructive tale.http://www.ft.com/cms/s/2/fd9ffd9c-dee5-11de-adff-00144feab49a.html

Especially because it shows the dangers of one particular kind of mistake that it's so easy for management to make, especially when there's measurement involved:

optimising the operations rather than process.

This is something that Shigeo Shingo warns against in his excellent book: "Zero Quality Control".

The executives who'd been parachuted into MySpace from News International had decided on a measurement to optimise: page views. There were making lots of money from page views. People who actually understood MySpace told them that they had to initially reduced the number of page views. The experience i.e. the overall process of interactive with the site, needed optimising. The News International executives resisted. They bogged down any attempts to reduce the number of page views in a laborious sign-off process. They did this for so long that MySpace lost any chance it had ever had of keeping up with facebook.

These super-smart executives just couldn't understand that the way to get more users (and hence, ultimately more page views) was to improve the experience and a very good way to improve the experience was to streamline it. They'd been given a measure they were going to optimise it.

Look around you now. Where can you see operations being optimised instead of process? Don't suppose there's anybody there who's mistaking being permanently busy for being genuinely effective for example?

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

Building the Lean Web Development Team

mark.stringer@gmail.com (Mark Stringer) — Sun, 06 Dec 2009 10:14:00 +0000

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)

3 Reasons NOT to do a Web Development Project

mark.stringer@gmail.com (Mark Stringer) — Sat, 05 Dec 2009 12:18:00 +0000

If you've come to this page for whatever reason and you don't work on a web development project, I hope you don't mind if I ask you to leave. This is really private stuff, just for people who try to make websites for a living. Here are some other interesting posts on this blog which aren't quite so private, personal and painful: "What is agile?", "Why is it so complicated?".

OK, now it's just us. These are three reasons (excuses actually) for doing web development projects which I hear a lot. They can all be prefaced with "We're doing this project, even though we're losing money on it because..."

...this is a big name client, a famous name and so it would be good to have them on our client list.

But they're treating you really badly right? You find yourself doing about twice what you would do for any other client just because they're a big, famous name and you want to please them. If you have relationship like this with every big name client that you work with, how long are you going to last?

...this is only a small (money) project but there will be bigger ones from this client in the future.

This might be true. But this means that you have to especially careful to get the balance right between the value that you give to this new client and the money you charge. There's a terrible temptation to bend over backwards to please your new client, in the process losing money and even worse, setting their expectations for your relationship for the future.

If you are being extra nice to them because they're a new client, make this clear that that's what you're doing! Make it clear that you're giving them an introductory rate or a 25% discount or whatever. Use this small project as an opportunity to understand your client - and identify any potential problems. Could you really work with them on a bigger project?

...we need this project just to keep busy and get some money coming in the door.

Ouch, ouch, ouch. And that's just when it's written down. When you actually hear the pain in someone's voice as they tell you, essentially, "We're taking on this money-losing project because we need the money." Oh dear. Hard times. Tough choices. So what can you do, if you really do need the money? Well, one thing is to make the discounting that you're doing explicit. This gives you much better scope for charging your full fee later on any further work. Another, even better option, depending on the sophistication of your client, is to offer a high-quality, reduced scope, full-price solution e.g. "we can't give you the bespoke site you want for that money, but we could skin a wordpress site that gives you 95% of what you want."

But finally. This is the hardest alternative. If you don't think you can make money from the work, don't take it on. As the Zen master said, empty your cup so that it may be filled. Use the time to finish any work-in-progress that is lying around and get it finished. Use the time to improve your processes. Use the time to talk as a team about what the recurring problems are with the work you do, and to suggest possible solutions. Advertise to existing clients and potential clients that you can now take on and deliver work at short notice - for a premium!

Oh and of course. Get some training. I can do it at short-notice for a premium ;-)

If you liked this blog post, you might like these: "I'm your software developer and I'm listening", "John Seddon's Re-thinking Lean Service", "The Value of Something"

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

This is really funny but...

mark.stringer@gmail.com (Mark Stringer) — Fri, 04 Dec 2009 13:18:00 +0000

This is really funny: http://theoatmeal.com/comics/design_hell and so is this http://www.27bslash6.com/p2p.html but you probably wouldn't be laughing the 9th or 10th time it happened to you. And if it happens to you 20 or 30 times, there's a good chance that you won't be in business.

Moaning very humorously about the problems that you have with your clients is great (unless perhaps your clients see it). But what are you going to do then. If you continue to get your ass kicked in exactly the same way time and time again then who's fault is it still?

It's your job to come up with solutions to the problems that arise again and again in your job.

And the only way that you're going to get solutions is by being prepared to try lots of things that don't work

One way of understanding this is something called "The Principle of Requisite Variety". It says that if you want to control something, you have to have as many "moves" as the thing that you're trying to control. Think of it in Bruce Lee terms (as I often do). If you want to control the bad guys (win the fight) you have to have at least as many moves as the bad guys. If you've got more moves than the bad guys, then you'll probably win. If all you've got is that jumping up and down on a wooden pole move you learned from Karate Kid, you're probably not going to win many fights. Some moves you might try:

Ignore it. See if it goes away.
Do it, but do it so bad that even they won't like it
Tell them, flat out that in your professional judgement that that wouldn't be a good thing to do.
If all else fails, if you really don't want to do this, fire them as a client.
(perhaps the smarter move) Get rid of such foolishness with pricing. Have a pricing structure that goes like this:
- Initial design £750 (initial %25 discount) for 2 days
- Amendments to initial design £1000 pounds for 2 days
- Fucking about and adding kittens, talking to your mother, £100 pounds per minute.

I think one way to phrase this last point might be: "Now we've decided to work together, let me just tell you a bit about the way I work. I'll do an initial design. That should give you an idea about whether I'm any good. If at that point, you don't like what you see, we can part company for a minimal fee (or you might say, even free).
If you DO think I'm good enough, we'll go on,
and the next treatments will be charged at £1000. But one thing I have to say, is that in my experience, there isn't a lot of value going past 3 or 4 versions without actually showing it to users, getting it live on the site and getting the reaction of your customers. Also, lots of little minor changes like that late in the process,
although they don't seem like much, they actually take me a lot of time.
So at that point I do charge by the hour." In my upcoming course - Building the Lean Web Development Team - we deal with the real world problems that web developers and their managers face. Sign up to attend on 20th January 2010 in central London. For further information, contact mark.stringer@gmail.com (07736 807 604)

Tackling the 3 Problems that Prevent Web Development Flow

mark.stringer@gmail.com (Mark Stringer) — Fri, 04 Dec 2009 10:37:00 +0000

I specialise in helping companies that develop websites. Part of that is giving them training and consultancy around using Lean and Agile methods, specially tailored and focused for the web.

One of the things I'm often asked about is how to improve estimates for projects. I think think a lot of the time, what this question really boils down to is: how do you get better control of the time that it takes to develop, deliver and get paid for a web development project? I think the answer is by making sure that you keep a close eye on those aspects of the web development process that are outside your control and may take FOREVER. Here are three problems you should really keep an eye on.

Problem: Late/Non-arrival of assets

This is the biggie. Many clients who commission web sites do not understand how much extra work is involved in preparing "assets" for the web. By assets, I mean any kind of content, written copy, graphics, images, sounds, video. The effort required in writing good copy for the web is especially underestimated.

Solution

Make it clear which content aspects of the website your client is responsible for producing. Make it clear that, in your experience, this is an aspect of web site production that affects timescales. If the issue is web copy, suggest that they hire (or you hire) a good web copywriter to produce the copy.

Problem: Lack of sign-off

Actually, this is another biggie. Actually it's two.

For the client mucking about with designs endlessly is (seemingly) much less risky than exposing it to the world.
In a lot of hierarchies, many, many people have the power to say no, very few people have the power to say yes.

Solution

Make it clear how much lack of sign-off costs. One way to do this is to take the costs of lack of sign-off out of the development budget! I have recently seen this work with termendously powerful effect with one of my clients. Another way is to offer discounts if sign-off happens within certain periods. Make it clear that quotes are valid and timescales can only be honoured if sign-off.

If they really do want to see hundreds of different designs, tinker with things endlessly. That's fine. But that needs to be on a time and materials basis.

Problem: Unavailability for Meetings and Feedback

Everybody's busy. Client's often express the wish that you would "just go away" and do the website. Unfortunately, quite often, what happens is the opposite - they "just go away". They stop responding to email and phone calls. This can be because they're very, very busy, but it can also because their business is changing in ways that mean that they won't need your website anymore.

Solution

This is an impossible situation and you have to make sure that your client understands this. If the client isn't available for meetings, or sends someone to meetings who is not really empowered to make decisions, make it clear to the client that the project is stalled and that no work is being done on it until they provide their input. Again, it's also very valuable to make clear how much this lack of contact is costing. Meetings with juniors who have no power to make decisions aren't free.

If they really are too busy. By far the best thing to is to sell them inidividual iterations. This provides them with the clean "Just Do It" experience that they seem to crave, whilst at the same time reducing risks for you. If you provide them with a working prototype at the end of every iteration, there's a much better chance that they'll come back for more.

I cover these problems, and their solutions in more detail in my course Building the Lean Web Development Team

If you liked this blog post you might like: "Six Things you Really Need to Know about your Customer" and "I'm your software developer, and I'm listening"

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

Two types of demand: Value Demand and Failure Demand

mark.stringer@gmail.com (Mark Stringer) — Sun, 29 Nov 2009 17:11:00 +0000

There are two broad types of demand on any service centre - value demand, the calls we want and failure demand, that calls we don't want. Value demand is what the xervice center exists to serve; it represents the demands customers made for things they want, things that are of value to them. Failure demand is created by the organisation not working properly. I define it as follows:

Failure demand is demand caused by a failure to do something or do something right for the customer.

John Seddon - Freedom from Command and Control: Rethinking Management for Lean Service

Posted via web from What Stringer's Reading

Adventures in Agile (with me!)

mark.stringer@gmail.com (Mark Stringer) — Tue, 24 Nov 2009 12:05:00 +0000

Max St John, one of the extremely talented bunch over at NixonMcInnes in Brighton has written a blog about the real nitty gritty experience of implementing Agile practices on a large, multi-stakeholder web development project.

Very kindly, he gives me a name check.

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

Tuesday night #xtc after the innovation games

mark.stringer@gmail.com (Mark Stringer) — Thu, 19 Nov 2009 12:29:00 +0000

I was talking to @benjaminm and telling him how excellent I thought his rendition of the red bead game was. And I was also talking to him about how I thought John Seddon's ideas were great but that I didn't think telling people that they were stupid (which is what he seems to do in his talks) is a particularly effective method of helping them change. Benjamin said that Seddon doesn't do that when he's actually consulting. He keeps quite and tries to find people that he calls "curious" members of management that might not be so hypnotised by the system that they're in that they can't still be interested in the actual problems of the work.

Benjamin seemed to like the comment I'd made at the red bead game about the RBG being a way of teaching Learned Helplessness as it's described in Seligman's book. I wondered if the people that Seddon finds in big organisations are the people who refuse to learn helplessness - just as about one third of Seligman's miserable electrocuted dogs refuse to learn it. I also talked about "The Psychology of Military Incompetence" and how some people must somehow manage to not get crushed by what Dixon calls "bullshit" otherwise we would never get any good military leaders.

Oh dear, sounds like I did most of the talking.

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

4 Reasons for Doing Anything (and why you should attend Building the Lean Web Development Team)

mark.stringer@gmail.com (Mark Stringer) — Tue, 17 Nov 2009 11:15:00 +0000

I recently read somewhere that there are only four kinds of reasons that persuade anybody to do anything. Since I sincerely think that anybody who has anything to do with web development should DO MY COURSE - Building the Lean Web Development Team, I thought I'd try all four of them.

Everybody is Doing this Course

Well, actually they're doing similar courses. Almost everybody involved with software development is now taking a look at Lean and Kanban. If you do this course, you'll be joining hundreds of thousands, if not millions of people worldwide who are realising that the approach of the Toyota Motor Company has something to teach them about their own business. But Shhh. Don't tell everybody this. Hang on a minute, what am I saying do tell everybody this. It's really important: Web development is different from making cars. Lots of people are talking about Lean and Kanban getting in consultants and going on courses, but they're trying to take what worked for making cars and clumsily attach it with staples and masking tape to the rather different process of software development. The differences between traditional software development and web development are mere details: kinds of details that Toyota's process guru Taiichi Ohno made a world-beating company by paying attention to.

Nobody is Doing this Course

If you do this course, you'll be in an elite minority. You'll be a rebel, a revolutionary, a true visionary. Almost nobody else is actually taking the principles that Taiichi Ohno used to develop the world's biggest car company and using them to actually understand and radically change the way people do web development. What most people are trying to do is to modify the practices which is, to be frank, just a little bit crazy. If you do this course, you won't just be giving your company a head start, because most companies will never be able to see web development this way. This course will teach you to look at your web development team in a way that will allow you to massively improve the effectiveness of what you do.

If you don't DO THIS COURSE Bad things will happen

If you don't do this course, or apply the kind of the ideas that we deal with in this course, bad things will happen to your Web development team. Quite simply, you will be overtaken by the web development companies and teams that do start to shape the way they work by the unique nature of web development problems. You won't be able to compete with these teams in terms of quality, cost or speed of turnaround. You know what's even worse? Evidence from what happened in the car industry is that even when things are utterly disastrous, you won't be able to see the problem.

If you do DO THIS COURSE Good things will happen

Lean web development is about learning to see web development for what it really is. Once you start to understand that "project management" is not a set of rules which you can learn on a course, but an attitude, once you decide to shape your team so that it is continually changing to match the shape of the problems that you have to solve, things get better. Once you start to understand concepts that are particularly pertinent to web development and not particularly pertinent to car manufacture, such as the difference between value demand and failure demand, you are in a position to give your customer what they want and to make money doing it.

Money, Money, Money

Number 5 of the 4 reasons why anybody does anything. I'm not that big a fan of using money as a way of motivating people but... Once you understand what the value is that you're delivering to your customer, you can work on getting that value to flow through your team really fast. The more value the work you do has to your customers, the more they'll want from you, the more they'll pay you.

Money Back

I'm so convinced that this course is going to help you build a better, more effective, web development team that makes you lots and lots of money that I'm offering a money back guarantee - if you come on this course and you don't feel that it's delivered what it promised, I'll give you your money back. No arguments. No hassles, no questions asked.

Money for Free

If you don't think this course is right for you, but you know somebody who it would suit to a tee. Tell them to mention your name when they book the place and I'll give you a 10% affiliates fee.

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

Do we need one?

mark.stringer@gmail.com (Mark Stringer) — Mon, 16 Nov 2009 12:32:00 +0000

When I talked about difficult conversations at Agile Yorkshire last week, the subject of "Hero Programmers" (HPs) came up. What is a "hero programmer"? Lets give ourselves a working definition. A Hero Programmer is someone who:

Is deferred to by all the other programmers
Has deep technical knowledge of the product/system.
Very busy, he works long hours, he pulls all-nighters for the good of the company – hey, he’s a HERO.
Widely regarded as indispensable by other people in the company.
Rarely takes holidays.

Sounds great. A hard-working, highly-skilled and very valuable member of the team. So what’s the problem? Well, there can be a few problems. Here are some other possible features of the Hero programmer.

Makes big technical decisions without consultation (i.e. changing the implementation language for the entire project).
Saves technically difficult work for himself rather than distributing it through the team.
Decides what features get worked on next
Regards himself as the architectural (or even moral, aesthetic) guardian of this system. And regards these ideas as higher than any mere “business” goals.
Refuses to pair program (often suggests code reviews as an alternative, though they rarely actually happen).
Rejects as a "waste of time" or a "fad" any of the basic technical improvement practices suggested by Agile: continuous integration, refactoring, Test Driven Development and even sometimes source code control.
Is DEEPLY suspicious of consultants.

Do any of these sound familiar? Is this you?

When I talked at Agile Yorkshire the subject of "Hero Programmers" (HPs) came up when I was talking about issues around identity. I talked about 5 identity dimensions which I got from this book - "Beyond Reason":

Appreciation
Autonomy
Status
Affiliation
Role

And when you think of Hero Programmers in line with these identity dimensions you can see how difficult it is to budge an HP. Along each of these dimensions, our HP is strongly rewarded. They get lots of appreciation – bosses, project managers, customers are grateful when they finally get the functionality that they want. Because the HP is the only one that can do a lot of the trickier bits of development they have the autonomy to decide what gets done, in what order. In the company and sometimes also by customers the HP is regarded with high status.

Very often, the HP's affiliations are not to the team that he works with. He may also feel an affiliation to an international band of coding gurus whom he talks to daily online and sees at conferences. To him, what they think of what he does is far more important than his work colleagues. And this brings us to his role as he sees it – keeper of the pure flame of the architectural (or sometimes even artistic, ethical) integrity of the project.

He probably gets very sniffy whenever anybody talks about money.

So, along 5 different measures of positive identity, the position of HP buries the needle. No wonder HP’s don’t want to change. From the HP’s point of view, the only direction is down. If he changes the way he works, if he gets promoted, he moves away from things that he knows (software development) to things he doesn't know (business, team-leading, management).

Do you have a problem with an HP? Here are some things you might try that I know have worked elsewhere. Most of these suggested approaches involve increasing the HPs status and autonomy rather than attacking and restricting them, which is what the usual (and greatly feared) move into team-leading and project management threatens:

Reduce the work load for the HP: Insist that he take his holiday. When he is at work, he shouldn’t be max-ed out, he should be given time to teach others what he knows and think strategically.
Turn the HP into an internal consultant – whose job is to roam between projects and solve the really hard problems.
Turn the HP into a "fellow" who's job is to think great thoughts and come up with new ideas.
Get him to talk and teach, write books, to your staff and on the conference circuit. It will be worth the travel expenses.
Turn the HP into an external consultant, hire out his specific, excellent skills to other companies.
Turn the HP into an open source guru – put some aspect of your project out in the public domain and give your HP the task of leading it.
Turn your Hero Programmer from a Code Geek into a Business Geek. A friend of mine used to write the software for the hedge fund that he part-owns, but now he involves himself far more in the minutiae of the tax laws and the mechanics of limited liability partnerships.

One thing that occurs to me is that if you keep seeing the same situation again and again, it must be a "stable" situation – what John Nash would call an "equilibrium". There are powerful the drivers are to keep somebody in this role (run through the identity list and think about the role of project manager – why would anybody want to be one?). The trouble is that it's a local equilibrium that prevents any kind of positive change. If a team that has formed around a "hero" programmer, out of frustration with this stability and stuck-ed-ness, very bad things can happen.

Yeah, yeah, he's a life-saver, but you don't have to work with him

If the HP is a founder they can be ousted in a coup by other board members. Or if the company finds finance, or is taken over, they are swiftly removed (VC’s have developed the sharpest skills for dealing with HPs through sheer necessity). Often the team or the company around the HP just evapourates, the juniors get less junior, read the writing on the wall and walk away. But these are actually good outcomes compared to the most likely outcomes in the short term.

Things carry on as they are.

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

mark.stringer@gmail.com (Mark Stringer) — Wed, 11 Nov 2009 09:24:00 +0000

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

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

Affiliate Policy

mark.stringer@gmail.com (Mark Stringer) — Mon, 09 Nov 2009 08:33:00 +0000

OK, this is my affiliate policy, which, as far as I can see is far more generous than some people's, not mentioning no names, Amazon.

It's this: if someone books a course with me and they mention your name, I send you 10% of the course fee (so with my current course: "Building the Lean Web Development Team", if you send someone in my direction, I would send you £35). If you were to send a big chunk of consultancy my way - your cut could be considerably more than that.

So please, if you know anybody who's working in web development, or trying to manage a web development team, or trying to work with a web development team, send them in my direction and tell them to mention your name.

It'll be worth your while.

If you know anybody who wants someone to help them get their web or software development teams working in a more Lean, more Agile way and needs a consultant, or coach to help them do it, again:

I'm your man

And there could be something in it for you.

Disclaimer: If I think you're doing anything dodgy, or spamming people, or trying to trick people into buying my courses or for any other reason I think that you're not being perfectly above board and honest in your recommendation, not only will I be very annoyed, I reserve the right not to pay you. Be nice.

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

Comments on John Seddon's Re-Thinking Lean Service

mark.stringer@gmail.com (Mark Stringer) — Thu, 05 Nov 2009 14:27:00 +0000

We'll cover the differences between failure demand and value demand, and how you might look harder at the nature of demand in your organisation in my course on 27th November - "Building the Lean Web Development Team"

Things I get out of this Podcast, my instinct was right. In order to get the best out of the Toyota Production System, you have to stick with the meta-principles. The details, about how to build cars of the rate of demand, rather unsurprisingly don't apply to software development - or web development.

His major insight, which doesn't attack "genuine" lean thinking, but which completely alters the way that it's implemented in software is saying that the Toyota Production System was shaped by the shape of demand. Curiously, although Womack and Jones and Taiichi Ohno talk about the nature of the economic cycle being the reason that Taiichi Ohno approached building cars in the way he did, Seddon doesn't mention this. But this is important as well. It's what I call the "Delta Blues" it's not enough to know what demand is now, or what it has been, you need to know how it changes over time. Is there a pattern? This isn't the stock market. Previous performance is a guide to future performance.

The other major, contribution of this piece which is especially important for web developers is the distinction between value demand and failure demand. I see now that the lack of this distinction has almost made a nonsense of trying to implement Agile practices in a web development environment. When you're making things in a factory in a "traditional" way, a substantial amount of the work that you do is work that you've planned to do (value demand). In web development, when I sit in on sprint retrospectives, it turns out that about half of the work that was done in any sprint wasn't planned, it was reactive to the customers need, mostly because things hadn't gone the way they should have (failure demand). A large amount of this seems to be farting about with hosting, browser compatibility, caching causing old files to still be visible. All that kind of stuff.

Seddon's point is that if you really want to improve the efficiency of your service company (and lets for now, assume that a web development company is a service company) then you have to understand and tackle the failure demand and set up systems to deal with it. There's hardly anything about this in Agile, there's nothing about this that I've seen in the writing about Lean for software.

One thing that you can do, which I'm certain is not being done, is to train the people who field the reports of failure demand in the technologies and techniques that they need to deal with the most common failure demand problems.

What Seddon says is that you have to look hard at your business and see what the crucial problems are. Then you have to try to find solutions. One of the ways to find solutions is hypothesis testing - try a bunch of different solutions, but make it clear to yourself what solutions you are trying and that they are just hypotheses.

Some counter-intuitive things that emerged form Taiichi Ohno's investigations which probably do transfer to services is that end-to-end time is cost, not activity. So many companies that I go into are obsessed with keeping their designers and programmers busy the whole time. Even some of the programmers and designers don't like to be seen to not be scheduled at capacity, or over-capacity. Some managers have seriously said to me that they don't think their developers will work hard enough unless they schedule for them far more work than they can possibly do in the time. Obsession with activity cost obscures the end-to-end cost. i

Some questions that you need answers to if you're a web development agency.

What is the normal relationship between value demand and failure demand? I.e. If a project seems to be a "£10K" value demand project, how much failure demand will it generate?
What is the nature of that failure demand? How much of it is preventable through changes in procedures?
What is the pattern of demand throughout the year? Even over the years? What can you do in times of low demand to improve the performance of the company?

Some criticisms of Seddon's approach. He's an academic. So he assumes that everybody else in the world is stupid. I think most of the people I meet are pretty smart and doing the best they can with the information they have. Telling people that they're STOOPID just doesn't work as a consultancy approach. But for me, having thought about this a lot over the last few years, his analysis is compelling. I think the division between value demand and failure demand is absolutely crucial for web development companies to understand.

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

Building the Lean Web Development Team - 27th November central London

mark.stringer@gmail.com (Mark Stringer) — Tue, 03 Nov 2009 13:00:00 +0000

This course will be run at The Hatton

This course is the v1.0 of the beta course that I ran in Bristol 6 weeks ago. Improved as a result of the great feedback that I got from that course.

Waste

This is the focus of a lot of discussions about Lean, but it's not the focus of this course. The focus is on:
* understanding what it is that you do
* which bits of that are actually of value to your customer
* how can you let them flow through your organisation quicker and more smoothly
* how can you stop yourself doing the things that don't add value

Value Stream Mapping

One way of looking at a business is an entity that creates value. A very simple scheme for reducing waste is to map what the value is that you're providing to your customers and then doing what you can to reduce, or completely eliminate any other activities which do not provide value to the customers.

Another way of improving the value stream is to make sure that value work flows steadily through the organisation with value being added at each stage. Through mapping the stream we can see how it can be reconfigured so that value added at one stage flow directly into the next stage where value is added.

With web development teams, my experience is that there can be problems here with flow of value into and out of the development team, there can be also problems with the timing of adding in design elements and content elements that are not independent from software functionality.

Flow

A central concept in the Toyota Production system is that work is carried out most efficiently if it flows through the team. It follows that this can't be done if every part of the process is running at 100% because, inevitable, the capacity of some parts of the chain will have higher capacity and some other parts of the chain will have lower capacity. The very first thing to do to improve flow through a team is to look at points along the production chain where work is building up.

In web development, this point is often testing. There are several ways of reducing this bottle neck:

* training up the whole team so that they can work in testing when there is work building up there.
* Abandoning testing as a separate function all together and relying on a comprehensive approach to Test Driven Development
* Pulling work through the system only at the rate that the lowest capacity section of the chain can deal with.
* Reducing the workload for the most experienced team members and using their extra capacity to improve the skills of less-experienced team members.

Kanban

I'm reluctant to use Japanese words when talking about Lean - as you see I've used very few - because one of my rules is that "Agile is not a license to speak Elvish or Klingon". Kanban simply ways of signalling what work needs doing and also of communicating to the team how they are performing.

Kanban is the system of signals that create flow of value through a team. One way of using a Kanban system is to create "pull" through the team so that work is only initiated when there is capacity further down the stream for it to be dealt with.

Continual Re-skilling

The rate at which required web-related skills change is extremely fast. In my experience with "old fashioned" software development there was a tendency for management to actually try to prevent its staff for from re-skilling (e.g. so that they would be available to work on COBOL projects, ADA projects, I've done them both). Now this would be an extremely dangerous thing to do - for both management and employees.

At the same time, the depth and variety of skills required means that it is very difficult for employees to acquire these skills "in their own time". One of the challenges of applying Lean to Web development is to figure out how to include continual improvement in the skills of the team into the web development process. It may be that this involves allowing some team members to work at less than full capacity (as the requirement for even flow through the process might dictate anyway) and expecting that the team members fill this time with re-skilling activities.

What is it?

One way of thinking about Taiichi Ohno - the inventor of the Toyota Production System - is that he was someone who really knew what a car factory was, what it was supposed to do, and how to make it do those things better. I'm not sure anybody knows what a web development team is (if there's only one kind of thing), what it's supposed to do, and how to make it better. I think this is really good news in some sense because people who can work this stuff out will be in a very competitive position - as are Toyota.

One of the areas we discussed here was that everybody I talked to in web development either doesn't know which bits make money, or knows that it is the bits other than bespoke web development.

Structure of "Building the Lean Web Development Team"

Session 1

Run through Lean Concepts

* Brief History of Lean and the Toyota Production System
* Value Streams, Waste and Flow
* How does Lean relate to web development

Session 2

Approaches to identifying the Value stream

Value stream mapping exercise

Session 3

Benefits of Flow

Flow and Kanban exercise

Mistake-Proofing and Poka Yoke

Session 4

What is it?

Open discussion

* Possible problems with adoption
* identification of next steps

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

Very Pleased (Again)

mark.stringer@gmail.com (Mark Stringer) — Wed, 28 Oct 2009 14:14:00 +0000

Just finished the sprint planning and review meeting. It was another blinder. We identified more problems and R [project manager] came up with a really good idea to solve one of them.
All's good... your help has been really fantastic in improving our team's process, reducing stress and making visible where we're losing profit and morale so we can improve even more in the future.

Rachel Collinson - from http://www.rechord.com/

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

Notes on Value from worskhop 14/10/09 - Building the Lean Web Development Team

mark.stringer@gmail.com (Mark Stringer) — Tue, 20 Oct 2009 09:44:00 +0000

Notes from my Beta Workshop - "Building the Lean Web Development Team".

We talked about four general areas on Wednesday:

Values
Flow
What is it?
Poke Yoka

Values

When we talked about Values we said that one of the important aspects of the Toyota Production System.

The Toyota Production System insists on seeing the world of business as a value-stream. Each activity in the value stream either adds value, or it doesn't. If it doesn't, it is a candidate for removal and reduction. The way to identify these candidates is to create a value stream map of your organisation (this is very similar to a "Brown Paper Exercise" done by many management consultants). We did this in the class and this is what we came up with:

We then highlighted the areas that we thought were adding value in the process [in red]. Then we highlighted the areas that we didn't think added value to the process. Quite a few of these were activities to do with planning and assessing the work that came in. The very radical idea occurred to us - "What if we didn't do those bits?" What if we just "Exposed our development capacity" to our clients - this brings in some of the Kanban thinking - "here are the slots, it's obvious when we're available and when we aren't." How do we figure out whether we can do a piece of work or not? By trying to do it.

When you look at things in this way, planning and estimation look really pointless. If your capacity is really obvious, then the option of figuring out how long something will take by trying it presents itself.

What are our values? I used an activity that I'd learned from reading "Sources of Power" by Gary Klein to come up with a bunch of values for the group. We wrote these on a set of index cards.

Web Developers' Values

Software engineering best practice
Customizable
We're a learning company
New People
Good solutions in non-perfect situations
Dealt with unexpected problems
Customer delighted
Generic
Flexible Code
Speed
Setting an example to other developers
Adding structure
Product
New challenge
Taking a risk

We then asked if these were the values of our customers, or our suppliers?

Customer's Values

We thought our customer's values were probably very different - this is the list that we came up with:

Easy Life
Shiny Fun Web
Rounded Corners
Blue
Verdana
On-Time
To-Budget
Free Food
Good Coffee
Regular Updates
Non-Threatening
Lack of Jargon
Learning Jargon to impress Boss

Who are your suppliers?

I'd talked to some of the people who turned up at the course - a woman who owned her own web development business and she'd told me with a shrug that she didn't really have any suppliers. After thinking about it for a while, I realised that this was very wrong. One of the things that Toyota does that makes it very different from other companies is that it has very involved, very long-term relationships with its suppliers. Here are some suppliers that you have that you might not have thought of:

Universities (supply you with staff). Universities supply you with staff. Are the universities teaching their students the kind of things that you need them to know? Are the universities picking the right kind of people to come on their courses - are they a good "fit" with the organisation. We talked about the value of having interns - I asked if anybody had ever had interns and there was a general agreement that when they do have interns, they're given "grunt work" rather than anything that might allow them to learn, or show off their abilities.
Other Web development companies (supply you with staff). People come to you from these companies - the better you know them, the better chance you have of good people coming to you from them.
Software manufacturers (Apple, Microsoft and Adobe)
Hosting. I hear lots, I mean LOTS of stories about last minute changes to hosting requirements that come from a client and derail a project. Do you have a really good relationship with your hosting supplier? Alternatively, are you permanently chasing problems with a very cheap hosting supplier?
Me, and people like me (I supply you with training and consultancy). How do you make sure that I know enough about your company to do my job properly. What sort of experience and abilities do you need in a consultant?

Value Dynamics

What are you supplier's values? How do they change throughout a project? This seems to be a crucial part of the business of web development in a way that it isn't in other industries such as car manufacture where buying the product is a quick process rather than the long, drawn out process that it can be with web development. I think a lot more work needs to be done on this, but for now, what we came up with was as follows:

Beginning of a project: What's important to customers at the beginning of a project is price and feature list, and impressive pitches.

Middle of a project: What's important to customers in the middle of a project is understanding the trade-off between features and price (although this sounds like a web developer-view to me).

End of a project: At the end of a project there are a whole different bunch of things that are now on the client's mind. Now they need to be able to show some working software to their bosses, and also, possibly some return on investment (ROI). We all agreed that if there is working software that is generating value, then the budget is much less of an issue.

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

Books that I talked about on "Building the Lean Web Development Team" 14/10/09

mark.stringer@gmail.com (Mark Stringer) — Fri, 16 Oct 2009 12:28:00 +0000

This is a list of the books that I talked about on the "Beta" course I ran in Bristol on 14/10/09. I'm writing this list out so that I can send it to the attendees, but I also thought it would be good to share it here.

The Machine That Changed The World

This is the book that started off my investigations into Lean and it's well worth a read, even though, I think Womack and Jones, who've gone on to write several further books, have changed their thinking a lot since they wrote this.

The thing I particularly like about it is the unimpressed view of western manufacturing from a Japanese perspective.

Taiichi Ohno, the Toyota Production System

The grandaddy. The dude.

I'm wary of treating any book as a hallowed text, but there's a lot of interesting stuff in this one. Even more interesting than the specific content is the approach. It take vision to look at the huge success of Ford's mass production system and say "Naw, we're not going to do that, we're going to do something different."

One way of thinking about Lean approaches is that they are a process of "Learning to See", another is that progress comes through continually looking at what you are doing and asking "What is it? What is it?". I think Taiichi Ohno might have been one of the few people ever who really understood what a car factory was.

Lean Thinking: Banish Waste and Create Wealth in Your Corporation

This is a later book from Womack and Jones with detailed case studies of several companies that have adopted Lean methods in order to improve their performance, including Porsche.

Zero Quality Control: Source Inspection and the Poka-Yoke System

Again, the main benefit of the thinking in this book is its difference in approach. This time to catching and fixing mistakes, not by yelling at staff to be better, but by working to improve the system.

Mary and Tom Poppendieck: Lean Software Development, an Agile Toolkit

I haven't yet read this all the way through, but it looks very good. The only issue that I have with it is that it's software oriented, and part of the point of the course yesterday was to question whether web development is actually software-oriented, or actually something entirely, or considerably different.

Martin Fowler: Re-factoring - Improving the Design of Existing Code.

A good book to look at when you're trying to think of Poka Yoke methods to mistake-proof your operations.

Gary Klein, Sources of Power.

Used this as a source for a value-generation exercise that we did: got people to tell stories about their expertise.

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