Wednesday, September 08, 2004

Anti-pattern : Code Rewrites

In Feature Driven Development, we use code reviews as a method of quality assurance and team learning. Feature Teams form under a Chief Programmer to develop a batch of Features in a Chief Programmer Work Package. The purpose of batching is to absorb the overhead - what Paul Szego termed “administrivia” - in a Feature. This would include the domain walkthrough which requires resources to be scheduled, as well as project tracking meetings and the design and code reviews. Doing this on a Feature by Feature basis would be cumbersome and inefficient. CPWP’s enable efficiency in the development tasks.

The code review is intended to be executed by the Feature Team and allows each of the team to learn from other members how their code works. It propagates the best knowledge of the entire project in terms of architecture, design patterns and coding guidelines and the result is both quality assurance (reduced defects and high internal quality) and learning. The code review process helps to raise all the developers on a team to the standard of the best.

Some who believe they are running FDD projects let code reviews degenerate into Chief Programmer code re-writes. In this form of review, the CP simply takes the code off each Feature Team member and re-writes it with them in a pair programming fashion. This may deliver the desired quality assurance in terms of reduced defects and improved internal quality. However, it will not deliver the desired learning and it will not raise the standard of the team to that of the best. Rather the effect will be to freeze learning and stem further improvement. Furthermore, the process of code re-writing is demoralizing. The long term effect will be to undermine trust and respect in the team. Developers will lose the sense of pride in their work and the result will be greater defects produced at a slower velocity. Resentment against the chief programmers may develop and the team will over time become dysfunctional.

Code re-writing may seem like a good idea. It is simpler to schedule and uses fewer resources. It may also seem efficient and psychologically pleasing to the geekier of chief programmers. But ultimately it is soul destroying. It eats at the core of a project team and destroys its ability to create value. Peer reviews may be hard to do properly but code re-writes are not the answer. If you can’t get peer reviews right for whatever reason then go the whole way to the other extreme and pair program. It has the same effect - improves external and internal quality and enables learning. It also encourages developers to take pride in their work. Pair programming does not carry with it the demoralizing side effect of the code re-write by the super uber-being of the arrogant chief programmer. Chief programmers have a responsibility to lead and leadership in knowledge work means in part teaching. A chief programmer who does not teach is not a chief programmer just a team lead directing others.

Tuesday, September 07, 2004

Drucker on Adaptive vs. Plan-Driven

I’d didn’t get through my posts on the work of Peter Drucker in August. I simply ran out of energy and fell off the blogcycle. So Drucker month runs over into September. Hey, we’re adaptive at agilemanagement.net

Peter Drucker doesn’t like planning much. Here is what he had to say in 1996 writing in “The Effective Executive,”

“Most discussions of the knowledge worker’s task start with the advice to plan one’s work. This sounds eminently plausible. The only thing wrong with it is that it rarely works. The plans always remain on paper, always remain good intentions. They seldom turn into achievement.”

Drucker also had something to say about adaptive process versus plan-driven processes back in 1985 when he wrote “Innovation and Entrepreneurship.” He completely predicted the shift to agile software development methods and adaptive just-in-time planning.

“‘Planning’ as the term is commonly understood is actually incompatible with an entrepreneurial society and economy….innovation, almost by definition, has to be decentralized, ad hoc, autonomous, specific and microeconomic.”

Drucker’s argument is based in the idea that in a knowledge worker economy, a competitive edge, a differentiator, is achieved by bringing new ideas to market faster. This is similar to Patterson’s concept that product design is a process of information discovery - in other words knowledge creation - and Reinertsen’s later observation that design in process is perishable. Drucker was basically arguing this in 1985. He had worked out that innovation was a product of knowledge creation from knowledge workers and that such knowledge had a half-life. Because of this the nature of the economy was changing and the paradigms, we had used to manage the old economy of mass production, were obsolete.

Wednesday, September 01, 2004

Four Roles for Agile Management

This paper first appeared in the July 2004 edition of The Cutter IT Journal. It replaces Chapter 8 “The Agile Manager’s New Work” from Agile Management for Software Engineering. This new writing, effectively a second edition of the original chapter, incorporates some newer thinking in Statistical Process Control and Six Sigma which first appeared as concepts in Chapter 32 “States of Control and Reducing Variation.”

Abstract

In Agile Management for Software Engineering [Anderson 2003], I introduced the idea that there are four roles for managers of agile projects and that all four roles have to be filled before a software engineering team can reach its agile potential. The names of the four roles were not new - product manager, program manager, project manager, and engineering manager - but their responsibilities were carefully defined to maximize the agile potential of the organization. Although they were described as roles and in theory one manager might be capable of filling all four, the reality is that each of them requires different skills. Hence, there is room for specialization, and it is unlikely that any one person will be good at two or more of the roles.

This article provides a definition of each role and explains why the separation of roles and responsibilities makes sense. The explanation is founded in a combination of management theories for continuous improvement, including the theory of constraints [Goldratt 1984, 1997], statistical process control [Wheeler 1992] and some derivative work in quality assurance by Edwards Deming, all of which provided the underlying theory for Six Sigma.

Download The Four Roles of Agile Management [PDF 2,234KB]