me.andering – Willem van den Ende

In the agile alliance board we’re ruminating on evaluation results of agile2006. Ron Jeffries has put up a page with his puzzles and ideas, and requests your feedback:

The Agile 2006 conference was very good, and the reviews from the attendees are mostly favorable. I’ve got some concerns and issues, and I’m soliciting feedback, input, ideas from people who have them. As an Agile Alliance board member, I might be able to get some things done. Tell me what to do.

(from Ron’s conference thoughts )

I’m sharing Ron’s puzzles. I’m also puzzling on direction for xp days and other agile conferences in Europe. So feel free to e-mail me or Ron, or leave a comment right here.
(I may type more later… injured a wrist swimming yesterday, strange but true)

A friend of mine says:

Question for your agile coach certification :

What do you do if your colleague does not want to write unit tests, because he believes that really good programmers don’t need unit tests?

Correct Answer:

Give your colleague a copy of John Bentley’s Programming Pearls. 100% ‘agile’ free content, and for real programmers only. It is chock full of cool algorithms, bitmanipulations and other stuff real programmers love.
Let him read it, and I doubt that he’ll still say that real programmers don’t need unit tests.

(For the un-real programmers: programming pearls is eXtremely Pragmatic, and full of advice on testing, debugging, asking the right questions to understand the problem, when optimizations are useful and when not etc. There are also many examples of problems that seem simple to program, with implementations that are surprisingly error-prone.

I read this book because someone else on the panel for ‘a good read‘ at next friday’s minispa recommended it.

I don’t often read ‘real programmers’ books anymore, and I’m glad this one was on the list – really good. I hope to see you next friday at minispa in London)

The drawing carousel Marc and I ran at agile2006 did not run as expected (in a good way) I called Vera Peeters, who originally designed the workshop, to tell her how it went. So far every drawing carousel we have ran is interestingly different in some way, we are puzzling on causes, so we can get more people to experience the flow resulting from promiscuously pairing in short episodes.

We had a somewhat smallish audience, so we assembled one team. Team dynamics were great. After strictly facilitating iteration reviews and standup meetings the team started to self-organise these. The team started to quickly decide pair rotation, and many decisions were taken through osmosis – as pairs rotated, information was spread around, so not everything needed to be discussed at the reflection and standup meetings.

One of those things, as we discovered during the session debrief, was that the team did not deliver a drawing, but more of a collage made of cutouts. We asked how that had happened, because we had been present at all of the iteration reflections and standups, and we were still surprised by the result. Cutting was not mentioned during the meetings (or at least, we did not notice…). The team said consensus on cutting was reached within the first three iterations, solely through pairing.

The team also asked difficult questions before the first iteration (I won’t mention the questions here, as that may spoil a future run…). Having one or more experienced testers, who are skilled in looking for holes and asking critical questions, in the team present at the first planning meeting helped in preventing rework early on.

The team had gotten into the zone / flow, where the team operated as one.

Factors that may have contributed to this:

• good mix of experienced agilista’s and ‘newbies’ – getting the ‘innocent newbie questions’ often expose holes in product and process – it also makes the debriefs easier to facilitate, as what happens in the simulation is,through the questions, easier to tie to real life
• Running it with only one team gave Marc and me ample time to discuss facilitation strategies during the drawing episodes. We were also able to pick up more keys from observation.
• Lynne Azpeitia was in the room as well, mostly observing, that gave us even more information to steer the session.
• There was no competion on resources with other teams (if there are more teams, the limited number of scissors, glue sticks and sticky tape rolls leads to resource competition and wait times – teams are not allowed to change tools while drawing, only after the standup and before restarting drawing.).

In hindsight, I did get a key for the team making cutouts. At one point, the team ran out of scissors. We had about five pairs, and four scissors… If they were mainly drawing, they would not need that many scissor.

pair drawing

switched pairs

drawing and cutting a prototype

standup

standup with list of tasks on the flipchart in the background

Editing the task list

drawing signed with business cards (some business cards were created on the spot with mini-index cards)

The team proudly presents their result

See also Other entries about drawing carousel, mainly photos from previous runs.

I’m back home, sort of, at least for this week. I’ve spent last month going to Singapore again, a short holiday (has been a while…) and an exhilarating trip to agile2006. More about that later (four sessions are waiting for a writeup, and afterr the election last week, I’m an agile alliance board member).

Right now, it is time to create some session proposals for xp days benelux (closes today) and xp days london (closes august 14th).

Pascal advertises xp days benelux with white beer travels and I can tell you Pascal and Vera can show you some pubs that are not on the site…

I participated in (re)writing a bunch of discovery session and tutorial proposals for agile2006. That turned out to be interesting, as all but one of them got selected, amidst fairly stiff competition. We decided not to run the xp game – running too many sessions is bad for the quality of individual sessions, and there are similar sessions in the programme already.
As this conference is going to be large, we tried to let our sessions scale to larger audiences, amongst other things by having more co-hosts per session than normal. That leads to a web of sessions, where some sessions share almost the same set of hosts, but not quite. After acceptance, I had a hard time deciding how to give my best effort in running the sessions. I decided to take responsibility for running the sessions where I am first or second organizer, and support other sessions in a ‘best effort’ way, where I’ll do whatever I can based on time and energy that I have.
Participating in many proposals with many co-hosts is slightly confusing. But fun.

I’ll be co-hosting

• The drawing carousel – a pair programming eXperience
• Simple tools for communication – a Balancing Act
• Systemsthinking workshop – using the Diagram Of Effects (DOE) to effectively change your work environment.

Together with Marc Evers, hopefully supported by (in various configurations, depending on the session and what suits our co-hosts in the schedule) Laurent Bossavit, Emmanuel Gaillot, Rachel Davies and Lynne Azpeitia.

I’ll be supporting in preparation and/or running (tool words is in the same slot as systems thinking unfortunately):

• Tracer Bullets (an experiential session on feedback) by Rob Westgeest and Tjakko Kleinhuis
• Tool Words, Weapon Words by Laurent Bossavit and Emmanuel Gaillot
• Writing on the Walls (about the use of information radiators) by Laurent Bossavit and Emmanuel Gaillot

Writing on the Walls is new, Tracer Bullets revamped – I haven’t had the good fortune of attending it so far.

So I got to xp day france, on thursday and friday.

it’s cool to see people get together, share experiences, try out new ways of presenting and simply connecting.

All of the sessions were in French. It was cool to see an american (Charlie Poole) and a canadian (J.B. Rainsberger) do presentations in French :

The thursday night dinner / boat trip was also very nice.

To introduce the sessions, all presenters did one minute presentations, which worked very well to warm up the audience.

I co-facilitated a run of Simple tools for communication (‘des outils simple pour le communication’) with Marc Evers again (also known as Balancing Act), this time supported by Laurent Bossavit and Emmanuel Gaillot, who helped us out with translating to French, doing roleplays and facilitation.

We scaled this workshop in several dimensions. Doing it in French was more difficult than doing it in English or German, turnout was the largest we had so far for this workshop (between 25 and 30 people). As it requires quite a bit of facilitation and safety, we are very careful not to scale it too quickly.

We did exercises and demonstrations about coping stances, self other and context, the satir change model, and as a roundup we did a temperature reading. Near the end, the audience was pretty much exhausted. Judging from the reactions, the laughs, and the stories participants roleplayed, the workshop was a success.

I haven’t much to say about it right now, still recovering from excellent dinners, wine, conversation and enjoyable sessions. And I’m preparing for the next workshop, this afternoon I’m co-hosting the ‘these are just some of my favorite tools’ workshop at SPA with Marc Evers and Emmanuel Gaillot. I hope the pictures speak for themselves.

I’m preparing to assist Marc Evers tonight at the Thinking for a Change workshop (description for use at the SPA conference, later this month). Marc and Pascal already made a presentation. That contains this gem by Richard Bach:

“If you really want to remove a cloud from your life, you do not make a big production out of it, you just relax and remove it from your thinking. That’s all there is to it.”

Hmmm. Simply. Easier said than done. Nevertheless, the only way to end drama, is to end drama. So I agree.

I have started preparing for XP Day France. Pascal van Cauwenberghe suggested we may need to speak French there… Right. Almost forgot about that. Minor detail.
How to practice?

I watched a bit of French television, that doesn’t help so far.

We continued our chat in French. That worked. A chat window gives me time to think and I can save difficult phrases.

It was fun, and I could keep it up longer than I expected. Until I tried to explain a problem I’m solving for a run of the Thinking for a Change workshop (possibly tomorrow at XP-NL). After some help from Pascal it ended up as:

“Comment peut-on amener les participants d’un workshop à discuter d’un problème réel et actuel qui peut être resolue avec les outils proposés lors du workshop?”

Pardon my French! In English:

“How can one get the participants of a workshop to discuss a real and actual problem that can be resolved with the tools introduced in the workshop?”

Funny. Looking back at it, the question is now phrased much more clearly than when I started (in Dutch). Rewriting in another language goes into the bag of tricks, so I can juggle my mind when rewriting, and practice languages at the same time .

Value Stream Mapping is a technique that is already used in the context of Lean Manufacturing. At OT2004 I attended the workshop “Understanding the Software Value Stream” by David Harvey and Peter Marks.

Borrowing metaphors from other domains, and applying them to the creation of software can be, from my experience, a dangerous thing. Even adding the word ‘development’ after ‘software’ is dangerous, since that also implies a metaphor. I consider borrowing from manufacturing especially dangerous – I consider software ‘development’ to be a creative activity best carried out inside a ‘living company’ not a kind of machine.

Value Stream Mapping seems worth exploring though, so the main question that remained in my head after the workshop was: how can we map Value Stream Mapping to software ‘development’, without implicitly taking over the ‘production metaphor’.

As described on http://www.mamtc.com/lean/building_vsm.asp:

Value Stream Mapping is a method of visually mapping a product’s production path (materials and information) from “door to door”. VSM can serve as a starting point to help management, engineers, production associates, schedulers, suppliers, and customers recognize waste and identify its causes. The process includes physically mapping your “current state” while also focusing on where you want to be, or your “future state” blueprint, which can serve as the foundation for other Lean improvement strategies. Interesting results that could be achieved with the above are:

• Enabling all stakeholders in the process to see the whole picture. In my experience people usually only see their own part of the process. Optimizing one part without considering other parts might cause the whole process to deliver less value instead of more.
• Both materials and information is taken into account. In software development we work with information only, but since information is supported by VSM, this could be sufficient.
• Focusing on ‘what is’ and ‘what could be’. Reflecting on process is a useful, and often difficult activity since assumptions have to be made explicit. Imagining what could be without taking the current situation into account, however, is much more difficult. There are other techniques (such as Diagrams Of Effects) that are useful, VSM could be a useful addition, since it takes information flows (rather than actions) into account.

Continuing the quote:

… A value stream is all the actions (both value added and non-value added) currently required to bring a product through the main flows essential to every product:

• the production flow from raw material into the arms of the customer

• the design flow from concept to launch

The idea of adding ‘non value added’ steps to a value stream is to identify steps that are wasteful and can be eliminated. Adding everything makes brainstorming about the process easier, because different stakeholders might find different activities valuable. Separating production and design flows is not something that is generally applicable to software.

For instance, in my daily practice of software development, there is no visible distinction between design flow and production flow, because each step in a process based on Extreme Programming encompasses both production and design. One of the things that came up after analyzing the value stream we created at OT, was that not only is value produced at multiple steps in the process, also very early on in the process value can be realized. Ordinarily, for a production line, I would think value is created at the end of the production process, when a product is handed to a customer and (possibly) money is exchanged.

In a process with short iterations, typical of agile software development, value is also created during planning meetings with the customers. For instance, customers get to re-think their business process while brainstorming their next wishes for software (and, as a consequence, perhaps changing the value ). At the next xp-nl meeting (http://www.xp-nl.org/Wiki/XpBijeenkomst4.5 ) we’re probably going to explore Value Stream Mapping further.

As you can see from my other entries, I was at AYE last week. I’ll try to summarize a number of sessions here. The sessions, are as usual, only part of what makes the conference. As Jerry Weinberg pointed out in both the opening and closing session, the most important people at the conference are not the organisers, but ‘the person to the left of you, and the person to the right of you’. I disagree sort of, since the organisers are also ‘to the left and right of me’ . A conference means to me always a 16 hour work day – 8 hours of sessions followed by 8 hours of dinners, lunches and drinks, and there was no shortage of interesting persons here.

Lunch with palmtrees at AYE, in the foreground Naomi Karten and Johanna Rothman

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

This workshop facilitated by Joanna Rothman was interesting and practical. To the left and right of me were managers hiring people, as well as persons on the ‘other side’ of the job interview process, looking for work.

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 went to this session by Jim Highsmith, because I’m interested in how one can quikly make fairly good decisions with a group, without falling back to an authoritararion style. Jim drew the following continuum, indicating his preference for the “self organizing” style in the middle:

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

See the session notes for some observations of others on this session facilitated by Becky Winant and Jerry Weinberg. This session revolved around an exercise where a client had to get the best advice possible from a consultant, and the consultant had to give the best advice possible.

a client (left) and a consultant

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

This one was totally hilarious. Naomi Karten asked all particpants to split up in clumps of three, and make a trip-report in fake powerpoint presentation style. Did I mention none of the other sessions at AYE used slides? I’ll let the pictures do the talking:

Vadim Temkin and Malcolm Curry doing their trip report in Russian – hilarious

Participants actively involved, as in the other sessions at AYE

Paul was having “blue screens of death” in orange and yellow

“And now for something completely different”, Phil and Jay had a bi-lingual presentation in cockney and new-yorks. I can’t remember what the slide with the chicken was about

And finally, after Naomi appreciated the participants for several things, it is time to appreciate the organizers. From left to right: Becky Winant, Don Gray, Esther Derby, Naomi Karten, Johanna Rothman, Steve Smith, and on the far right: Jerry Weinberg. Thank you for a wonderful time at AYE!