This page is a diary of our activities, as we try to transition to ExtremeProgramming at UdNeueMedien. The thoughts and observations herein are mainly written down by JiriLundak (so often they reflect purely my very personal view of things) and maybe other team members, as well.
We will try to capture the progress we make as an XP team and hope to look back once in the future and reflect on what we have done.
Prelude
In early January of 2002 our team at UD Neue Medien became increasingly aware, that we were in need of a change in attitude, behavior and process to be able to keep up with project pressure. You are always in trouble, when having to balance the FourVariables against each other.
Having heard KentBeck talk enthusiastically about XP at OOP 1999 in Munich and having read some XP books, I was thinking, that this was the only way to keep up with the accelerated pace of development. I was even more convinced after having experienced projects at a previous employer, that were not successful because of months-long AnalysisParalysis.
I was happy to see that our management welcomed our change to XP officially, giving us green light to adopt it, under the condition it would have intimate knowledge of what was going on within the team. -- JiriLundak
February 16th, 2002
Having already done some of the technical practices sporadically in the weeks before (like UnitTesting, PairProgramming, StandUpMeeting, etc.), this is actually the first week we tried do it all.
We have set up a whiteboard, where we attach all the StoryCards and TaskCards? (color coded as green respectively white index cards). Unfortunately we have no large offices, so it was a bit hard to find a good place for the board. We decided to append it in the office of our CTO, who also plays often the role of our internal CustomerProxy.
Our first planning game was something, I personally was afraid of. How would we be able to find the right size of stories and tasks? What would the effect be, when a story would turn out to be much bigger, than management and we anticipated and accounted for? What would happen to the fixed price projects that were already sold and terminated, when we would estimate them to take longer than expected?
My fear turned out as unnecessary. The breaking up of projects into stories and further into tasks, helped all team members to be more realistic about the complexity of the tasks at hand.
There is a big bulk of stories we have already articulated to fill up the next n iterations. Currently we have chosen to do one-week iterations and one month releases. I hope we will be able to keep up with this pace. A question arises: How far into the future should we plan?
An interesting observation I made during our first IterationPlanning meeting: A developer noted at the end of the meeting: 'If I had to do it myself, I would not have thought of about half the tasks, that are needed to complete the story.'. Should it be really true, that we think of more facets of a story, when doing the planning all together? I think this is the first positive sign, that we are likely to catch more of the real requirements, than doing some analysis all alone in one room with paper and pencil. -- JiriLundak
February 22nd, 2002
Are one week iterations too short? This question crept up in my mind during this week. It seems sometimes, that with one week iterations you spend too much time with iteration planning - say the whole Monday morning - and not enough programming, to get anything accomplished. We should limit our iteration planning to what it should be: an iteration planning meeting and not a one year planning meeting. How do you keep the focus of a team to the immediate tasks at hand? It seems though that we managed to have more precise estimates of the tasks to complete our first story. So we have something to cheer about!
Next week I will be off for some Holidays in the SwissMountains?, so somebody other from the team will maybe fill in the missing week of this diary. -- JiriLundak