Impl Lean SW Development: Will it make me, as a developer, more productive/efficient?

[Svend Rost]

This Lean thing sounds nice. As I understand it, it's a method to improve
the productivity.

Will your book teach me, as a developer, ways to become more productive
or are you dealing with issues at a more coarsegrained levellevel? i.e.
a number of tips/ideas to be productive as an individual opposed to how
to make the development department more efficient as a unit.

Thanks in advance,

/Svend Rost
[ November 09, 2006: Message edited by: Svend Rost ]

[Frank Carver]

One of the pillars of a lean approach seems to be to communicate goals rather than instructions and push responsibility down to the people doing the work. An implication of this is that improving both team and personal productivity at reaching these goals is exactly how overall effectiveness is achieved.

I would therefore hope that the book at least references sources for this sort of improvement, but ideally covers this in more detail. This is an area where the overlap between Lean and Agile pays off, though. With more responsibility and freedom to achieve goals comes more flexibility to use agile approaches. So reading (and practicing) agile methods is a suggestion which can be used straight away.

[Peer Reynders]

Originally posted by Frank Carver:
One of the pillars of a lean approach seems to be to communicate goals rather than instructions and push responsibility down to the people doing the work.

This has an eerie parallel in military history: Directive Control (Auftragstaktik) versus Command and Control (Befehlstaktik).
Ultimately Directive Control tends to achieve more with fewer "resources" - however it can only be successfully conducted by teams comprised of highly-motivated, highly-trained and highly-skilled team members.
(The first Lean Development Book does make reference to David Freedman's Corps Business: The 30 Management Principles of the U.S. Marines)

Which raises an important issue: Is the availability of "highly-motivated, highly-trained and highly-skilled team members" to most constraining factor for lean and agile methods, possibly even their Achilles heel? In commercial life "highly-motivated, highly-trained and highly-skilled" people are always in demand and therefore come at a premium.

Do agile and lean methods actually improve or elevate everybody to the level that is necessary for lean or agile to work? Or do agile and lean methods simply create an enabling environment by removing the obstacles for the teams that would already be relatively productive and efficient if they were left to their own devices?
[ November 09, 2006: Message edited by: Peer Reynders ]

[Ilja Preuss]

Originally posted by Peer Reynders:

Which raises an important issue: Is the availability of "highly-motivated, highly-trained and highly-skilled team members" to most constraining factor for lean and agile methods, possibly even their Achilles heel? In commercial life "highly-motivated, highly-trained and highly-skilled" people are always in demand and therefore come at a premium.

Do agile and lean methods actually improve or elevate everybody to the level that is necessary for lean or agile to work? Or do agile and lean methods simply create an enabling environment by removing the obstacles for the teams that would already be relatively productive and efficient if they were left to their own devices?

I'm not sure whether I'd say *everybody*. But producing something useful regularly, getting feedback from real users, closely collaborating in a team and being responsible for how you do your own work is in fact quite motivating. So I'd say that, yes, an Agile working style will likely help quite a lot getting highly-motivated team members.

And how do you get highly-trained/-skilled people? One way probably is to, well, train them. Again, Agile approaches with their massive feedback provide for a lot of learning opportunities. If you allow the team to use them - by giving it enough slack to reflect, by allowing members to pair program etc. - the team members will already train themselves quite a lot, in my experience.

[Ilja Preuss]

Another thing that you might learn from Lean ist that, if you what you are doing isn't the bottleneck, improving the performance on that task will not be of a significant help in increasing ouput of the team.

What you can do then, is helping to remove the real bottleneck.

I hope I got that right...

[Svend Rost]

As I understand it the focus is not on tools for the individual, but more
on tools for managers or teams to enable the individuals to become more
productive.

I.e. "decide late" pushes the responsibility to the developer and thereby
making him able to increase his productivity, however the initiative has
to come from a higher level than the developer. Does this make any sence?

/Svend Rost

[Frank Carver]

however the initiative has to come from a higher level than the developer. Does this make any sence?

That's one way of getting there. I'd say in more general terms that, wherever the initiative originates, everyone involved has to "buy in". It seems quite feasible for a lean approach to be initiated from "below" and propagate upward, provided that the higher levels of the organization work with it.

[Mary Poppendieck]

To answer the initial question - we have found that when developers take our course but have no way to change their environment, they get frustrated, because they can't see how to use lean principles in their world. However, when developers have some control over their work lives, lean principles provide guidance. For example: Is there a merge and regression test cycle that takes a long time and finds a lot of problems AFTER you are done developing? Quite often, the first thing EVERYONE needs to do is to establish the rule of "No Partial Credit" and work together to find and get rid of any and all problems before a code is allowed to be considered 'done'. This may not be as technical as you might be looking for, but it describes what developers should consider to be 'their job'.

On subsequent topics in this thread: I believe that in just about any instance, 'average' workers can become 'experts' with appropriate training and guidance. Consider WWII production in the US and Canada. The productivity achieved in those countries was phenomenal, and it was achieved by women who had never before considered working, men who were too old or unfit to get in the military, and minorities who had until that time been considered incapable. An extensive training program called Training Within Industry was used to teach supervisors how to do good supervision; it is widely credited with much of the superior productivity of the time. This program was exported to Japan and adapted by Toyota to their world. Toyota has consistently trained all team leads and first line supervisors how to effectively train front line workers to do their job well and improve their processes. In my opinion, this is where top performers come from.

Mary Poppendieck