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)