During the morning session for today I attended the research paper session presentation on "Foundation and rationale for agile methods".There were four papers: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.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: "developer" types tend not to search for solutions in a book (prior knowledge?) and "mentor/manager" types tend to do that. "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) 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".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. Posted by

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.