me.andering – Willem van den Ende

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’.

Agile seems to become mainstream enough to regularly do open enrollment training courses. Rob Westgeest and I just finished setting one up, aimed at software developers who want to experience agile software development firsthand.

We mainly market it through our customers. In a way, the course is marketing itself – since the idea for Rob and me to do this together came from a customer. I hope to write more about how we created this course later.

In a three day hands-on course, Rob Westgeest and I introduce planning, test driven development and analysis skills that enable programmers to more effectively contribute to a thriving business. We combine explanation from our experience with immersive exercises and a multi-day case, resulting in a working system. You can find the course description, organiser bios and dates (all in Dutch – the course can be in English if desired) on the eXperience Agile website.

Today I had a really bright idea…. not. I wanted to safeguard my blog better, by putting my blog and website in subversion, a version control system. I was unaware that subversion does not maintain file modification dates of files after importing. For my website it doesn’t matter, but this weblog depends on the modification dates of the files to sequence the blog entries.

While I was at it, I overwrote my backup and the released version on the webserver. I noticed only afterwards the blog was out of whack. Some aggregators are also affected (i noticed agileplanet was). I re-dated as many files as possible, and those that couldn’t got an old date, so aggregators are not affected too much – in a few days the entries disappear from aggregators anyway.

It’s probably better to start versioning work right from the start, but its’ annoying subversion does not maintain the original dates on import nevertheless. I haven’t even found an option that makes it possible.

Registrations for Agile Open are trickling in – there’s a nice variety of people registering. I noticed several new ideas for sessions have been posted this week (agile

security, XpGame, DrawingCaroussel). Also, the conference schedule is taking shape, thanks to active participation

of various people.

Other ideas (e.g. for non-session activities) will remain welcome until the

end of the conference. This conference is what the participants make it, the co-organisers

provide the container that makes events possible.

So far, we’ve had a lot of positive reactions, also from people who won’t be

able to attend – some want to register for 2006 . I’ll keep you posted

on the feedback I get and other stuff that’s

newsworthy.

I’m looking forward to Agile Open a lot. It is so cool to see something like this grow.

I’d like to point you to a blog entry by Johanna Rothman, What’s a Year of Experience? that clearly articulates a piece of a puzzle I’ve been having for several years. In recruitment and contracting, often a lot of emphasis is placed on how many years of experience a candidate has with X, where X is often a technology (less often a skill). Johanna gives the example of driving:

There are people who never learn from their driving experience in snow or ice. Every year, they’re surprised by the snow or the ice, and they drive too fast (or too slow). These people may have plenty of years of driving experience, but it’s the same year repeated over and over again.

I once worked in a group that had many years of experience programming C and C++. As I was a relative rookie at the time, I felt impressed at first. Until I found out that it was the same year over and over again… Yes, they were very familiar with the ins and outs of the language (those ins and outs haven’t changed in the eight years sicne that project, I was surprised to find out recently).

Unfortunately, they did not seemed to have learnt to work better as a team. At first, I was relieved that we didn’t have that many meetings, and I could ‘just do my job (programming)’ ( I’m different these days….). Until after a few months it dawned on me, that the team was chasing the same defects over and over.

This was easy to trace, as the group had nailed down several practices quite well. Every night an extensive suite of integration tests was run, and defects were collected in a defect tracking system (do you notice how I refuse to use the magical word ‘bug’ here?). Defects were closed and then later on re-opened. Sort of teh same defect repeated over and over again. In the end, the company was taken over, and this particular product was never released, because the new parent company preferred their own version of the product (how strange).

The group was very good at what they thought was their task – programming C with some ++. That is how they recruited new team members as well. I remember a conversation with my boss about a job interview. One of the things they did was see if the applicant understood certain language constructs. My manager exclaimed in surprise to me, ‘this guy did’nt even understand … (some obscure use of the C union construct)’. The uninon construct had at that time been made entirely obsolete by classes in C++. I was smart enough to keep my mouth shut, as I had never used the union construct much, and did not know about this particular use of it either. My manager was very happy about my performance nevertheless….

Years of experience had given her detailed understaning of the C union construct. What the team needed was detailed understanding of team working. Despite the groups individuals being highly intelligent (individuals had MsC’s, PhD’s, patents granted, creative testing skills), the group as a whole had years of experience of the same thing and did not function as a team.

What this group needed was not a new recruit intimate with language details… People can pick up details or entire languages quickly from working closely with teammates.