This blog has moved. Go to for the latest posts.

Tuesday, June 20, 2006

Day 1 at XP 2006 conference, part 3

The last event for today was the keynote speech by Brian Hanly (acutally it was Sean Hanly who did the keynote, thanks Lasse for the correction), founder and director of Exoftware which is a major sponsor for the conference.
His point in the talk was that Agile needs to cross the chasm of adoption from the Enthusiasts and Visionaries to the Pragmatists (implicit in the talk was that Pragmatists are managers and top-level managers). In order to do that the Agile crowd needs to start talking in a language that the "pragmatists" understand, in papers/publications that are important for those same pragmatists. For Brian this requires that Agilists need to understand that we can't use phrases like "You organizational stack is corrupted" or "You have to refactor your organization" or "Your management build is broken". His argument is that we need to be able to speak a language that people understand in order to get our message across. He went on to narrow the point down and to state that we should from now on use stories when communicating the benefits we see in Agile to Pragmatists.

I must say that I agree with him in above points. However he went on to say that we, Agilists, need to make this change to be able to more successfully sell the idea of Agile software development to the whole software community and to avoid ending up in the "graveyard" or. In this point I disagree, I don't think that there is an intrinsic value in having Agile methods distributed to the whole industry. I believe it will happen, but I don't think it should be an Agilist's mission to disseminate Agile methods. The methods will be adopted _if_ and only _if_ they are proven to be effective.

I also believe that Agile is just a step towards an even better way to develop software, and I would not like to get bogged down in "evangelizing" the world at large and miss the bigger picture which is "we need to perfect software development every day", "Agile" is just the word of the day. Tomorrow I want to be where the best results are, Agile is just a stepping stone, even if a very important and even fundamental one.

Let's not "fall in love" with Agile, let's "fall in love" with improving the software development process.

at 09:15 | 1 comments
RSS link

Bookmark and Share

Day 1 at XP 2006 conference, part 2

During the morning session for today I attended the research paper session presentation on "Foundation and rationale for agile methods".

There were four papers:

  1. Distributed cognition account of mature XP teams: in this paper presentation the thing that struck me the most was the practice of "fluid pairing" as described by the presenter. In this practice the team decides on the spot how the pairing should be, for example: if you signed up for a task where you should be pairing with a person on a certain task and you find out during the actual pairing that you are not the right person to be pairing with for that task you can suggest that the other person choose another pair for that task. I'm simplifying the idea here, but that was the core of the idea.
    Why I liked it is that I feel that sometimes we are slaves to the practices, what I mean is: "I signed up to this pair-programming task so I must need to see it through even though I could be adding a lot more value to the customer by doing something else" - this is the wrong way to think about it. Pair programming just like any other Agile Practice should be a productive tool, not a burden. If you feel that you are pairing in the wrong task you should change.

  2. Decision making in Agile Software Development: in the presentation the author tried to show what are the differences between "mentor/manager" type people and "developer" type people when approaching a decision. The main differences that she noted were:

    1. "developer" types tend not to search for solutions in a book (prior knowledge?) and "mentor/manager" types tend to do that.

    2. "mentor/manager" types will think of different alternatives before implementing a solution to a problem while "developer" types will go with the first solution that works. This, she pointed, makes the current metrics on "optimal design" obsolete as "developer" types do not strive for an optimal solution, they just design something that works. (my note: This is also why we need refactoring)

  3. Software development as a collaborative writing project: The author described the process his team went through when writing a fairly complex system to calculate retirement insurance policies. The system needed to take into account large amounts of knowledge that was hard to codify, so what they did was to define a coding standard that was understandable by the domain experts (also future users of the system) and use an interpreted language so that he could write a prototype and show it immediately to the users/experts without any other overhead. By showing the programme to the users he was able to get immediate feedback. When they found a problem (the user inputed some data and the answer was wrong) they were able to stop the system and walk through the system-state because of the interpreted language and change it on the fly so that the programme would start returning the right values. As the coding style was done in a way that the users/experts could actually read the code, the programmers were able to work with the users/experts while looking at the algorithms and change it there directly with user/expert feedback about how the algorithm should work.
    At the end the author made a point that I consider important: we are suffering as a profession from inventing languages and coding standards that our customers/users can't read. In this particular environment they could obtain a lot of value from having the customer understand the algorithms by looking at the code, and this made the project also a "collaborative writing experience".

  4. Job satisfaction in agile and non-agile software development teams: In this paper the authors presented the results of a survey where they studied the job satisfaction rates between Agile and non-Agile teams. What they found is that the number of satisfied and very satisfied people in the Agile teams was much higher than in the non-Agile teams. They did make a point to state that happier teams are not directly more productive, but that happier people cause less turnover which in turn reduces the costs of dealing with that turnover for a company therefore increasing the productivity for one particular company.

In the afternoon session I went to a workshop on patterns of adopting agile development practices. The organizers are collecting content for a wiki on patterns of agile adoption, and the participants contributed with their own stories/solutions to that effort. The session was all in all quite interesting especially when we got the opportunity to discuss the assignment in smaller groups.

at 09:10 | 0 comments
RSS link

Bookmark and Share

Monday, June 19, 2006

Day 1 at XP 2006 Conference

The day started today with a talk from
Pekka Himanen about the Hacker Ethic.

His introduction on how the Open Source development teams are able to produce so much and so high quality code was interesting as it was rooted on his Learning Philosophy and how interaction between people can make a team/community much more productive than the sum of all individual parts.

The talk was very interesting as it contrasted the often "gray" and "dull" environments in many companies and the dynamic and enriching environments in Open Source communities (even if people don't really meet face-to-face often or sometimes at all).

He also explained how a 12 year old can submit a patch to a problem on the Linux kernel that gets accepted. He explained that this happens not because that 12 year-old is particularly much better than all others, but because that 12 year-old starts with a passion to solve a problem, ask the questions on the NET and go on to build their solution on the knowledge of many other people in the community. They act as a synthesizer of the community's knowledge and in the process learn a great deal about programming and the subject being handled.

This was a good example of how learning can be so much more effective in this type of communities.

at 10:56 | 0 comments
RSS link

Bookmark and Share

Highlights of Sunday tutorials on XP 2006 conference

Yesterday was my first actual day in the conference here in Oulu. The day started for me with the tutorial from Mary Poppendieck about Lean (Agile) Software Development.

I had read her book and learned from it a lot.

In the tutorial she touched on several interesting aspects that are not very obvious from the book. The ones that I found more interesting were:

  1. A (large) defect list in a company usually acts as a buffer between the developers and testers, a bit like a SLA (Service Level Agreement) measurement between both organizations, but that effectively prevents communication from happening between both organizations. Mary pointed to an example of a project that had around 51 defects listed throughout the full length of the project (3 years), why that happened was that people went in and fixed any bug that was found.

  2. Mary advocated a "stop-the-line" policy for bugs/build failures and similar problems. When a bug is found or if a continuous integration build fails the whole team should stop committing until the problem solves.

  3. Another point mentioned was the "capacity dilemma" for managers. Normally managers like the idea of "everybody being busy", of course, according to Queuing Theory this actually means that people are a lot less productive as there is no buffer to accommodate variability in the arrival of work. She gave the example of Google that has the 20% rule - in which developers are allowed to use 20% of their time in their pet projects, but of course, when there is "crunch-time" they do have that 20% extra to absorb the extra work-load.

at 10:42 | 0 comments
RSS link

Bookmark and Share

XP 2006 conference starts

Today started the
XP 2006 conference here in Oulu. I have a lot of positive expectations regarding this conference. Reading the proceedings from last year's conference I got a lot of great ideas to apply in my work, I expect that this year, being present will be even more productive.

at 10:40 | 0 comments
RSS link

Bookmark and Share

Monday, June 12, 2006

What "done" means and it's importance.

Today a colleague at work described his experience with one of the principles of Scrum: "Done means done".
This very simple phrase has very deep implications. One is that you are never really done until a feature is ready for release. Some teams will define that differently, but his team defined that "ready for release" meant that all major bugs in the feature should be solved and only small issues could be left out of the feature if needed.

When they planned the schedule for that feature they were over-optimistic (like it invariably happens in software, according to my experience), they had 1 week scheduled for the feature but by the end of a 4-week sprint they still had many major bugs waiting to be fixed. Instead of succumbing to the temptation of calling that feature "done" (after all they had spent already 4 weeks with it, not the original 1 week) they faced the stakeholders and said: "we are not done and we need more time for this feature". As it happens they had a pretty convincing argument for continuing with the feature, it really had been more complex than they thought and in the process of fixing bugs they had found other non-trivial issues that really needed to be solved before they could honestly call that feature "done". The project management agreed, and the new sprint started with them looking again at the same feature and fixing all the issues they thought were required.

Now, a few weeks after the end of the second sprint for this feature they are happy about the decision they made and have said that not only did they actually get that feature really "done" (i.e. they feel they do not need to touch it until the end of the project), but they also found many issues that normally (based on historical evidence) would be found only 2-3 years later in a customer environment.

What I get from this story is that I've seen this pattern repeat itself over and over again with teams that give Scrum (in this case) or Agile a good, honest try. Invariably Agile software development leads to:
- Teams growing and learning new things about the software development process that they were not aware of before;
- Software being produced with higher quality due to the "done" rules that the teams set for themselves.

at 10:17 | 0 comments
RSS link

Bookmark and Share

Thursday, June 01, 2006

What is so hard in a retrospective? People.

I've been doing
retrospectives for a while at work. They have become so useful and part of my understanding of continuous improvement that I've started doing them at the end of every meeting or presentation I hold. The point being that I know I can improve, and it's excellent that I have the opportunity to get feedback from the people that "suffered" through the meeting and may have (and usually do) some good pointers on how I can improve the meeting culture or a particular presentation.

Today a colleague at work asked me what is needed to do a successful retrospective with a project team (more precisely a group of scrum masters in a multi-scrum project).
What I answered him was that the process (of the actual retrospective meeting) is not as important as the people aspects of the meeting.

In a retrospective the hardest thing is to make sure that all people feel at ease to talk about the real problems that any project faces. What is hard is creating that relaxed yet serious atmosphere where everybody can talk about serious issues but still take it lightly enough not be offended or feel personally attacked when their actions are under criticism. If you fail to create this atmosphere you will not have any of those "eureka" or breakthrough moments that successful retrospectives can bring.

I believe this is the key to a successful retrospective. In one project we got to the point where we could criticize each other's actions (not the people!) very much directly without beating around the bush, but we had at that point invested a lot of time (and some money also) in creating a very open atmosphere in the project. To achieve this level of honesty requires you to work at it during several sprints/months (it took us at least 7 months to get there).

All in all if you are looking for that "Eureka" feeling in a retrospective don't expect it in the first few ones you hold. They will come, but only when you have been able to make everybody feel "at home" with each other.

at 21:32 | 1 comments
RSS link

Bookmark and Share

(c) All rights reserved