On Stupidity (and Web Development Project Management)

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

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.

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)

Building the Lean Web Development Team: Flow

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

1. 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.
   
2. 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.
   
3. 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.
   
4. 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.
   
5. 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)

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

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)

Building the Lean Web Development Team

20th January 2010, Hatton Garden, Central London

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

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

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

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

Click Here to Book Online

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

3 Reasons NOT to do a Web Development Project

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...

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

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)

Adventures in Agile (with me!)

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)

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

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)

Affiliate Policy

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

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)

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

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)

Towards the Lean Web Development Team

I've been reading "Lean Thinking". and at the same time, I'm trying to figure out how to put together a highly-functioning web-development team - I think there might considerable demand for one if one existed. Also, because I'm a consultant, I'm trying to figure out how I could take an existing web team and make it more like a highly functioning web development team. I wouldn't claim to be au fait with all the Lean terms, and as I've mentioned previously I still have some questions and doubts. So this is my first stab at this - any Lean gurus, please feel free to comment or correct.


I'm going to run a workshop in Bristol to investigate these ideas further. Because, obviously, these ideas are very much still in Beta, I'll run it at cost (about 50 pounds per seat). Let me know if you're interested in attending.

Lean Concept: Value Streams

The software is only one part of a website. Design, Marketing and PR integration. While there is almost always some custom software that needs to be written in a website of any complexity at all, the aim of the website is normally some kind of "human" goal, either a marketing goal, or a humanitarian goal. All sorts of value gets added to a website at many different points in its lifespan. A lot of this value is added after the website goes live and in an ongoing process.

Lean Concept: Multi-skilling, cross functional teams

It's not your skills. It's not your talent. It's the way you fell out of the Victorian hopper. The education system is still generating tradesmen who describe themselves as developers or designers or testers or project managers or salesmen (people from design agency backgrounds have a different set of titles).

Lean concept (my words, my gloss): Big pipes

Another thing that Toyota do is have high bandwidth communication with their customers (through a programme of visiting salesmen that encourages

Your first (last and only?) job is talking to your customers. How are you communicating with your customers? What aspects of that communication are valuable? How can they be increased? What aspects of communication with your customers is NOT valuable? How can that be decreased?

Your first (last and only?) job is talking to each other. If you can figure out how to communicate with each other and improve each other's skills and add value to each other's work you'll be in great demand.

How fat is your pipe? What's the fattest pipe you could give to your customer? What would the customer actually want i.e. to keep changing the design, to be able to add and remove complex features at the very last minute? Is it possible? Would your team have to work evenings, weekends, shifts? Could you organise yourselves to do that? How would you charge for it? How would you explain these charges to your customers?

Lean Concept: What is it?

One way of thinking about Taiichi Ohno, the guru behind the Toyota Production method is that he is the man who had the best understanding ever of what a factory is and what it produced.

What is your organisation? Think of some more metaphors? Hunting party? platoon? String quartet? Dance troupe? What are you making? Cakes? Cuckoo clocks? Spaceships? Fanzines? Architecture? You've got a metaphor. A model for what kind of organisation you work in, you've got a metaphor, a model for what it is you make. Are they the right ones?

Use the metaphor of an engine. What do the dashboard instruments measure? What are the dipsticks? What is visible? What should be visible? How does everybody in the team know how they're doing? How does the customer know how you're doing?

Lean Concept: Kanban, simple visual workflow ordering

Does it make sense to pull work through your organisation at the rate that it can be delivered at rather than pushing it through at the rate you win it? What things that weren't "wasteful" could your programmers and designers be doing while they were waiting for work?

Lean Concept: Waste - identifying it get rid of it

Where are you wasting your time? Overworking? Arguing? Using the wrong tools?

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

Negotiations and Web Sites

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

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

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

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