Friday, November 04, 2005

Drucker on agility and testing

The other day I picked up a copy of "The Daily Drucker" from the local library. It was again one of those fortuitous events, almost as if the book told me to pick it up from the shelf. I had another similar experience last year at the same library when I picked up "XP Explained", so I think it's particularly fitting to find references to agility and testing in Drucker's ideas. I don't think Peter Drucker needs any introduction, but I have to confess I haven't read any of his books yet (although this is about to change!). "The Daily Drucker" is a collection of fragments from his books, put together in "a thought a day" format that's pretty agile in itself :-)

Here's what Drucker has to say on organizational inertia: "All organizations need to know that virtually no program or activity will perform effectively for a long time without modification and redesign. Eventually every activity becomes obsolete."

These are sobering words that can be applied verbatim to software development (note the use of the word 'program' in the above quote!). They say that you must be prepared for change, and indeed welcome it, as XP teaches. In fact, in the same fragment (from "The Age of Discontinuity", Drucker goes on to say: "All organizations must be capable of change. We need concepts and measurements that give to other kinds of organizations what the market test and profitability yardstick give to business. Those tests and yardsticks will be quite different."

Note the use of the word "tests". To apply this idea to software, you can't prove that your application is capable/performing if you don't have tests and yardsticks. Again, an idea that appears over and over in agile software methodologies. Here's Drucker again: "Each institution will be the stronger the more clearly it defines its objectives. It will be more effective the more yardsticks and measurements there are against which its performance can be appraised. It will be more legitimate the more strictly it bases authority on justification by performance." You couldn't give a better justification for having unit/acceptance/performance tests in place for your application even if you tried :-) !!!

I was also struck by some of Drucker's ideas on abandoning what doesn't work. It reminded me about the virtue of courage in XP, which gives you the fortitude to throw away code and start anew, knowing that you'll probably do a much better job. Here's Drucker: "Without systematic and purposeful abandonment, an organization will be overtaken by events. It will squander its best resources on things it should bever have been doing or should no longer do. As a result, it will lack the resources, especially capable people, needed to exploit the opportunities that arise." It's almost like Drucker is talking about the YAGNI principle and about Big Design Up Front. The alternative, of course, is to Do The Simplest Thing That Could Possibly Work. In fact, according to Drucker: "The question to be asked - and asked seriously - 'If we did not do this already, would we, knowing what we know, go into it now?' If the answer is no, the reaction must be 'What do we do now?'" In XP, we know what to do now because we have the current iteration to work on, having obtained feedback from the customers.

Drucker talks of course about feedback too. He associates it with 'continuous learning' (another agile concept) and he advises everybody to write down the results they anticipate before doing anything of significance. Then, after a number of months, they will feed back from the actual results to the anticipations. This accomplishes three things: firstly, it shows you what you did well and what your strengths are; secondly, it shows you what you have to learn and what habits to change; and thirdly, it show you what you are not gifted for and cannot do well. These are the keys to continuous learning, and it seems to me that they're used very effectively in the agile practices of test-driven development, continuous integration, constant feedback and frequent iterations.

Finally, Drucker has something to say about agility itself: "Large organizations cannot be versatile. A large organization is effective through its mass rather than through its agility. An organization, no matter what it would like to do, can only do only a small number of tasks at the same time. This is not something that better organization or 'effective communication' can cure. The law of organization is concentration. Yet modern organization must be capable of change. Indeed it must be capable of initiating change, that is innovation. It must be able to move scarce and expensive resources of knowledge from areas of low productivity and nonresults to opportunities for achievement and contribution. This however, requires the ability to stop doing what wastes resources." The lesson for agile development? Keep your teams small and focused, encourage an environment of collaboration and freely flowing ideas, don't pidgeon-hole people into roles, be prepared to react quickly and to throw away what doesn't work.

I am amazed by the depth and breadth of Drucker's ideas, and about their direct applicability to software development. My TODO list has just been augmented with "Read at least one Druckerian wisdom nugget every day".

No comments:

Modifying EC2 security groups via AWS Lambda functions

One task that comes up again and again is adding, removing or updating source CIDR blocks in various security groups in an EC2 infrastructur...