Agile development is a topic surrounded by many misconceptions. Every now and then — usually at conference coffee breaks — you can hear project managers bragging about their plans for doing their next project the “agile way”. Why not, they think, leave out all the expensive requirements analysis, project planning and design? Great! Let’s do yet another death-march code & fix project, but this time with the blessings of the software industry gurus.

That’s not at all what agile development is about. As anybody knows, who has ever dared trying, agile development is hard work: it means being very systematic and disciplined all the time. Just because you don’t do all the thinking and planning up-front (as prescribed by the waterfall model), it doesn’t mean that you don’t do it at all. On the contrary. You do these activities a lot, but in smaller chunks and in phases where these activities provide the most value. Not neglecting those activities and doing them at the right time requires a good deal of discipline and stubbornness, especially when the customer won’t stop whining about the fact that the product is still not ready and that every day the product is not out will cost the company a fortune.

Ah, speaking of the customer: One element of agile methodologies is the so-called on-site customer. The on-site customer is a crucial element, if not the most important element in any agile development effort. This person knows the problem domain and the requirements best; developers can always approach him and clarify what is really needed or ask for early feedback by showing prototypes. The on-site customer also steers the project by (re-)prioritizing features, thus defining what the team should build next. But this is just one side of the coin. There is much more value in having the customer close to the developers.

Being together with the development team throughout the project, the on-site customer gets first-hand insight into the making of his product. Through the on-site customer, customers and developers can talk directly for they are not separated by walls or politics; they meet regularly and understand each others perspectives, needs and feelings. Mutual understanding is the foundation of trust and trust is one of the most powerful ingredients to a project’s success. In my opinion, this other side of the coin is at least as important as the first one.

But, boy-oh-boy, how hard is it to find someone who is willing to sit in the driver’s seat instead of just taking a taxi? Isn’t steering much more work and potentially dangerous to a person’s career than just insisting on a contract to be fulfilled? And how onerous is it to sit with us strange developer folks? People, who wear unconventional clothing and by and large don’t care much for their grooming, hate to small-talk and — if they talk at all — tell only inside jokes that no customer will ever understand, let alone laugh about.

If you ask me, that’s the hardest agile practice: finding an on-site customer who is ready to take the heat, is technically competent (is even able to write acceptance tests!) and is willing to sit together with such a strange breed like us. It’s certainly not the stereotypical suit-wearing, gelled-hair kind of businessperson that every company has in abundance.

If you watch one of those famous chefs on TV, you get the impression that cooking is both, fun and easy. A chef knows instinctively how to combine spices and how long the meat has to stay in the oven to be just perfect. That’s a clear sign of true mastery: masters have become one with their tools, materials, and processes; to a layman everything they do looks so simple.

What the audience usually fails to realize is that these chefs are not just great cooks and entertainers: they are also entrepreneurs, managers, and coaches. They usually run at least one big gourmet restaurant, they do the marketing and goods procurement, they write books, they hire people and train apprentices such that they someday can become great cooks, too. To sum it up, they are experts at their craft and possess other important skills at the same time.

Contrast this to a traditional software company, were you have managers managing people and developers doing the programming. Managers usually don’t do any coding and probably haven’t done much coding in their life. Most likely, they are the least-qualified to write solid, production-quality code. And yet they are in charge of strategic decisions, including hiring new developers. A master chef, however, is the most-qualified person to do the cooking and because of this is the most-qualified person to make strategic decisions.

In my view, a traditional non-coding software manager is a relic of the industrial age. The obvious waste is that such a manager does not actively contribute to the main asset, ie. working software. But there is more: not being a skilled software developer with first-hand up-to-date experience, a manage-only manager will face difficulties in many areas: first in finding and selecting talented people; second, in being a mentor and role-model for developers and third, in convincingly educating upper management about intrinsic software-related problems. Especially the latter weakness is a constant source for disappointment and grief in many companies.

The classic apprentice/journeyman/master model has proven timeless over centuries. It promotes people who master their craft and have the right management and social skills. Possibly the biggest advantage is that in such a system managers (“masters”) are still allowed to pursue their craft. Being able to do what one loves to do the most is good from a motivational point of view and leads to continuous dissemination of knowledge and best practices.

Have you ever heard about Cliff Young? In case you haven’t here is his story…

For those who think that running a marathon is not challenging enough, there is the Sydney to Melbourne ultra-marathon: 875 kilometers across the hot Australian desert. This race is obviously only for the best of the top athletes and it usually takes them six to seven days to complete. Having gone through the pains of preparing and running a “normal” marathon myself I can only try to imagine what a race like that means.

Despite of these apparent tortures, in 1983, a 61-year-old farmer decided to take part in this race, wearing an old army jacket and gumboots. Spectators were worried that this poor guy wouldn’t survive the first hours of the race but when he left the stadium they gave him a big cheer anyway.

The race started and as expected, Cliff lagged way behind. After 20 hours, the first runners arrived at the camp, where they took a bite, got a massage and slept for about two hours (they typically stopped for a four hour break for every 20 hours of running). When Cliff arrived at the camp three hours later, he didn’t stop — he just continued to run. When a reporter asked him whether he didn’t want to have a break like the other athletes, Cliff responded that he was here to run and not to sleep.

He ran and ran. On the third day he decided to “sleep” for 25 minutes. Believe it or not: he arrived at the finishing line in Melbourne almost two days ahead of number two.

Amazing story, isn’t it? There a various slightly different versions of this story out there, but what they all have in common is that they stop here. What usually isn’t told is that the next year, 17 out of the 18 runners even exceeded Cliff’s record — all of a sudden, they had realized that it is possible to run the race without sleeping at all.

Cliff Young won the race because he challenged existing limits. Not really hard limits, like laws of nature, but arbitrary limits.

So the question is this: is something truly impossible or do we just think it is impossible because we haven’t tried before?

Once upon a time, in the land of Foo, there was a programmer who wrote awesome code: free of defects, easy to read and maintain and yet efficient beyond compare. Everyone admired him and his works.

The word spread and the emperor was excited when he heard about the skills of the programmer. The emperor ordered him to come to his palace to work for him as his chief court programmer. The programmer obeyed and continued to write outstanding software — much to the delight of the emperor.

After some months, however, the emperor wanted to find out what exactly made the programmer so great and whether it was possible to instill his spirit into the other court programmers. So he observed the programmer and collected countless metrics. He also had the programmer attend many meetings in order to define rules and procedures for all court programmers to follow.

One day, the emperor noticed with horror that the programmer didn’t write golden code anymore; and neither did the other court programmers.

(with apologies to Aesop.)

“On arrival we will stay in dock for a seventy-two hour refit, and no one’s to leave the ship during that time. I repeat, all planet leave is cancelled. I’ve just had an unhappy love affair, so I don’t see why anybody else should have a good time. Message ends.”
(Prostetnic Vogon Jeltz, Hitchhiker’s Guide to the Galaxy)

Grey is not just a color — it’s an attitude. There is a management style that I refer to as “Greyface Management”. The term is loosely based on the “Curse of Greyface“, an important concept of Discordianism.

Greyface Management is characterized by a total absence of fun. Everything is prohibited: free speech, sarcasm and parties. And there is no praise for good work, either. Never. In fact, a Greyface Manager’s motto is: “Praise is the absence of punishment”. A Greyface Manager typically wears a grey suit (mentally, at least) and an annoyed look on his face — he is a humorless bureaucrat, akin to a member of the Vogon race.

The presence of Greyface Management is not just unpleasant — it is a sign of serious trouble. A manager who uses this kind of management style in a software shop openly confesses that he doesn’t have a clue about software development in general and “Peopleware” (that is, developers) in particular. Now, it is a well-known fact that most software managers can’t manage (a subject well-worth exploring; I will certainly revisit this topic in future posts) but many software managers are aware of their limitations and successfully use techniques such that productive work is still possible under their reign. A Greyface Manager, on the other hand, hasn’t reached that level of sophistication and uses the worst-possible approach: oppression.

Humor is very important for software developers, especially “creative” humor that requires “out-of-the-box” thinking — that’s the very reason why programmers usually love Monty Python and Dilbert. Sarcasm and inside jokes help keeping the team knit together, so it’s not always a bad sign if developers make jokes about testers and sales people (and vice versa). And, dear Greyface Manager, what use are conforming “yes-sayers” that work to the rule, anyway?