I was lucky enough to recently attend the XP Days Germany 2009 in Karlsruhe. It was a great experience.
In the morning on the first day was a choice of two tutorials or workshops. I attended one workshop on facilitating skills, which I choose because it was right outside my comfort zone. I think it was a great start to the conference to be pushed into some active participation with the other attendees. It focused a lot on exchanging information amongst ourselves, about the various types of situations, not just meetings, where moderation is required, and some of the tricks that others use. At the end we had to write down one goal or thing to do as a result of attending the workshop. I wrote down “Seek out opportunities for practice.”
The first presentation I attended was “Am Ende entscheidet das Naturell” by Dierk König. The main theme of the talk seemed to be criticisms of typical models for categorizing people, such as the Myers Briggs Type Indicator, CANOE etc. I started to think it was a criticism against all such models, But then he introduced us to his favorite model, the Margerison-McCann Team Profile. I find such models very interesting, providing they are not misused. I think allowing a team to learn more about itself, and assign roles based on interests is a good use of a model like Margerison-McCann. Just for fun I tried looking for a free online test to evaluate myself according to the model, but couldn’t find anything but traces of a test that gave a “similar to Margerison-McCann …” evaluation. I couldn’t find the actual test though. It seems as if it is a fairly highly protected model, requiring certification and of course payment before one can make use of it.
After that was a Pecha Kucha session of very high quality. I had the opinion that the format itself may encourage high quality presentations, but the two sessions on the following day were less impressive, but they were also in a different room so perhaps acoustics were a factor.
During the afternoon tea break, was a TDD competition, where pairs could demonstrate in a short time how good they were at TDD, pair programming and refactoring and be judged by a jury for it. The best two teams, of the four, went on to the final round the next day. I noted then, how pleasantly refreshing it was to be at a conference not dominated by Microsoft, not one of the teams were using languages or development tools from Microsoft. In fact for the whole conference I didn’t see any use of MS languages or tools. The languages used for the TDD contest were Java, Ruby and Groovy.
The last presentation of the day was about knowledge silos, from Jens Coldewey, and ideas for dealing with them.
The following morning I attended the sessions “Creating Leaderful Teams to Achieve High Performance”, and 42 Convincing Patterns (that is just my bad translation). So two topics more useful for someone in a coaching or convincing role than in a technical role, but it is good for me to choose topics that are outside my comfort zone, and help pick up ideas that anyone can use. Especially in self organizing teams. Overall I found a surprisingly high coaching presence there. Not just because talks for developers are often given by coaches, but a lot of talks themselves were about coaching. I almost had the feeling that there were as many coaches there as developers. Which either means there is an oversupply of them, agile teams really need coaches, or the XP Days is not so representative of the true agile community, and a lot of developers felt it less valuable to attend than coaches. I suspect all three are valid to some extent. In fact one coach even suggested an open space topic of how to move from coaching to developing.
After the morning tea break, I attended a presentation on using Kanban with product maintenance, which combines two of my favorite topics. It was a hard choice though. Another presentation at that time was from Andreas Boes about the role of agile in the industrialization of software development, which would also have been extremely interesting. Some of the tweets coming out of it made me wish I had chosen that one.
The hashtag on twitter by the way was: #xdde09
Following that was the second Pecha Kucha session, lunch, and the final of the TDD contest.
After the lunch break was the keynote from Alistair Cockburn. Very inspiring stuff. The one thing that stuck for me was his mentioning of craftsmanship. He said that in the first half of the 20th century, craftsmanship was the basis of engineering, (I am just paraphrasing here), and after that they kind of removed the craftsmanship element from it. After a lot of the discussions I have had about craftsmanship seem to involve comparing it to engineering, being able to view it instead as the core of engineering should prove a very insightful step in the direction of more professionalism in software development.
After that was the third Pecha Kucha session and a session on being a member of an agile team, which was good solid information, but for me nothing really new.
Arguably the most valuable day ways the community day on day three. It consisted of a short World Cafe session at the beginning, followed by an Open Space for the rest of the day. We were able to have many smaller sessions rather than few larger ones, which was great as I find open space works best for smaller sessions, without needing to do things like fishbowl etc. The two sessions I actually sat in on completely was the one on software craftsmanship, which was inspiring, and Alistair Cockburn also hosted a general “Whatever U Want 2 Talk About” one, which was a great chance to chat with one of the manifesto signers.
I did write a short list of notes, mostly trying to concentrate on things that I could actively bring to my day-to-day work especially with regards to developing myself as a software craftsman. Some of the things I listed were:
- Cumulative Flow Diagram. This is a technique for tracking Kanban processes etc, but I am also going to try and use it to track our Scrum process within our team, and see if it brings any insights.
- Sprint Burn-Up Chart. I am also going to practice this technique, using our work sprints.
- I am going to try and think in points.
- I am going to try and convince management that tracking the hours that individual developers work on things is counter productive, and impedes the craftsmanship ethic, and try and encourage a focus on looking at things at the team level, using the information radiators that we already have.
- Craftsmanship is the forgotten core of engineering. I want to read more about the history of craftsmanship and engineering and change the way I look I at how the two are related.
- At the start of each new story, I will try and get as close to the customer as possible (which will normally not be the customer but someone in our company that understands things from the customer perspective rather well) and try and see with my own eyes what needs to be done etc. Ideally I will do this together with my pairing partner, and/or my acceptance test writer.
- Look into forming some mentor / mentee type relationships. I know ACM has such a program.
- Encourage a personal responsibility over tools etc. I know there is an initiative at work to set up some sort of automated system setup, but I think this separates the developer from his tools. I think the process of having a new developer set up his own PC with his developer tools is not a waste of time, and a valuable process to go through. Of course there are a few points where we need to have the same settings etc, but generally, a developer should have the freedom to set up his environment how he feels most comfortable.
- In the course of a sprint or even a week, I will try and pair with everyone in the team.
- I will try and run my workspace / desk / PC like a craftsman will run his workshop. Keeping things tidy and well-organized, knowing where everything belongs and exactly how everything works.
- I will try and develop a craftsmanship codex.
- Katas, Dojos, Reviews, Pairing
- Our team should really be encouraged to implement their own changes. Usually we might identify problems in our retrospective that just get reported up to management to solve, and changes get imposed on us from the management level down. This undermines both the retrospective concept, and the concept of the team itself. Solving our own problems is a prerequisite for developing as a team. Particularly things like process change should occur at the team level.
- I shall perform some root-cause analysis of every bug and error, both those within the sprint, and those reported from support, and present the results at the retrospective.