me.andering – Willem van den Ende

I’m ruminating on a largish entry about Agile Open. It was wonderful. In the meantime, I recommed reading what Rachel Davies wrote in her trip report or having a look at the conference photographs posted by Marc Evers during the event.

I worked on my candidate statement for the agile alliance board elections today. Yesterday, at the agile seminar in Nieuwegein, Nynke Fokma, Marc Evers and Peter Schrier spontaneously self-organized into a playful campaign team (we’re not going to take this too seriously, mind you). During drinks they asked around what people expect from the agile alliance.

One of the concerns that came up, was with agile becoming mainstream, there will be a surge in ‘true believers’ who take a bunch of practices from a book (e.g. extreme programming explained or the scrum book) and take it as ‘the thing’ rather than as a gate to further understanding – turning off sceptics through their zeal.

If you want to read more about this, check out the xp mailinglist archives a few years back, or read about Shu Ha Ri on the c2 wiki or in Alistair Cockburn’s book on agile software development. I believe it is good to start out with practices, try them out a hundred percent and then reflect and make them your own.

By drawing in more beginners we, as a community, can support our industry in making a smooth transition towards more effective and enjoyable work. I interviewed a bunch of people recently for the agile2005 experience reports and yesterday at the agile seminar, and one thing that most of them had in common was how much difference they experienced in their working environment after starting with simple practices like stand-up meetings and iteration planning. An older engineering manager told me, that now he saw his engineers have so much fun he would almost consider going back into engineering. Now is a great time to be working in software development.

Ok, so here is my candidate statement, within acceptance tests provided by Diana Larsen : max 150 words, has to contain something about non-profit and community experience and what I would like to do for the agile alliance.

Hi, my name is Willem van den Ende. I’d like to help build agile alliance branding strength by fostering thriving local communities, international conferences, a website and other expressions that model our values.

I work as software development coach, currently based in Eindhoven, the Netherlands. I enjoy growing communities, so I co-founded xpnl, xp day benelux, agile open, agile systems and systemsthinking.net. Growing up in a tiny country that cultivated its golden age by accepting diversity when that was outlawed elsewhere, makes me realize how big this world is – we can prosper only by learning from each other.

As agile becomes mainstream, I believe we need to emphasize values over practices and individual methodologies. I see the agile alliance as rallying point for pragmatists seeking like minds advancing the “State of The Practice” in management and software development. We’ll be the change we wish to create.

I’ve been invited to run for Agile Alliance board member elections. For me, this is the first time I participated in this way in an election. So, in the spirit of communication, feedback and respect, I would like to know how I can best serve other Agile Alliance members in this way. if you’re a member, and tell me what you would like me to do for you, if I were elected.

I’m articulating the ideas I’ve already got so far in a 150 word blurb for a mailing to the members. That is due tomorrow, so If you reach me before then, I’ll be able to weave it in there as well.

I recently read the second edition of Extreme Programming Explained – Embrace Change by Kent Beck. As the dust settles, the community is embracing the changes in this second edition (or as I say, version two).

For your and my linking pleasure, here are summaries by Michele Marchesi, Bill Wake and Keith Ray.

I used to recommend the first edition as the quickest way to get started with extreme programming. Currently, as ‘getting started hands on guide’ for beginners I’d recomment the Scrum book (for iterative planning) together with Test Driven Development by Kent Beck for programming.

I’d recommend the second edition for those who are interested in the pragmatics behind extreme programming. It now feels less action oriented, but compensates that with a much better explanation of the reasoning behind the practices.

Worthwile reading if you’ve been doing (some of) the practices for a while, and start wondering why they work. Over the past years, I’ve found it worthwile systems thinking about this with some colleagues. XP Explained second edition can help you get there a bit faster.

I just came across this, from the Portland Roundtable on software development, Commodization of IT

One idea that comes to mind borrows from the experience of the computer hardware industry, and relates to aggregation concepts. If one can combine commodity components to create a new product that is both useful and affordable (i.e. high-value) then commoditization becomes an enabling force, an opportunity, if you will, to provide something that was not feasible to provide before. Using this analogy, how might this concept of commodity aggregation apply to IT services?

Last year I was thinking with some colleagues on commoditization from a perspective of fixed price bidding. The roundtable report provides some fresh insight. I am thinking of integrated (yet loosely coupled) products recently, but had not yet linked it to commoditization.

What I get from the roundtable is: If you’re competing on price alone, it is because you are not differentiated enough.

Earlier on, I wrote about the changes we’re making for the XP Day Benelux 2005 session selection process. For XP2005, Vera Peeters has adapted some of these ideas already, and it seems to be working fine so far. The main change from the process of last year, is that all of those who hand in a session are also invited to participate in the review.

Vera worded the values,goals and condition for this review much more succinctly than I can, so I’ll reproduce her invitation to session organisers here (with her permission):

We value communication, feedback, simplicity and courage.

As a workshop review committee, we want:

• an open and transparant review process

• useful and valuable feedback for the submitters
• a lot of input to create a great conference
• an atmosphere that encourages information exchange
• participation and involvement of a large community

That is why we decided to invite all workshop submitters to participate in

the WorkshopReviewCommittee. Everyone who accepts this invitation, agrees

with the following rules:

• You review at least 1 proposal, according to the WorkshopReviewProcess

• You can choose which proposals you wish to review, from those proposals that don’t have 3 reviewers yet
• The review forms are filled in on the wiki, which is password protected and accessible by the WorkshopReviewCommittee only
• The reviews are not anonymous

As a session organiser, I’m very happy with this, and it seems to work out very well in practice, as most reviews have now been completed. The sessions I sent in have not been fully reviewed yet, but so far I’ve received some excellent and detailed feedback. Wether a session is well received or not, does not matter so much – detailed feedback helps to improve the session itself as wel as its’ description.

Also, the lack of anonimity (which is the norm for other conferences, and even tracks within the same conference) balances out the fact that (as Marc Evers pointed out) a session organiser can skew the results in his favour by being extra harsh on other sessions. If you do that, the other reviewers / session organisers will be on to you quickly, and you’ll only damage your own reputation. With anonymous review, this is somewhat easier to pull of (or so some people think. If there are comments, style is quite recognizable…).

As far as support software goes, non anonymous reviews make it possible to use a wiki for the review, instead of a more elaborate review support system.

As a session and conference organiser, I thoroughly have come to dislike the word submission to describe a session or paper that is handed in to a conference organisation, as it suggests servility, meekness or obedience on the part of those who organise the sessions and write the papers. For more synonyms, check out this thesaurus query.

In dutch we have the neutral word ‘inzender’ (the person who sends something ‘in’). I haven’t found an equally powerful word in english yet. So for now I’ll stick to session organiser.

Of course, we could just add a new word to English, and start using insender . Let’s see if this meme spreads.

Marc Evers pointed me to a blog entry by David J. Anderson Stop Estimating. David explains his view on estimating from a theory of constraints perspective. Marc’s timing was impeccable, since unbeknownst to him I was having a discussion with a development team at a client’s site on the benefits and costs of estimating work.

The estimates are not really that important, as I said to Marc yesterday:

The clients have a sort of ‘open space’ attitude towards the development team: it’s done when it’s done

We agreed that this is not quite so bad as the development team felt about it. This gives the developers the space they need to do quality work.

“Why do the developers feel bad about this?”, I wondered . Precise estimation is not a reason to feel good or bad (if so, it feels a bit like moralistic programming to me). Estimation accuracy is information about the project, nothing more, nothing less. Frustratingly enough, it is very hard to turn this information into useful action.

For this particular team, I learnt that the development team is getting some definite benefits from the estimating activity, besides the estimates themselves. What we came up in the heat of the moment was:

Value of estimation

• (when predictable) possibility to make promises on delivery dates

• signal of uncertain or unclear wishes, or lack of clarity on design modifications (when estimates are difficult to make, or are proven to be highly inaccurate)
• creates communication and shared knowledge – if programmers make different estimates for the same task, they have to explain how they got to their estimate. This creates shared understanding.

Cost of estimation

• several hours a week, spent on discussing estimates, as well as design.

• time spent on meta-estimation – discussing why estimation works or not

One of the striking things when the development team reflected on their estimates yesterday was, that they’re quite capable of giving a rough estimate on a large, not yet well-defined task. Say, ‘this is going to take two to three months’. And then discover that estimating for the next two days is extremely difficult. Perhaps the answer is in David’s counter entry agile estimating:

An agile estimate should have a number of value units, a velocity, an end date and a buffer (or a measure of variation in velocity). That’s it. You shouldn’t be estimating anything individually. Fine grained individual estimates of effort are waste – muda! Just say “No!”

As a sort of ‘training wheels’ (detailed) estimation can be very useful. It helps a team become aware of all the work they are doing, makes the team aware of what they know, what they can know and what they don’t (and sometimes can’t ) know.

Trying estimation in a certain way has to be done consequently for a certain period of time – since the effects of estimation are mostly medium-term. After trying a set way of estimation, the team becomes more experienced, and is able to decide what they want to estimate, and how and why they do it.

Just saying no can be done in a responsible manner, once you’ve experienced several alternatives – varying from no estimation at all to too detailed estimation.

By the way, if you’re having an argument on velocity in your XP team, and you have been doing stories for a while, I definitely recommend David’s recommendation to take into account a measure of variation in velocity.

If you feel velocity is problematic, creating an information radiator for the velocity, and drawing an upper and lower variation band around it (say 5 or 10%) will show you if velocity means anything in the project, or something else is going on.

This was one of the first theory of constraints / lean – related things I took to my practice. The effect was ehm, interesting. I soon realized not everyone in and around the team wanted to see and/or hear that the variation was so large the velocity numbers didn’t mean anything.

Watch for fingers being put in ears when you explain the variation bands in the graph….

I extracted this text from communication skills are hard skills in order to let the point I’m trying to make stand out more clearly. I realized I’ve been using (at least) two ways towards communicating more effectively – ‘simple’ techniques (examples in the previous posts) and models.

Models indirectly modify my communication, because they help me make better sense of the world around me, so I can be more aware, fully present and (re)act more effectively. For me the most powerful in the past three years have been Systems Thinking and the Satir tools.

Recently Nynke Fokma, Marc Evers and I co-created a tutorial around three Satir tools (congruent action, the interaction model and the Satir change model ): Congruence in action

I find the idea of congruence especially powerful – actively balancing self, other and context.

It helps me to be hard, as in tough when it is right to do so. It is also hard, as in difficult, to master. With the people from agile systems we play blame games, making fun of our own incongruence, or be incongruent in another style dan the persons ‘default incongruence style’ – aka coping stance.

If you want to know more about coping stances, I recommend the book Congruent Action by Gerald Weinberg, or a trip to Agile Open, where we hope to run a trial version of the tutorial.

Playing the blame game probably only works with a small group of people you trust. As time goes by, practicing and playing games make it easier for me to recognize my own and others’ coping stances, and adjust my reactions to that.

Esther Derby is writing on stopping to use the words soft skills and instead use communication skills.

Communication skills can be anything but soft. As an example, communication skills can make it easier to see through other people’s games and play ‘hard ball’ in a correct way. I like the comment written by Jason Yip:

I don’t even like to say conversation, confrontation, collaboration skills are “non-technical”. There are reliable techniques for these sort of things and “non-technical” seems to me a subtle suggestion that it’s all magic.

I’ve picked up a great deal of communication techniques over the past few years, thanks to training courses, personal coaching, intervision with colleagues and organizing workshops and conferences. It’s not magic, but the effects can feel magical, liberating. I’ve picked up some techniques which are directly applicable as such. Examples of techniques I learnt or improved are making sure I make eye contact with the person I’m conversing with, creating rapport (from NLP) and standup meetings.

Sometimes I learn these things quickly, others take more time to master, even though the idea is simple – changing my behaviour is not always easily done – that also makes communication skills ‘hard skills’.