Yesterday, someone described us at CQ2 as "Software Efficiency Experts" . Probably, because we try to eliminate waste in software development, and we continually search for, and find practices that work well for us and our clients.

But what about Effectiveness? It is nice to reduce costs, but if you develop the wrong things, you are getting nowhere. You are getting there more cheaply than otherwise, maybe faster as well, it is all well tested, but it still is the wrong software!

The best way, in my opinion, to increase effectiveness is to eliminate waste in requirements:

• Don’t automate things that don’t have to be automated. If you leave it up to some technical people (I know I’ve been one), you would have everything automated. Instead, automate work that costs much more to do by hand than with software, or automate something so you can deliver much more value to your customer than otherwise possible.
• Program your software ‘just in time’. Delay implementation until you really need the software. It is more effective to invest in software you need now, than in software you don’t need right now, and might never need at all.
• Make sure all the features developed so far provide value. Measure usage of features, remove them if they aren’t used anymore. Unused features cost money for time spent maintaining software, and possibly planning things based on these features. Sometimes it takes time to explore software by using it, to find out which features are really essential and which aren’t.

Now that we are developing the right thing, we can focus on developing the thing right. What works well for us in this respect, is Test Driven Development (which makes reliable software cheaper to build and maintain than unreliable software), Refactoring and some other techniques from Extreme Programming in combination with increasing the personal effectiveness of development team members and better and more enjoyable teamwork through e.g. Retrospectives.

Cost-effective is a nice word to describe this, because it focuses on cost (efficiency) as well as on value (effectiveness).

The metaphor Erik and I use for this these days, is that you have an engine which starts running very efficiently and is very powerful, but the car around it hasn’t changed, so the transmission can’t cope…

Then you can decide to optimize the car as well, but you discover there are holes in the road. Then you can start to fix the holes in the road and so on…

The xp-team is the engine, the organisation around it the car, the organisation around the organisation the road etc.

At XP-Day London, Mary Poppendiecks lecture on Lean Development reminded me of some of the interesting things in Lean Manufacturing and the theory of constraints.

Value Stream Mapping

At least there are tools to identify why your xp-team has diffculty interoperating with other teams within the organisation, and maybe with your customer as well, especially Value Stream Mapping seems interesting. This is where an organisation or team identifies which activities, at what point in time produce value, and other times when there is just waiting for e.g. supplies from outside. An example of elements in a value stream are a finished piece of software waiting for acceptance (not providing, value, just waiting) or customer and programmers discussing requirements (providing value, because the vision for the system is growing). The idea is to look end-to-end end shorten the time it takes a requirement to be turned into deployed software, so that an organisation can respond faster to changing demands.

Kaizen Events

There are also things from Lean Manufacturing with which you can get a whole organisation (the car) to work on their process collaboratively. Kaizen Events look particularly interesting. This is where you take a day with a group, identify things that can improve, and actions to take to do the improvement. I guess the Retrospectives we run are similar, but Kaizen events seem to work with very large groups as well.

Jim Highsmith also hinted at this in his workshop at AYE on team decision making. He gave the example of toyota, where, when developing a car, several car bodies, transmissions engines etcetera are developed. Measurements etc. are taken and discussed with tool-makers, assembly workers, so that when it is time to produce the actual car, there is always a choice of components. When there is a problem with a certain component, it can easily be exchanged.

Interestingly enough, while checking out Dave Thomas’s blog today, I found a related note, "mechanism versus policy" . One size does not fit all, he says when discussing user interface implementations. For expert users, NakedObjects (where users can manipulate objects in the application domain more or less directly through a very thin GUI) might be an excellent solution, since they are free to manipulate everything, while for novices or casual users, a wizard-driven interface is more suitable. Why then, not wrap your NakedObjects in a wizard, and offer the choice which to use to the user?

I have the same feeling about editing web-sites through browsers. As a power-user, I prefer to work with files and be able to do batch modifications with scripts and tools like secure shell. For casual users, the previous sentence might contain 4 strange words (‘batch’, ‘scripts’, ‘tools’, ‘secure shell’), so they’d think, ‘what the …’ is he talking about? The other way around, I feel constrained when having to upload 100 jpeg files one-by-one through an upload dialog - an experience I had when trying to get some digital photos printed recently.

I’ve been walking around with this idea for some time, at least with the frustration of working on one solution (e.g. in this rant), but expressing it to others is much easier now I have a term (Set Based Development) to describe the alternative.

References:

Toyota’s principles of set-based concurrent engineering (text only link )from Sloan Management Review, Winter, 1999, by Durward K. Sobek, II, Allen C. Ward, Jeffrey K. Liker

A new camera sure is fun, but it has one major drawback: I make much more pictures than usual :-). The three categories below contain over 550 images in all. Since I promised several people to put them online, there was no way around but to make myself some scripts to scale the images and generate index files. The program ImageMagick makes this relatively painless. If you want my scripts, just drop me a mail.

Just click one of the images below to see all of the images in the category. At AYE I took so many pictures (about 350) that that one is divided into subcategories...

Visiting the AYE conference and the Grand Canyon in Arizona, USA	XP Day Benelux 2003	A photoshoot with Charles Vermeulen around the Grevelingen lake in Zeeland

Most of the preparation is done individually, by organisers dispersed over several places in The Netherlands, Belgium and France (and sometimes the states). Most of the communication is taking place through e-mail and Internet Relay Chat meetings. It turns out, that often coordination of the work is more work than the work itself... I just put the session descriptions from the website into a document. That took me about twenty minutes, which was much less than deciding who was going to print them ;-). I'm sure we'll find ways to do this more efficiently in the future...

My favourite way of organizing is still doing work co-located, as for instance this picture from a program committee meeting shows:
Nynke Fokma, Peter Schrier and Vera Peeters working on the conference program

Modifying the conference program is quick and easy during a pc-meeting. We take the latest version from our website (yes, the website is conventient for broadcasting the program to participants and session organisers), transfer it to post-its, and juggle around the program on a whiteboard. We then take a photograph of the end-result, and someone (usually Vera) ensures the broadcasted program reflects the one on the whiteboard.

So, I'm almost off to the conference location, to do a last check of the rooms, the internet connection and maybe do some set-up work already. May-be I'll see you tomorrow. I'll put some pictures up somewhere next week.

In a previous entry I already went into Jean Mc Lendon's great session on Satir Systems Coaching, so I won't repeat that here. The sessions below are the ones that stand out in my memory at the moment.

Interviewing with Ease

Most hiring managers in the group were having problems with large amounts of applications for each open position. One has to strike a balance between the amount of time spent interviewing people, and the chance of a 'bad hire'. Hiring someone you later have to fire is very expensive, in terms of both costs and morale in your teams. Having an HR department do screening before you as a manager with more technical and functional knowledge before you can seem efficient, but they can easily put off the best candidates, or fail to see through tricks by not-so-good candidates.

Johanna recommended coducting so called phone screens, with the most important dissatisfiers early in the phone screen. A phone screen is a scripted telephone interview (in the same vein that is used for telemarketing). An example of a dissatisfiers is e.g. 'are you willing to travel 25% of your time' - if that is required for the the job and the applicant says no, you can end the phone screen right away (don't forget to thank the applicant for their time of course). In 5 to 15 minutes you can quickly decide which persons you want to invite for an interview.

We spent some time thinking about (il)legal questions. Surprising to me, the USA is quite highly regulated with respect to questions you can not ask. Whenever I met someone, they would often ask 'where are you from', and 'where are you based'. In a job interview it is illegal to ask about the applicants place of birth apparently, whereas this is a default component of a Curriculum Vitae in The Netherlands. Questions about fluency in certain languages are only permitted if they are essential for the job.

The group then did an exercise on Behavior description questions, these are a special kind of open question, asking the applicant to describe what he or she did in a specific situation in a past project. One can use these questions to find out relevant behaviour to the job in question, without spending too much time explaining about your current situation - job interviews are typically way too short to give both the company and the applicant sufficient time to go deeply into each-others' situation. An example of such a question would be "What did you do last time you disagreed with a team-mate? With a Manager?" or "What did you do when a customer was dissatisfied?".

An interesting trick that came up, is the so called "dirtbag test", to sift out the real assholes from the population.... If you want people in your organisation to respect each other, have a junior assistant call the applicants to verify something on the CV - if the candidate is not respectful towards the assistant, dismiss the application.

Panel interviews may seem efficient ways to conduct interviews, but they are in fact the opposite. See for an amusing story and more details Johanna's blog entries When Candidates Run Interviews and Panel Interviews.

After the workshop I decided to pre-order some copies of Johanna's forthcoming book Hiring Technical People, which looks promising, and useful to me when we decide to expand cq2's software studio beyond our current network.

Firing technical people

or, Managing team membership, who's in and who's out by Becky Winant and Steve Smith. Follow the link to see photos by Steve Smith. The workshop revolved around an exercise having two teams of participants ('team 1' and 'team A') stand on a flipover. With each round, the amount of available paper to stand on halved, leading to acrobatic situations like this:
"Sue and Deirdre on the shoulders of Vadim and others, Esther watching, Becky checking if all feet are completely on the paper."

The image above is of Team 1, my Team A was much less acrobatic, since we decided (it took me some effort to convince the others to do this :-) ) to tear apart the flipover and stand on separate pieces early on. Eventually, it got to the point where there was of course not enough paper for everyone to stand on. So I was the first to check out ("I came here to stand relaxed on a piece of paper, not do acrobatics - I need a beer") and go to the IFEP (Institute For Excluded People) where a bunch of Team 1 members had already gathered.
"I need a beer" - image courtesy of Steve Smith

After we stopped laughing from the game, we shared team exclusion and firing stories. Some of the suggestions that stuck in my mind:

• Have regular person-to person meetings with those who work for you. Don't do performance reviews once a year only.
• Don't delay difficult decisions (one participant reported productivity of his team tripled after he fired a disfunctional team-member) - after you make the decision, it is likely that everyone will be relieved, even the ones you let go.
• Give advance warning, be specific in your performance targets & reviews.
• If you want to be an effective manager, don't be afraid of firing someone - it is part of your job.

Collaborative decision making

I rembember most the three phase model for discussion, liberally translated in my mind as 'diverge, argue, converge'. To come to a decision in the converge phase, one can take a vote, using a continuum from 'veto' 'object but would not veto', '?', 'agree with reservations' to 'fully agree'.

Jim illustrated the importance of divergence with an example from Toyota, where they keep their options for a new car open as long as possible - until a car finally goes into production, they will develop more than one drivetrains, transmission, chassis and engine. This helps them solve problems with production - because not everything designed can be easily produced. If there is a problem with manufacturing, they can choose to one of the other options.

The diverge phase is akin to brainstorming, because we don't want to dismiss too many options.

I am looking forward to reading Jim's literature suggestion, "A facilitator's guide to participatory decision making" by Sam Kaner, as well as the book Jim is currently working on, "Agile Project Management".

Enhancing Your Personal Influence: From Novice to Maestro

The client and consultant were given instructions to this effect before the interview. Contrary to what is usual in this kind of game, the client and consultant were not given adversarial instructions. This didn't help the client I was observing in the above picture... The client kept asking 'are you the best consultant for this', and asked a question about price in the first 2 minutes - this helped setting an adversarial athmosphere... In a sense this meeting between client and consultant was a success, because they quickly discovered they were not a good match.

The next round turned out to be quite hilarious. Since I'm really starting to like roleplaying, I played consultant. In this round, the instructions were a bit different: the consultant had to give the best advice possible and get a fee for his work. When the client arrived, it turned out he wanted a travel consultant, to plan a trip to Maine. I quickly transformed myself into a travel agent, even though I did not know where Maine was :-) . Luckily the client told me he wanted to go there by bus, so I didn't have to suggest it... I also didn't know anything about available hotels and prices, so I stalled the client, asking him for a price bracket and promising to get back to him the following day...

It turned out both client and consultant had screwed each other a bit... The consultant got a price bracket below what the client had spent last year, and the client was working with a clueless travel consultant! Both client and consultant had a fairly good feeling after the meeting

So, I learnt that I've become quite proficient at sales meetings, although venturing too far out in the unkwown can be risky. The observers told me I had been making good eye-contact (which i've been working on in the past year). Next time, I'll ask even more questions.

Closing session