A rational voice in the sea of noise about agile development

Alan Shalloway made a post to the [leandevelopment] forum that resonanted with me.

1. The people aspects of development are more important than anything.
2. That being said, there are rules (of the nature of soft dev) that people need to know.
3. The system people will in can help improve their behavior (and this is neglected in sw dev a lot)
4. Much improvement can be made by people knowing what to look at
5. Knowing what to look at (e.g., flow instead of how productive people are measured by how busy they are) can be used to gel people
6. You can’t get trust by working directly on it – in other words, saying trust us doesn’t cause trust
7. Systems include a doing and a being aspect – they are inseparable
8. The foundation of Deming is respecting people and attending to systems
9. The foundation of lean is Deming + just in time and automation ( so respecting people is foundational)
10. People learning lean tend to ignore the people aspects of it and translate lean into tools – this is not good and is something anyone teaching lean has to attend to – but it doesn’t make lean tools
11. Although the software dev system is a complex adaptive system, one can get macro-prediction out of it
12. Putting people in good systems results in better results than putting people in bad systems – so attending to the systems will help the people’s behavior
13. Trusting in your environment without demanding people always think is a sure way to fail
14. Management demanding people work a certain way is a sure way to fail
15. People talking to each other improves the interactions and learning of people.

I'm especially connected with notion of a "system," which included people, processes, and tools. This is my Systems Engineering paradigm. This also means that the people, processes, and tools each have to be "tuned" to work in the domain and context (the problem in the domain). By tuned it means there must be Measures of Effectiveness and Measures of Performance produced to provide feedback for correction action to the system.

These two measures have some simple definitions.

This approach provides the mechanism for connecting the dots between people, processes, and tools. The question can be asked "is what is being proposed supporting the best outcome for the system or project?" One source of guidance can be found in Theory of Effectiveness Measurement.

One thing that drives me nuts about the agile community is that the loudest voices come from those with most anecdotal experiences. "Hey it worked for me on my little project, so it must work for you." "Oh yea, what domain to you work in?" The paper above is one of 100's of research sources on the application of processes, methods, and their measures of effectiveness. Add to that a fully formed set of theories around System Engineering and you'll start to see that advice masked as anecdotal experience is just that "masked."

Anecdotes have their place, but they are just that anecdotes. Quotes from populist magazines are in the same class. Ask for validated, independent review of any idea that proffers a new idea. Ask where it has worked outside the personal experience. This is how decisions are made when you're spending someone else's money. If you're spending your own money - have a ball.