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)

Getting the right project management method for Web Development

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

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)

Brownout on Agile Boulevard

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

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)

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

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)