Reading Mary Poppendieck’s new book “Leading Lean Software Development”, I came across area of the traits that a leader in a software organization should have.
These competencies are known to many of us who are involved in software development and more appreciated by those who have Lean background. Leaders should rise up to the level of technicality and competence required to deliver successful software. They are not only doing HR and people management functions, they should be more as advocates and coaches with considerable appreciation for technology and processes.
Some understanding about developers is summarized in the following points:
1- Developers are more like authors than translators of specs to code.
2- Implementation and design cannot be segregated. Developers continuously make critical decisions through the course of development on daily basis.
3- Developers are non-fungible. The traditional school of process management has taught us that if we institutionalize a process, then our dependency on people becomes less.
4- Developers are always learning to enrich their understanding about the business domain, technology and processes. They need to work in an environment that preserves and improves their skills and satisfy their notorious need for learning new things. High turn-over happens because developers are not able to satisfy those needs. The Open Source model proves that. It was created by thousands of unpaid developers who were willing to give free their expensive hours just to learn and produce meaning software. They could exercise “deliberate practice” to enhance their expertise and achieve excellence.
Enabling architecture: Good software architecture must support changes over time through high cohesiveness and loose coupling. These two attributes from low dependency architecture that partitions areas that change together as one group, while other areas which are insulated into separate groups.
Mistake proof process: The alternate way to writing specs is to write them as acceptance test cases which are intended to test end-to-end features. This will avoid inconsistencies in the interpretation of software specs by testers and coders. This gap in understanding is the cause of many failure in software development as testers have a different understanding from that which the developers had when then produced the software.
Evolutionary development: Development is structured as small discovery iterations which have the purpose of experimenting and to prove something. The learning from every iteration feeds the next one. The construction of iterations is done so that we can fail fast, and therefore to understand the weaknesses and resolve them. Every iteration has three phases ethnography, collaborative modelling and quick experimentation.
Technical expertise: Robust design can only be produced by motivated developers with deep technical expertise as noted in the beginning when we talked about developers.
Iterative development: Software development is done in iterations starting with highest risk and highest priority features. Early iterations are looked as experiment and the code is made easy to change as system grows and more and more features are being added.
Set-based design: Design decisions are scheduled for the last responsible moment. This is the moment that default decision must be taken anyway. Meanwhile several design decisions are developed.
I will cover the rest of the areas in a future blog.