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)

Do you speak organisation?

Having gone to Andy Murray's Prince2 refresh talk at the BCS, I'm starting to think that the issue between Prince2 and Agile might be slightly more subtle than I thought. Prince2 is a method of talking to organisations.  Agile is a set of methods for delivery, especially for software.  Both methods claim to be able to do the job of the other.  Both are bluffing.

Yeah right, I know, Scrum of Scrums.

Also, as far as I can see (my knowledge of Prince2 is very sketchy) there's nothing in the method to say how you actually get the work done, so what's to stop prioritised lists, Kanban-style displays of work in progress and strict limits to how much of that work is in progress?  I think this is what the guys at e2x were trying to tell me last time I talked to them, but I wasn't ready to get it.

Maybe Prince2 is a bit like Old Entish. Maybe arguments between Agilistas and the gentlemen of Prince2 is a bit like the battle between materialists and idealists in philosophy of mind.


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

David Anderson at #XTC (and the Magical Number Seven)

Great to hear David Anderson speak about Kanban at #xtc. Will be giving the Limited WIP site close attention.

One thing he said that I really did like was that you should try to optimise the process that's already there. You should do this by reducing the work in progress before you start to try to introduce any other changes to the process - like Agile. His idea was that this approach results in much less resistance than wholesale change. As an Agile coach and consultant, I've definitely experienced the resistance, but also there's contradiction implied by trying to change people to an iterative process all-at-once which I think this might address.

One thing that occurred to me - which I'm sure has occurred to many other people was the apparent connection - between limiting work in progress and the "The Magical Number Seven, Plus or Minus Two."

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

Free (and Nearly Free) Stuff!

Agile Lab is giving away free stuff.

Here's the situation.  The more that I've read about Lean, Kanban and Taiichi Ohno and the Toyota Production System, the more convinced I've become that there's a way of using these ideas to create a web development agency that would be massively more efficient and productive than most of the ones that I've seen, even ones that have adopted Agile methods as fully as they possibly can.

But my ideas aren't properly developed yet.  I'm reading everything I can about Lean and Kanban.  I'm talking to people who are doing this stuff inside their organisations. I'm listening carefully to the war stories of others who are trying to introduce Lean ideas.  Trouble is, experiences of Lean inside a web development agency are few and far between.  Most case studies seem to come exclusively from large organisations who are developing large stand-alone software projects albeit with some kind of web front-end.  Nobody seems to have done this yet with a 'typical' web development agency that builds lots of web sites that don't just involve software, but also combine design, marketing and PR.  This seems to me a great pity, because I think this might just be where Lean ideas could be most powerfully effective.

Over the two years that Agile Lab has been running, its area of expertise and focus has been on web development agencies.  I want to work with them to understand how Lean ideas can be made to work in a small web development agency that typically has several small projects on the go and short turn-around times.

I don't think anybody has successfully applied Lean, Kanban and other Toyota Production System methods to this kind of web development.

I want to be one of the first, and I want to get there in the most professional way possible.  For me, that means without using paying customers as guinea pigs. In order to do that, I'm prepared to give away considerable chunks of

FREE

yes, that's

FREE

consultancy, to any web development company that's prepared to come with me on this journey and allow me to use details of the experience as case study material.

What's in it for you?  You get to explore the way your company works.  You get the benefits that come with bringing in an outside consultant: someone who helps you step back from your day-to-day concerns and works with you to make your company the best it can be. You also get to experiment with the ideas that made Toyota the worlds biggest and most successful car company. Ideas that hold out the possibility of allowing you to "perfect" web development in the way they other companies like Porsche have used Lean to perfect car manufacture.

Oh - did I mention the course!  Gah! I can't believe I forgot about the course!  On the 14th October 2009 at the Watershed in Bristol I'll be running a workshop course on:

Lean Approaches to agency Web Development

The idea is that I talk through the basics concepts of a Lean approach: why anybody who does web development should take any notice of a car company? Then we'll do a bunch of workshop activities to explore these ideas, this will almost certainly include a value stream mapping exercise and an exercise to demonstrate the importance of even, continuous flow. Maybe some other stuff- not sure yet.

This course isn't FREE - but it is available to you for the stunning bargain price of £50 which will just about cover my expenses and make sure people turn up.

Contact me now if you're interested in signing up.

Especially if you bring along several members of your team

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

Testing Times for Testing

Went to the Extreme Tuesday Club (XTC) last night. Talked to a couple of guys from the Big Media Company and then to a couple of guys from uSwitch.com. There was also a bloke from an investment bank (Josh, not his real name).

The bottleneck was the QA guy

Curiously, all the conversations - I don't know whether there had been a talk about it or something before I arrived - were about testing. The Big Media Company guys were doing Kanban and Kanban had shown them that the bottleneck was "the QA guy". And they were wondering how to get round this. The guys from uSwitch.com had taken what sounds like a really radical decision and just got rid of their dedicated testers. But they said that the result was that the developers took responsibility for the code. Of course, you can only really do this if you've got TDD (they were calling it BDD) in place. You write your automated acceptance tests with the business people and then you code until the tests past - a common theme from both the uSwitch.com and Big Media Company guys was that you release stuff when it's ready, you don't wait for the end of and iteration.

Testers focus on finding bugs without regard to value

Why did uSwitch.com get rid of their testers? Well, the testers weren't really on board with Agile, and one thing you have to careful of is anti-Agile diehards who bring progress to a halt, but the testers were also focussing on bugs without regard to value. The developers at uSwitch.com keep an eye on the error logs from the live site and they keep an eye on the conversion rate - how many people who visit the site actually make a purchase. If something causes the error logs to spike, or the conversion rate to drop, they're on it. The focus is on delivering value to the site. Another knock-on effect of not having any testers is that the business people, the product owners, have to "be their own domain experts". Again, another theme that emerged from last nights discussions is that there is a temptation to leave final responsibility for the product with the testers. Testers can be expected to have a detailed knowledge of how the system should work, but they're unlikely to have a detailed understanding of which bits of the system are of value to the business.

Offshore testers, are "paid by the bug"

Josh worked for a merchant bank that was still clinging to traditional waterfall models of development. He'd had some success on a few projects in introducing some Agile practices, but again, testing was a problem. In order to make sure that everything worked as it was specified, testing was done offshore and the offshore testing company were pretty much paid to find bugs. It would be very hard to expect this company to know, or to care about the business objectives of the company. So the list of bugs that was sent back by this offshore company had no prioritisation in terms of business value.

Josh also raised the problem of time with the traders being very valuable, that all the time that a trader was talking to them, he was losing money. We talked about whether the amount of time the trader spent on the software was going to be the same in an Agile project and in a conventional waterfall project. The guy from uSwitch.com told a story about some work he'd done at a previous company, where he'd traded in his desktop machine for a laptop and just gone and sat with the guys who needed the software. He'd watch what they were doing and occasionally ask them questions, he'd also get to show them the software he was writing as he was writing it.

Quick - we need a crisis!

We talked about there being no way of persuading people to go for this without actually giving them the experience of doing it. You could try to explain the benefits of an Agile/Lean approach until you were blue in the face, and it probably still would do any difference. One thing that we thought might make even a merchant bank take such an approach was if it was seen and understood that their competitors were doing something similar. We agreed that very few people take such radical approaches when they're already making money. Even the Japanese (and then only some Japanese) only tried these methods when their country had been defeated in a war and economically ruined. We discussed some ways of artificially creating these crises. The second time I'd had this discussion in a week.

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)

Agile, Lean, Kanban feed

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