Many thanks for reading the blog and for your comments. I agree with you that the “too much / too little” process pendulum that I described in my blog is definately far from new. I personally think the pendulum is currently swinging ever wider and the debate very much cenre stage thanks to the radical rethinking that the agile school brought and the push now to further propogate its benefits at scale and in the mainstream. I also passionately agree that we need standards and rules. What we need to find in software development is the same kind of acceptable balance between constraints / responsibilities and the individual freedom needed for creative progress that we strive for in society as a whole. There is probably no one magic formula for this and it will always be to some extent be a shifting balance of tensions and compromises. I also agree that ivory tower process is fundamentally ill-conceived and that shared / standard practice should always be based on many years of shared and refined experience. Finally I agree that people are the ultimate key – they are the one true source of all new software solutions and the value these deliver. Truly great people are however by definition in relatively short supply, as are tuly great teams. They are also grown, not born. The problem for process for me is how to we make great teams out of the mix of people at our desposal and how we get many of these teams operating effectively within broader supplier organsiations to the meet the larger goals of both supplier and customer. In my future blogs I will be talking in more detail about some process concepts that I have found useful in this regard.

These ends are everywhere. For example, if no rules were applied in traffic, there would be a terrible disorder and damages, and if too much protecting rules are applied, the traffic would die down. Or if we had not rules in the society, the same happen.

In the development world it is the same in many situations. If we don’t apply a structured architecture analyses, the integration will almost newer be finished, and not with enough quality. Or if the project leaders don’t push his nasty rules, nothing would be finish.

The important is to get the rules and processes right. For me, this is much about knowledge and understanding. If a process is developed by bureaucrats, unsuitable for operative development work, the process gets poor. And the reverse, if highly talented engineers bring together a scientific approach with real practical stomach feeling, there is hardly any limit for process efficiency.

The problem target management and company leadership to select the right people to hire. Or for an employee to select the preferred company to work on. But don’t blame the process, it can go wrong or right like anything else can and does.