Well, first day of German XP Days is over. For all of you who couldn’t come, I’ll try to give you some insight:
I personally started today just after lunch, since the tutorials in the morning had been sold out. But doesn’t matter, it’s just the warm-up day and a good warm-up day doesn’t start before lunch!
The first session I attended was “Am Ende entscheidet das Naturell” – together with title comes the first hint that XP Days Germany are really quite… ehm, German. Almost every talk seems to be in German – which is on the one hand ok for a national convention. It gives German people the chance to join the agile community, even though they don’t understand English. On the other hand, it excludes the few people from other countries, who are here. And keeps potential visitors away. I think it’s sad to miss the chance to let them participate. Actually I’m of two minds about this question. Maybe it’s not a general question, but a question of personal taste. I tend to the international variant. Or as a compromise, at least one track in English, the others in German.
Ok, back to the talks: “Am Ende entscheidet das Naturell” means something like “Finally, the temper (disposition) tips the balance”. Dierk Koenig from Canoo talked on citeria how to categorize people at work.
He mentioned several models for characterizing people, like well-known Myers-Briggs model and “big five”, but the difference between these models and the approach they use at Canoo is the fact that one doesn’t need to know everything about his employees’ personality, but just about a few criteria, e.g. “What is your approach to collecting infomation?”. “Focussed” and “Holistic-associative” were the left and the right end of a scale. In the model they use, just 4 of these criteria had been filtered out. The second criterium was extra- vs. introversion (communicating with others), the third was self-organization (structured vs. flexible) and I have to admit that I’ve forgotten the last one (I think it was sth. about innovation…).
Depending on your personal likes and dislikes, you can draw a scheme of which roles and responsibilities you’ll probably take over in a team. Because the four dimensions with its two extremes in each case relate to eight steps in a working process or to eight roles in a team.
Well, I like the pragmatical aspect of this approach. Dierk Koenig pointed out that they use it sometimes in team retrospectives. As an example, he showed a photo of a map with eight fields, one for each role. Each team member had put a big stone on a field for his key strength and smaller stones for supporting roles. Some fields had many stones, some of them just one. So it became very clear to all who looked at the photo, which roles could turn out as risks.
But in my eyes the most valuable sentence Dierk said, was in the beginning of his talk, when he reminded us of the Agile Manifesto: “Despite we are talking about Agile, most people are still talking about processes and tools. But we should stop talking about processes and tools, we should start talking about people.”
The next session was a Pecha Kucha session. I had heard about this special form of presentation before, but it was the first time I saw it. It’s some kind of lightning talk. A speaker has a topic and 20 slides for that. Each slide has exactly 20 seconds to stay. That means: 400 seconds left for a talk, 6 min. 40 sec.!
Things I like: You try to tell people a story. Everything which is unimportant will be left out. The slides don’t have any bullet points and don’t have much text. Mostly, they’re just pictures. And they only support the speaker’s message. Of course, everything I mentioned can also be valid for a regular talk, but to be honest: Most talks are different, people don’t care about these rules. In Pecha Kucha, people are forced to do so.
We had three talks in this session. “Stop the Line in Software development” by Stefan Roock, a very useful talk on really stopping the production process in case of failure (like Toyota does). “Our Journey to the Land of Agile”, an experiential report by Markus Adrezak and “I am packing my Agile Suitcase” (I have no clue if this game, well-known in Germany, is also known in other countries!?) by Holger Koschek, a talk on the most important values, principles and tools in Agile. Each talk was very good. But form impressed me even more than content (maybe this is the disadvantage of Pecha Kucha).
I missed the TDD session but I heard from others that it had been very good – and totally overcrowded. :-)
The last talk for today was “Wissensinseln – Schadbild, Bekämpfung und Vorbeugung” (a very typical German title! Can maybe translated with “Islands of Knowledge – Symptoms, fighting and preventing them”). Though it was the last session, Jens Coldewey managed it to get my full attention to his talk. He talked in a very engaged manner on this topic. The main part: How to realize that your team has a problem with sharing knowledge. He showed some indicators which I’ve been knowing very well: Some remarks during the sprint plannings, “This task can only do XY” or “I have nothing to do”. Or the fact that stories are not done the order they were prioritized, but in different order (“that’s because the first story is XYZ’ story and we carry on with the second (third, fourth, …) story”). Another indicator is a chart with story points a team achieves per sprint. If story points hit rock bottom every time when a particular team member is ill or in holidays, then you know that something goes wrong.
Afterwards we had a lively discussion about how to prevent it. I think it’s even the easiest part to prevent it amongst developers: You can do pair programming, code reviews etc. But nobody had a good answer to the question of knowledge transfer within a *cross*-functional team itself. How to handle knowledge transfer between developers, sysops and designers? How not to overburden the team’s only sysop? And how much knowledge transfer from a sysop to a programmer and vice versa is necessary? And how much is useful?
That’s a topic I’d like to see being placed on the Open Space agenda on Saturday. I’ll put it into the discussion once again.
Powered by ScribeFire.