One of my (enlightened) bosses said that one of the biggest lie of modern management was that you could supposely manage software development like you do with a factory.
This world view is called Taylorism or Scientific management; in Taylorism, mass production is obtained by chopping up jobs on to an assembly line, and training specialized workers that locally optimize their performance. Put one hundred workers in a pipeline, where each of them performs the same repetitive operation, and you can build hammers or cars very fast, and not spend too much in salaries.
As we know today, viewing a team as a factory whose output is software is a false comparison: the work of developers is comparable to architecture and design even at the single-line-of-code level, while the repetitive, physical building is only comparable to the automated build running in Jenkins.
The Lean assumptions proposed by the Poppendiecks are instead:
- a mature organization optimizes the whole stream from requirements to deployment. This whole system view is in opposition with the divide et impera approach of traditional software engineering, where the team's function are divided into strictly separated compartments: you can only get requirements from an analyst, and you can't even touch the servers as software must pass from QA and system administrators.
- A mature organization distributes learning and control between the people who accomplishes the work; again, this assumption contrasts with traditional software engineering where planning and execution are kept separate, along with design decisions and coding.
After this digression on Taylorism, you now know what is the rationale for the tools presented in this part of the series: empower a team to make decisions and reach a global optimization.
You cannot push practices
The Poppendiecks present several case study where the supposed best practices - coding standards, automated builds and unit testing - were replicated along different teams after the successes of a pilot one. This happened out of our industry too - as GM tried to replicate Toyota's practices in their factories.
It is at best dangerous to blindly copy practices in a different context, but it fails at the people level too: no one likes to be be told how to do his job.
Automated testing may seem a panacea and a must for you, but no matter how this or other practices seem appealing, transporting them on other people is not going to produce the same results. There is certainly a correlation between their usage and results, but both are caused by the knowledge of principles and values in your team that brought out these practices.
Thus, I test-drive code in my current projects because it stops bugs from reaching production and helps me improve the design. Forcing someone with less motivation is going to make him test wiring code (or entire webservers and databases) for the sake of coverage, or to build procedural monsters just because they can be easily automatically tested, and so can't have a problematic design.
The alternative to picking practices and throwing them at someone else - who probably knows better how to do his job than us - is self-determination.
Have you ever wondered who designs expenses reports forms? They are usually push from one dedicated department to the others, but the very people that compile them to get reimbursements for travel and accomodation never have a say into their design. Of course accounting people have their merits and domain knowledge - but the result is often a nightmare when it comes to compiling one of them.
The self-determination solution is to involve the users of this reports - everyone who writes or reads them - into their design. On a more general scope, involve everyone who performs an activity into the design of the process for performing it. Proposals should come from the developers closer to the actual work: it's not a manager or consultant teaching a programmer how a feature should be transformed from a story into reality, but a conversation where the programmer tells the boss how to let him do his job.
Before you say that this is obvious, how often have you seen this applied systematically in a company? Self-determination however provides advantages on two levels:
- on the technical level, you get working knowledge from the field. No one-size-fits-all process will work in every team in the company without allowing for customization.
- on the people level, the motivation provided by choosing your own approach to work is even more important. At the implementation side, a developer feels empowered as he knows he is given authority (to choose its practices) and responsibility. At the manager/product owner side, excuses are removed: no one can come up to you and say he would be able to deliver if it weren't for that useless dance of documents he had to update.
Imagine a world where developers picked TDD or formal requirements (or Java vs. PHP) as they recognized them suitable to the current project. For this to happen, self-determination is not enough: imagine a team of trained (or untrained) monkeys that type on keyboards. :) We'll see other Lean topics for empowering the team in the next episodes of this series.