Building the Lean Web Development Team
Event Info
Description
Book online at: http://buildleanwebdev.eventbrite.com/
This is a new course which has already been run as a Beta course in Bristol and recieved extremely positive feedback.
The course is now running at The Hatton, in Hatton Garden, central London.
Lean is not about Waste
Waste 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
