"You can't be a little bit agile"

Thanks to Bill Caputo for pointing me at this article from CIO Magazine. Two paragraphs really stood out for me:

• To become agile, everyone in IT has to understand the business inside and out. IT can't stay on top of business needs, or react quickly to new market opportunities, if it doesn't know or understand the business drivers. And just as the IT department must foster flexibility and responsiveness across a number of disciplines inside IT, companies have to promote that same flexibility and responsiveness across all their business units. Giving a stodgy business an agile IT department is like giving a fish a bicycle. There's nothing like bureaucracy to put the kibosh on agility. Agility has to be the mantra of the the company at large, and as BCBS of RI's Zink says, it has to be supported by the top executives.
• You can't be a little bit agile. You can't be agile in one area and not in another. You need agility in staffing, architecture, budgeting, governance, vendor relations and programming. And if that sounds like a lot, well, it is. But it's worth it.

The attempts that I have seen to weld agile software development to a bureaucratic business organisation have not been totally successful. The executives in those organisations would probably deny it but the lack of an agile organisational culture was definitely driven by the example that they set. (Off-topic: is "do-as-I-say-not-do-as-I-do" the opposite of leadership?)
To me the biggest challenge of being a software coach is uncovering and addressing the organisational barriers to an agile style of software development. Some of these barriers are addressable within a single team or IT department, but many of them are not. How many clients want to hear that "being Agile" is a destination that may be reachable after cultural change throughout the organisation, not a silver bullet that they can shoot their IT department with?

Time to take it slow

The Slow Food movement promotes an alternative view of the preparation and consumption of food. In their eyes fast food is the inevitable outcome of an approach to life in which people can be treated as machines and ceaseless haste has become a virtue: "We are enslaved by speed and have all succumbed to the same insidious virus: Fast Life, which disrupts our habits, pervades the privacy of our homes and forces us to eat Fast Foods."

The movement's emblem is a snail, appropriately enough: the Snail is "of slow motion, to educate us that being fast makes man inconsiderate and foolish"; since it carries its house, "wherever the Snail is, that is its home". I think that the message here is applicable beyond just food: consider for example the differences between "fast software" and "slow software"*.

Fast software is churned out for minimum cost by low-skilled staff that have few opportunities for growth or advancement. (The true cost of the production of the software is hidden from the consumer at the time of purchase.) The need for conformity to the fast software production process subsumes the individual needs or talents of the staff, and requires that different products have similar "ingredients" (tools, languages, architectures) and hence similar "taste" (user experience, fit to business need). The quality of fast software is uniformly low but the brand power of the producers maintains aggregate consumption levels. Consuming fast software brings little sense of satisfaction but it requires little effort and you can rest assured your competitors are doing the same.

Slow software is crafted by skilled teams that come together to meet the particular needs of a single purchaser. Each slow software project evolves in its own way, and each member of a slow software team is expected to bring their unique skills to bear on the challenges faced by the team. Working on a slow software project provides opportunities for team members to both pass on and gain expertise. Slow software teams make careful tool and technology choices to suit their operating environment, and pay constant attention to the needs of their users and customers. Because slow software teams take pride in their work, slow software is of high internal and external quality, and slow software producers gain new business through recommendations by satisfied customers rather than through branding or advertising. Consumers of slow software engage with the producers during the production process, and although this requires time and resources it is a rewarding experience that provides a significant business advantage.

This contrast characterises what I see as some of the essential differences between the mass-market big-consultancy approach to business systems development (fast software) and a smaller scale alternative that emphasises craftmanship and diversity to the benefit of all parties (slow software). And perhaps the pursuit of slow software is one way of satisfying the principles behind the Agile Manifesto?

* In 1607 Francesco Angelita wrote a book about snails in which he said that humans had much to learn from them: Slowness was an essential virtue, as was adaptability and the ability to settle anywhere, in any situation. By slowness, he meant both prudence and solemnity, the wit of the philosopher and the moderation of the authoritative governor. We could extend this interpretation to say that the snail takes its time as it trails along, impervious to haste and readily at home everywhere.

Postscript: Bob Martin covered much the same ground earlier this year: You don't have time not to do it right! Where did we get the idea that our companies wanted us to write crap? Aren't they paying a lot of money for this software? Aren't they going to depend upon this software for profits? Isn't this software worth a lot? If so, then why would our company want to pay for crap that slows us down? Wouldn't they rather have good clean code that keeps us running fast?... Remember, two years from now all people will see is the mess, they won't see how fast you got it done. Nobody remembers the speed, they only remember the mess. So do it right... Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills.

The iteration-is-not-a-unit-of-work antipattern

This is an antipattern that I've seen a few times in teams that are making the transition to XP or agile development. It manifests itself when organisations that are used to thinking about fixed time and scope projects draw up a release plan, typically the plan for the first release. The stories are discussed and prioritised and allocated to iterations as usual, but from that moment on the plan is treated as if it were fixed, and as if the delivery of specific stories at the end of specific iterations was guaranteed.
But of course it does nothing of the sort. The iterations in a release plan are not units of work ("these stories") but units of time ("this many days"). Trying to make an iteration into a unit of work requires that either its length varies to reflect actual effort required, or that the team is put under constant pressure to squeeze varying amounts of effort into some arbitrary time span. In the first case it's hard to track work completion properly and commitment to a release date becomes impossible; in the second case quality and morale slips and the team (including the customer) loses the ability to steer the project in a way that accomodates change.
Reflection: have you seen this antipattern? What was the outcome? What lies behind the desire for a release plan to be fixed or guaranteed? Are the other ways of dealing with these forces that would not cause an iteration to be treated as a unit of work?

New RSS feed

My RSS feed is now provided by FeedBurner - it is much higher quality than BlogStreet ever managed! (The Atom feed is available as always.) Thanks to Ade for pointing me in the right direction :-)

If design is dead then when was it alive?

[This little post has been a draft for too long. Time to let it loose I think...]

Among Mike Hill's FAQs and FUNQS from XP2004 is the following gem about the skills of developers he has met:
Based on my experience:
– 30% [of developers] need basic language training.
– 50% need OO training.

The problem is, what kind of OO training would be effective? Exposure to good designers and good designs would surely help, as would working in an environment that exposes the monetary cost / benefit tradeoff of a good design. (As Martin Fowler puts it: If you're a manager or customer how can you tell if the software is well designed? It matters to you because poorly designed software will be more expensive to modify. In my opinion I think that "to modify" means "for more than one person to work on for more than one day".) It is frustrating to keep on hearing of the confusion between the simplest design and the problems of simplistic design. Surely simple design has aesthetic qualities such as self-similarity, elegance, or coherence; whereas simplistic design is repetitive, inconsistent, and plain ugly?

This is what Alan Kay has to say about OO design and the history of Smalltalk: Bob Barton... had said in one of his talks a few days earlier: "The basic principle of recursive design is to make the parts have the same power as the whole." For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures.
Later, I sat in the room pondering the board from my talk. Finally, I counted the number of nonobvious ideas in this little program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them. The connection to literacy was painfully clear. It isn't enough to just learn to read and write. There is also a literature that renders ideas... at some point the organization of ideas starts to dominate mere language abilities. And it helps to have some powerful ideas under one's belt to better acquire more powerful ideas. So, we decided we should do design.
When, in what order and depth, and how should the powerful ideas be taught? Should we even try to teach programming? I have met hundreds of programmers in the last 30 years and can see no discernable influence of programming on their general ability to think well or to take an enlightened stance... A twentieth century problem is that technology has become "too easy". When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. Really? I hope not.

FYI: learn lean through Agile Scotland

The Agile Scotland group have organised for Mary Poppendieck (author of the excellent book Lean Software Development) to give her "Implementing Lean Software Development" course in Edinburgh in October.