Fundamental Approach to Software Development
Changing the Way we think
Almost without thinking, we slip into standard ways of thinking. Giving people a new tool does not guarantee that they will change the way they think.
Statistics describe an industry that more often than not tries to apply new technologies without making a corresponding change in the fundamental approach to software development.
We are kind of like carpenters, who have for years used hammers to pound nails. Someone hands us a nail gun while singing the praises of this powerful new tool.
We listen to the song and dance and look at the tool. We think, I know how to use this. I've been hammering nails for year. We then proceed to use the nail gun like a hammer, pounding away with the flat side of the nail gun. Of course it doesn't work.
The tool must be defective.
Four Fundamental Principles of Software Development:
- The best predictor of success is how dedicated the team is to the software methodology. A recommended methodology imposed from above will consistently fail if the underlying team does not believe in it, and that same team may be successful when they create their own methodology.
- The second best predictor of any methodology is how well it eliminates waste. In this case I mean the topic of waste from the "Lean School" of Dr. Deming. The central purpose of all methodologies is the elimination of waste and having an insufficient process is waste.
Having too much process is waste, while using an incorrect process is waste.
- Any methodology that includes continous improvement can eventually be a great methodology.
If implemented correctly, your development methodology is constantly evolving and improving.
Of course continuous improvement is challenging, requiring 1) good goals, 2) metrics to measure progress toward those goals, 3) the ability to modify the process as needed with little friction,
and 4) the drive to do so (see rule number one).
- The software development methodology must be designed, built, managed, evolved, and evaluated by the software team and not by management.
This very bottom-up approach goes against everything that many executives learned in MBA school, unless of course they happened to
study lean manufacturing. Executive management has a role to play such as 1) assembling the right staff and other resources, 2) empowering the team, 3) communicating goals and objectives, 4) providing feedback, guidance, and mentoring.
Generally the role of top management in the lean world is to act when asked, not to command.