Agile Lab - Training, Coaching and Consultancy Blog

Wednesday, 16 December 2009 at

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.

photograph of a man wearing an " I'm with stupid t-shirt " pointing to a cat

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)

Labels: , , ,

Friday, 11 December 2009 at

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.

a lemon

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)

Labels: , , ,

Thursday, 10 December 2009 at

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)

Labels: , , ,

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)

Labels: , , , , , , ,

Wednesday, 9 December 2009 at

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:

lean concept of flow 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)

Labels: , , ,

Tuesday, 8 December 2009 at

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)

Labels: , , , , ,

Monday, 7 December 2009 at

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)

Labels: ,

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)

Labels: ,

Sunday, 6 December 2009 at

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)

Labels: , , , ,

Saturday, 5 December 2009 at

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)

Labels: , , ,

Friday, 4 December 2009 at

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)

Labels: , , ,

Tuesday, 17 November 2009 at

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)

Labels: , , ,

Monday, 9 November 2009 at

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)

Labels: , , , ,

Thursday, 5 November 2009 at

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)

Labels: , ,

Tuesday, 3 November 2009 at

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

This course will be run at The Hatton

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


Waste

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

Value Stream Mapping

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

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

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

Flow

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

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

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


Kanban

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

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

Continual Re-skilling

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

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

What is it?

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

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

Structure of "Building the Lean Web Development Team"


Session 1

Run through Lean Concepts

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

Session 2

Approaches to identifying the Value stream

Value stream mapping exercise

Session 3

Benefits of Flow

Flow and Kanban exercise

Mistake-Proofing and Poka Yoke

Session 4

What is it?

Open discussion

* Possible problems with adoption
* identification of next steps


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

Labels: , , , ,

Tuesday, 20 October 2009 at

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)

Labels: , ,

Friday, 16 October 2009 at

All the Written Feedback from "Building the Lean Web Development Team" in Bristol 14/10/09

Negative/Could do Better

  • Would like some of the examples that string it all together.  To summarise learning.  Maybe there is a good one in the books.
  • Always nice to have an agenda at the beginning.
  • Is there anything else that is diagrammable?
  • Not sure how useful the 'What is it like? What is it not like?  exercise was.
  • Attendees should come from a cross-section of an organisation.
  • More discussion needed on value dynamic, and on suppliers.  I'm not sure I'm getting it yet (I know they are different issues).
  • Feel slightly overwhelmed.
  • Would be good to hear about a team who are doing this... how you might see this working.
  • Next steps are big risks to take - help!
  • Have more questions now than answers - maybe this is an unrealistic expectation because nobody has done this before.
  • Not sure of the relevance of the "What is web dev like or not like?" section.  Maybe some poignant note with summaries of your points would be helpful.
  • I am unsure whether the point you made about roles required in a web dev team was actually answered.  So was there a point?

Good Points

  • The diagram of flow was really handy, sound.  That made lots of sense.
  • Liked all of the activities, especially like the mind-clearing ones.
  • Showed the importance of thinking outside your own values system.
  • Nice selection of further reading to think about.
  • Easily accessible course.
  • Been thinking about a few of these things before the training - good to hear it from a professional experienced guy though.
  • It's good to have a few people to get tailored adviced.
  • I like the method of teaching where you encourage students to come up with the answer themselves.
  • Some good practical steps sections where we learnt how to apply to our organisation.
  • Great to learn about processes that we can directly take away and apply practically to our own companies.
  • Definitely going to promote the idea of rewarding quick sign-off.
  • I like your analogies.  They help me understand the concepts and how they relate to my business.
  • Chance to talk about things with other people in a similar situation.
  • Value Dynamic.
  • Practical things to try out, if my staff can cope :-)
  • Mark's experience of working with difference web agencies.
  • Great ideas, inspiring possibilities
  • Value chain exercise
  • Interactive bits

 


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

Labels: , , , ,

Thursday, 8 October 2009 at

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)

Labels: , , , , , ,

Wednesday, 30 September 2009 at

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)

Labels: , ,

Tuesday, 29 September 2009 at

Seeing the Blubber for the Cows - The Vikings the Inuit

Ways of Making is a piece that I wrote a long time ago, having read in short succession Taiichi Ohno's book on the Toyota Production System and and Jared Diamond's book Collapse.  At the time I was also thinking very intensely about how the internet might change how things got made.  I realise that when I'm talking about "ways of making", I'm also talking about "ways of seeing" which is a very important concept in Lean thinking.

I find this story really, really scary.  And I think it's important to keep reminding myself of it, because it's saying that the way to save yourself can be right there in front of you, and you can still ignore it.  It also just goes to show the powerful desire that we have to carry on doing what we're doing  and how, in the right circumstances, this can be a more powerful desire than survival.

 




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

Labels: , , , , , ,

Tuesday, 15 September 2009 at

Building the Lean Web Development Team - Course 14th October Watershed Arts Centre, Bristol

This is a discussion and then an outline of the proposed Beta course - "Building the Lean Web Development Team" that I'm going to run at the Watershed Arts Centre in Bristol. As I've pointed out in previous posts, this course is still in development, so I'm offering at the cost of the hire of the hall and lunch - 50 pounds per head.


Waste

One of the central concepts in Lean is waste reduction, but waste can come in many forms. Perhaps some of the forms of waste that don't leap to mind are waste through over-production and waste that results through continual work of resources people - or machines at 100%.

In software, as in car production, a great deal of waste comes from re-work - things that are regarded as finished but which need to be returned for more work to correct errors.

On the web a lot of re-work is generated by "small stuff" discovered the testing function - browser compatibility is the one that comes up again and again - typos, broken links due to move from development to test hosting, adding unexpected text to form fields. I'd like to explore ways that this kind of waste can be reduced.

Value Stream Mapping

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

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

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

Flow

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

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

* training up the whole team so that they can work in testing when there is work building up there.
* Abandoning testing as a separate function all together and relying on a comprehensive approach to Test Driven Development
* Pulling work through the system only at the rate that the lowest capacity section of the chain can deal with.

Kanban

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

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

Continual Re-skilling

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

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

What is it?

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

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

Structure of "Building the Lean Web Development Team"


Session 1

Run through Lean Concepts

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

Session 2

Approaches to identifying the Value stream

Value stream mapping exercise

Session 3

Examples of Kanban use, in and out of software development

Benefits of Flow

Flow and Kanban exercise

Session 4

Open discussion

* Possible problems with adoption
* identification of next steps


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

Labels: , , ,

Saturday, 5 September 2009 at

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)

Labels: , , , , ,

Wednesday, 2 September 2009 at

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)

Labels: , , , ,

Friday, 28 August 2009 at

Lean conversation with @flowchainsensei (Bob Marshall)

This is an email conversation that I had with @flowchainsensei (Bob Marshall of http://www.fallingblossoms.com) Following his talk about Lean at Skills Matter on Tuesday night.

Hi Bob

Just a few thoughts on your talk on Tuesday night - I'll share these with you privately, but would actually like to post them (or some bits) as a blog post if you were OK with that.

Convincing people that you're an authority on the problem


I think you did this pretty well. Let me give you my paraphrasing of what the problem is and see if you agree with it. By removing wasted effort from a project, projects can be easily 2-3 times as productive, quite easily 5 times as productive, and possible 1000 times as productive. The bulk of project teams are manager to remove only about 20% of the waste.

Not too sure you've paraphrased what I was trying to say - although you may have paraphrased what I actually did say - or more importantly what you and some other folks heard at the time... :} For the avoidance of confusion though, please allow me to recap:

The problem (as I see it) is that people in tech businesses across the board, but particularly people in positions of "responsibility" don't realise just how much time, effort , money, human potential, etc. their businesses are wasting presently just doing "business as usual". This lack of realisation stems, at least in, part from a lack of awareness of just how much more effective some (few) organisations are than their business is.

So the typical (near-median) organisation is wasting around 80% of all the effort, etc. it's putting into developing software-intensive products and services. Every day.

Note in particular my focus on life (and effectiveness) at the organisational level, as compared to the project level - where most of the agile folks, including the industry's thought leaders, tend to dwell. Indeed it is my assertion that organisations cannot get past x3 on the Rightshifting scale by optimising at the local (project) level.


Convincing people that you're an authority on the solution


The result of this claim from the audience was "OK, who are these people. What are they doing that is so different?" I think here you were missing war stories. Don't you think, this is a substantial part of what people want to hear from a consultant? I think here, people would want to hear about super-performing teams, especially super-performing teams inside big organisations that didn't bring about their own destruction or removal. I think you could have "Landed the plane" if you could have had some good war stories about teams that were around 100% phase, you, or someone else suggested they do some stuff and then they moved to the 200% phase. then they got stuck, then some crisis happened and they realised that they could move to the %500 phase, and now they've all retired to the Maldives.

You're so right about the value of war stories and how these help people relate, engage. Unfortunately there just aren't many (any?) of these stories to be had. At least, I can't find them - not about highly effective organisations anyhow. One or two do spring to mind (Motek, GE Engines North Carolina) so I'll remember to mention these in future. And of course there's FlowChain - which is more a work of Science Fiction than fact at present, but hopefully a compelling story nonetheless. Hope to do a FlowChain session soon.


"The System"


If the system isn't the people, then what is it? You might have a very good answer to this, but I don't think you made this clear. I think you can image what this might be for a Ford-style production line, but in the TPS, surely the people and the knowledge and practices that they have are an integral part of "the" system. I think I read an article in the Economist which cited the lack of sufficiently-trained sensei as a reason why Toyota have stumble as they became world's biggest car producer.

Also, I can understand that there's a tier or management that needs to look at the organisation as a "system" and to some degree not think about the individuals and their talents - this wasn't your audience here. These were people inside the system.

I like to think I have a good answer to this. Thanks for point out my lack of clarity here. Ben and David Joyce have been talking about introducing folks to Deming's Red Bead experiment btw. And Martine Devos is looking for helpers to devise a Lean game to this end too. In the same way that a "team" is people, but more than just the people, for me a "system" of work is a similarly distinct thing.

And no coincidence that I'm FlowChainSensei :)

As for the demographic of the audience, yes my message has most value for executives, and they just don't go to these kind of events. I'm speaking at a Valtech event at the end of September where the the demographic might be more closely aligned. But I disagree fundamentally that people inside the system should not concern themselves with that system.


Books


You mentioned a lot of books. This is good for me because I read a lot of books, but many people who can read chose not to - especially, the kind of people who buy consultancy and attend talks and training. You can't answer their questions by pointing them to a book. I (ha ha) read somewhere that people divide into how, why, what and what if. I think there are readers in all those categories but readers tend towards the "why"/"what if" categories. I struggle especially with "how" people because the only way that you can get through to them is to actually physically get them to do it themselves. You can give them reasons until you're blue in the face.


I point people to books as a short-cut to me taking time to explain a certain topic, issue, subject or solution. Not that I resent the time necessary for effective explanation, (just the opposite, in fact) - it's just that in a time-limited session like Tuesday, I prefer to cover ground rather than dwell on one thing for too long. Agree with your observation about "how" people. Although I'd say that most people are "how" people to some extent.


I think if you want to reach everybody you need some kind of activities that let the "how" people feel what it's like to make processes more effective in a Lean way. "What" people are in some ways even more difficult, because they want to know exactly what they should do in their own situation. This is made even harder since I got the feeling that many people in the audience were middle-level people in big organisations. What's the one thing they can do to improve their team and make the organisation more Lean?

Agree with your point about activities. I like practical workshops with games, simulations, etc. Again a time thing (although maybe that's too glibly dismissive an answer? - for which I apologise). What's the one thing? In my opinion: Learn to see waste (or in TOC terms, learn to see bottlenecks). Hence one justification for the Rightshifting "campaign": To present people with the mere possibility that there could be much more waste in their organisations that they've heretofore realised / considered / conceived. Once someone accepts that this possibility exists, they may just be inclined to keep an eye out for waste.


If this is so great, why isn't everybody doing it?


I wasn't convinced by your explanations of why the hump is focussed around 20% efficiency. Is it really "inertia" or that "people are just stupid?" Do you really have to bomb a country flat and then get control of 90% of a country's capital in one room before you can make a change (as Deming supposedly did with Japan)?

Honestly, I just don't KNOW why organisations (and more relevantly, executives) are prepared to tolerate 80% waste (or more) in their organisation approach to software and tech product development. Other aspects of organisational ineffectiveness are less tolerated, I'd say. So why is the problem so acute in our "profession"? I have a coherent theory (see "Current Reality Tree" document http://www.fallingblossoms.com/opinion/content?id=1003 on my website), which involves a number of factors. And Rightshifting is my solution.


One way that I think about this is to think that however appallingly an organisation works, there is a sense in which it's "working perfectly" that is, it's in some form of equilibrium. Of course, one way to shift an equilibrium is to create a crisis, but another is to gently change a whole bunch of things until a new, higher stable state suddenly reveals itself - Jeff Sutherland talks about these "punctuated equilibria". Again, I think this might be rich territory for a set of "calls" to action for mid-level people. How can they move to make the ground more fertile for a shift towards being a Lean organisation. Otherwise, there's a danger that the message is "you can't get there from here."

Agreed. And the most common equilibrium state is generally round the 80% waste mark for tech businesses. :(

I many organisations I have seen, I truly believe that they "can't get there from here" - and their only future is to remain at their present level of equilibrium and hope that their left-drift remains slow enough that they can stay in business.

I think we have to accept that organisations generally have a (latent, hidden) reason for being, often far removed from their ostensible purpose of making a profit, or whatever. And often, that latent purpose is dysfunctional (from a societal point of view, not least). In people we call the resulting discomfort "cognitive dissonance". I'd go so far as to say that in organisations, the result of such dysfunction is ineffectiveness.


Regards,

Mark.

PS Lets meet up and chat soon.

Would love to! Just not this week - too much Python to do, deadline approaches! :)


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

Labels: , ,

Tuesday, 25 August 2009 at

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)

Labels: , , ,

Thursday, 16 July 2009 at

Trying to Understand Kanban in Software

I was very interested to hear Karl Scotland's talk yesterday at Minispa2009 about Kanban. I think he's a addressing some very important issues, but as I've said on Twitter, I wasn't quite convinced by his talk. I think he's nearly there and can't quite make out whether the problems are in my understanding; his communication; or in the actual ideas themselves. Anyway, here are some notes on things that I think at the moment are an issue.

Software components aren't car parts

One of the way I try to explain stories when I'm doing agile training or consultancy is that stories are stories. A story is an out-of the ordinary situation which needs resolution. It's news. Software development spends most of it's time dealing with "Man Bites Dog" cases because "Dog Bites Man" cases are already catered for in the language libraries and the API. Software people, project managers and the people who support them with training and consultancy are all what Peter Drucker called "Knowledge workers". Ironically, that means we spend most of the time NOT knowing what we're doing. I'm not sure how well this fits with manufacturing car parts, or assembling cars.

Toyota Production System is a "That would never work for us" method

Anybody who has ever tried to advocate any kind of project management method to someone in an organisation will be familiar with the "That would never work here, that would never work for us," response. What isn't perhaps discussed so much is that exactly that attitude is the root of the Toyota Production System from which Lean and Kanban ideas are extracted.

As I understand it from my reading of Taiichi Ohno's book and from reading "The Machine that changed the world." One of the original spurs for the Toyota Production Method was an understanding that the way that Ford made cars wouldn't work in Japan. They simply couldn't make enough cars to get the economies of scale that Ford (claimed) he was getting. Another realisation was that Japan's demand for manufactured goods was extremely cyclical and so Toyota needed a method that could "smooth" out these oscillations in demand. But Ford's model of hiring and firing low-skilled workers as the need arose simply didn't fit with Japan's cultural understanding of what work was. People worked for the same firm and stayed loyal to it all their lives. Enormous value was placed in the deep knowledge and mastery of skills. Toyota decided to put together a system valued skilled workers and held onto them through all stages of the economic cycle.

This is what I don't see in Lean and Kanban approaches to software. It doesn't say "We need to design our own Toyota Production System that reflects our culture, values and economic cycles," rather it says "we need to use theirs!".

Flow vs frame. How do you know what you're capable of?

This maybe not so much an objection as a lack of understanding. I didn't quite understand what Karl meant by the term "cadence". It seemed to be something like an iteration, but of variable length. I sat up and paid very close attention at this because one of the things that you're always asked when consulting and training about Agile methods is "How long should iterations be?" And so some kind of rule - even a rule of thumb for working this out would be interesting to know about. But at the same time I'm worried that giving up on the idea of fixed-length iterations, results in the loss of information about velocity. And one of the things that I think is vitality important about Agile methods is the ability to get better and better understandings of what you're capable of as a team.

Another way of thinking of iterations is a frame that you put around the work that would be getting done anyway that allows everybody (developers, project manager, clients) to talk about it in an different way, to reflect on progress, to decided on changes of emphasis and direction.

The aim of these comments and objections isn't to dismiss Kaban/Lean approaches because I think they would be particularly well-suited to settings such as web development agencies, where the work tends to turn up in a continuous flow and doesn't necessarily fit itself into time-boxed. Iterations.

Thanks to Karl for an interesting talk.

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

Labels: , , , , ,

Thursday, 6 September 2007 at

Agile, Lean, Kanban feed


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

Labels: , ,

Tuesday, 19 June 2007 at

Agile Lab Courses

Scheduled Training Courses


Date

Title

Location

Fee

Contact

Wednesday 20th January 2010

Building the Lean Web Development Team

The Hatton, Central London

£350

Email mark.stringer@gmail.com or phone 07736 807 604 (book online)

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]