|
|
In a previous post, I urged you to go out and learn a bit more about non-IT stuff, so that you can talk to the rest of the company. I don’t usually follow my own advice, but this time I have: I’ve bought a few new business books.
 This week I have mostly been reading “Competitive Advantage”. Competitive advantage is a management classic by Michael Porter. It was recommended by John Favaro during his XP2005 keynote.
In the book, Porter dissects the activities of a company in a “Value Chain”. He analyzes how companies can gain and sustain a competitive advantage. A company can either have a “differentiation” or a “cost” strategy.
The book is a 2004 edition, but I was disappointed to see that it’s essentially the 1985 version. And it shows. I haven’t read the whole thing yet, but there are only a few vague references to “methods used by Japanese companies”. For example, if we want to respond to the customer faster, Porter recommends to increase inventory or to get surplus capacity. Ouch! What about reducing inventory, increasing inventory turns, removing waste, establishing flow, reducing cycle time, building quality in…?
 I’m also reading Bill Waddel and Norm Bodek’s “Rebirth of American Industry“. This one is more fun and easier to read than Competitive Strategy. In the book, Bill and Norm describe the history of (car) manufacturing. From the Lean early Ford, over Sloan and Dupont’s definitely not Lean GM and back to Lean Toyota.
Their main point is this: Sloan and Dupont created a management and accounting system at GM that essentially goes against Lean, as it considers inventory an asset and labor a liability. The strengths of the early Ford and current Toyota production system is that they focus on cash flow and empower their employees to continuously improve production processes. The Toyota Production System didn’t spring fully formed from the (brilliant) minds of Taichi Ohno or Shigeo Shingo. They evolved gradually, by solving problem after problem.
The GM management and accounting practices went on to become the de facto methods in American industry. As everyone was doing it, nobody really noticed the inefficiencies in the system. Until the Japanese arrived…
I believe the same is true in software development: there’s something structurally wrong in management and accounting (measurement) of IT projects. These lead us to work in large batches (have to keep those analysts busy!), to count work in progress as value and to have long cycle times. Agile, like Lean, will always be limited to implementing a few easy technical tools that don’t require us to change the way we work (unit tests, continuous builds, refactorings), unless we can change the way we manage and measure. And if the want to do that, we have to speak the lingo. Back to Porter…
Wednesday afternoon
This afternoon, I’ll go to the “A good read” session, where a panel discuss a set of books. As you might have noticed, I love to read books. The one I’ve got with me to read on the train, is “The Ancestor’s Tale” by Richard Dawkins. Nothing to do with the day job. I just find evolution to be fascinating. Darwin has really changed the way we see the world, as few people have done.
In the Ancestor’s Tale, Richard goes back in time to find the common ancestors (“concestors”) of different species. For example, the first concestor is the species from which both humans and chimpanzees descend. Then come the gorilla’s, and so on. I’m currently 425 million years from today, where I meet with the ancestor of the Coelacanth and us. The Coelacanth caused a bit of a stir when it was discovered in 1938, because everyone believed that Coelacanths had gone extinct a long, long time ago.
Dawkins makes it clear that there’s no strict, clear boundary between species. It’s all gradual evolution, there are no large discontinuities. “Species” are just arbitrary classifications invented by biologists to indicate that two types of creature are sufficiently different to make the distinction useful. We are not descended from Chimpanzees, but we had the same parents. We are all siblings of Coelacanths, even creationists.
I’m reading the Ancestor’s Tale because I liked “The Selfish Gene“, which argues that the reason for all life is to propagate genes. It’s a great book, the argumentation is very convincing, but I fear the metaphors he uses are prone to misinterpretation. For example, what does it mean for a gene to be selfish? If you look long enough (a few million years or so), it would look as if genes have some sort of will or goal. Of course, it’s all massive, random processes with feedback from selection.
I read the Selfish Gene after hearing Dawkins in Steve Reich and Beryl Korot’s “Three Tales” music video.
Part of Dawkins’ text is:
“We and all other animals
are machines
created by our genes
A monkey is a machine
that preserves genes up trees
A fish is a machine
that preserves genes in the water”
Hmmmm… How’s that for a metaphor that can be misunderstood? Read the book to understand what Dawkins means by “machine”.
How do you decide which books to read? What’s the story behind the last book you read?
Tags: SPA 2006
Retrospectives in enemy territory
You know retrospectives are good for you. But what if you can’t hold a “real” retrospective? There could be many reasons:
- We don’t have any time
- We don’t feel safe
- We don’t do silly, fluffy stuff like that
- We don”t need to improve any more
Do you give up? No, that’s the kind of situation where you really need a retrospective.
Undercover retrospectives
Don’t organize retrospectives.
- Find some excuse to have a celebration. The end of a release or iteration. Two weeks without a build failure… Use your imagination
- Go out and get coffee and pastries. Or soft drinks and pizza. Take away Chinese…. Be creative
- Invite the team members, your customer, system engineers who put your software into productions, DBAs who nurse your precious data, people from other teams who helped you get to this success. Thank them for making the reason for the party happen.
- Now comes the devious bit. Get people talking about what went right. Ask them “If you could change one thing, what would it be?”. Ask them if they would like to research something new. Make mental notes of what people say (I don’t recommend alcohol at the celebration: you’re unlikely to remember what was said, the next day).
- Make it happen. Implement the suggestions; start research. By the next celebration, everyone will be pleasantly surprised that you listened to them and took their ideas seriously.
Try it! It doesn’t cost a lot of time and money, but it does wonders to your team.
Tags: Retrospective, Agile
An afternoon off
Yesterday afternoon I went to a seminar on “Agile Development in the large”, organised by Ardatis. Johan Lybaert (Program Manager) and Jan Van Reusel (Development Manager) of Ardatis presented how their company has been using Agile Software Development techniques. They use a combination of XP and Scrum, modified to their own circumstances. Three developers gave a hands-on demonstration of extremely fast test driven development, not only of business objects, but also of their user interface.
Ardatis was assisted in the transition to Agile by Jutta Eckstein. Jutta co-presented the event, often in dialogue with Jan. As the team consists of 60 people, Jutta’s experience in large agile projects came in handy.
Fun
The presentation was very clear, with plenty of metaphors, funny bits and practical advice. I particularly liked the “Rules of the Game” sections. There were only a few, simple rules but these lead to complex behaviour. One of the key requirements for successful agile development they pointed out, is a high level of discipline in following these rules.
The presentation was interspersed with short video fragments. At the end, Jan seemed reluctant to show the last fragment. I’m glad he did. In this short video we saw the teammembers smile and laugh. They were having fun at work.
Enthusiastic about a methodology
Have you ever heard people talk enthusiastically about a methodology? I have, yesterday.
It’s happened to me a few times before. Customers who got more than they expected, in record time. CEO’s who quickly saw the results of their IT spending. IT managers who felt they really managed their projects. Sceptical users who, after using the system, asked to use the system sooner than planned; and “when can we have the next version?”.
I’ve never seen anybody get excited about waterfall, RUP or any other method. This only happens with agile software development. With non-agile methods, people were sometimes pleased about the result, but never about the way we got there.
It don’t mean a thing, if it ain’t got that swing!
There’s a bit of discussion about the “watering down” of agile. Everyone is using “agile”. Agile is good. Agile is the new apple pie.
Isn’t there a danger that people will get confused? How can we make the difference clear between “real agile” and the pale copies?
It’s simple: look for fun, enthusiasm, happy people. You can’t fake that.
Agile Development doesn’t need any marketing budgets. Just make your customers, managers and teams happy and enthusiastic. And let them talk.
Who have you made enthusiastic today?
Tags: agile
Collection fieldstones
As you read earlier, I’m reading “Weinberg on Writing: the Fieldstone Method“.
I’ve begun to consciously think about how I collect fieldstones.
Slippery fieldstones
I get most of the material for what I write by reading, by thinking about what I read and by writing about what I think. There are plenty of fieldstones. The problem is collecting them.
I don’t always have something to write ideas down, especially when I’m reading. I have an inhibition against “mutilating books” by cracking their spines, writing in them, folding down corners of interesting pages or putting sticky notes in them. In any case, I don’t have sticky notes on me when I’m reading. This means I must trust my memory to collect interesting fieldstones.
A few days ago, I was re-reading “The Toyota Way” to collect material for my presentation at XP Day France, when I came across this fantastic fieldstone: “Obeya”. This was a perfect fit for what I wanted to convey with the presentation. With this word, I could link two sections of the presentation. I tried to remember the word. And I did… for 5 minutes, or so. And then I forgot the word.
I don’t worry too much when I forget something: if it’s important it will come back. “Obeya” came back when I was getting something to drink from the fridge. This time I could keep the word in memory long enough to write it down on the back of an envelope. Whew! Later that day, I added “Obeya” to the presentation.
Leaving stones behind is not too bad. If the fieldstones are good, they’ll turn up again.
Playing with words
Weinberg describes many ways of playing with the text. There’s one I used to use long ago at school, when I didn’t have any “inspiration” to write an essay.
I opened the dictionary at random points and scanned the pages for “interesting” words. There are many ways a word can be interesting: the sound or the shape of the word, the meaning, an “exotic” origin… I usually collected between 10 and 15 random words like that.
Then I shuffled the words. Weinberg calls this “playing Solitaire” with the words. Slowly, the words would prompt a story. The only thing I had to do was write that story down, using at least 10 of my “chosen” words. Quick and easy.
I particularly enjoyed obscure or unusual words. I pictured the teacher looking up all those words in their dictionary. I thought they might learn something by grading my work. I think they mostly learned that I’m an obnoxious smart aleck…
There are many more “games” like that in the book. I’m going to try a few of them. I particularly like “Dani’s Decimation”, a game where you remove 1/Nth of words from every sentence, 1/Nth sentences from a paragraph. It’s bound to simplify my writing.
Playing with structure
There’s another writing game that I play, that’s not in the book. For the “Things I didn’t Learn” series, I imposed a certain structure on the stories, to see what would happen.
I started with three stories and tried to give them a common structure. You need at least three exemplars before you can generalize (like in framework writing). You need at least three before you can start to talk about “series”.
Once these three stories were composed in my head, using the common structure, I started to think about other stories that I could fit in the format. Working against the limitation of a fixed format, I found more stories that would fit. Each of them had to have a certain structure:
- I encounter a problem that others have also encountered
- I solve it using an Extreme Programming or Agile technique
- But I go back to using the tried and true ways. The problem reappears.
- Everyone (me included) says “that’s how it’s supposed to be”. Software projects are meant to go badly. If there were a way that projects could succeed, we would have to change our ways of working. There is no such way, so we can’t be blamed if things fail.
An outline’s not for me
Weinberg warns that writing from an outline usually doesn’t work very well for him. It doesn’t work for me either. I prefer the collecting-shuffling-writing-rearranging method.
Sometimes I have to follow an outline. For example, the “Toyota Way” book contains 14 principles, which are part of 4 categories. I’ve kept this structure for my presentation. I use the 14 principles and 4 categories as a “backbone”. For the rest, I’ve collected fieldstones and put them where they made most sense. And then I rearranged them, and rearranged them again. I’m still rearranging and will probably continue to do so until the day before the presentation. But still, the 14 principles are there.
The 4 categories are still there, but I reordered them. The book presents the philosophy first. I prefer to keep it at the end. That way, the presentation ends on a strong note, building up from the Process practices like Flow, Pull, Heijunka… Then we have the People principles, then Problemsolving and finally Philosophy.
P.S. If you’re curious about the meaning of “Obeya” and you haven’t looked it up yet, “Obeya” is the Japanese for “Big Room”. It’s the name given to the practice of putting all people involved in the design of a car in one big room, so as to facilitate communication. This word is useful for two purposes:
- “Obeya” is a practice that is the same in the Toyota Way and in Agile Development. It reinforces the idea that Agile and the Toyota Way share some practices. In the presentation, I want to show that they also share most of the principles, even if the practices are different.
- “Obeya” links two sections, the one on “Learning” and the one on “People and Partners”. Letting people work together lets them learn from each other, encourages frequent integrations and speeds up “Nemawashi”, seeking consensus. Engineers from partner companies also work in the “Obeya”, so that their designs are perfectly integrated with the rest of the design. Working in the Obeya, these engineers experience The Toyota Way firsthand. They can become ambassadors and sensei of the Toyota Way in their own companies.
p.p.s. As you may have noticed, these days I like to write stories around obscure Japanese terms 🙂
Tags: agile, Toyota Way, XP Day
|
|
