Category Archives: eXtreme Programming

Published new stuff

Since I’m not only a terrible blogger but also a terrible self-marketer, I tend to forget to mention the things I’ve published so far.

But today I want to introduce you at least to some of them:

To start with the most recent one, there is an article on Pomodoro Technique from my colleague at crealytics, Martin Mauch, and myself. It’s been published on Projektmagazin: http://www.projektmagazin.de/artikel/mehr-schaffen-in-kuerzerer-zeit-die-pomodoro-technik (sorry, English folks: It’s in German only).

The second is a book which has been published last October. I had the honor to contribute a chapter to Henning Wolf’s “Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen”, which is focused on case studies from hands-on folks. Of course, my chapter was about Agile in startups. (And: Sorry again, German only, too)

Last but not least, I want to mention a book which is on the market for quite a while, but fortunately, it seems to become a classic: The PHP QA book aka “Real-World Solutions for Developing High-Quality PHP Frameworks and Applications” (yes, finally, in English! :-)) and “Softwarequalität in PHP-Projekten” (German Edition). Also available on Kindle.
It’s partly theoretical knowledge, partly case studies. Mine was on QA with Selenium at studiVZ, together with MAx Horvath, so maybe I mention it for sentimental reasons (good old days!).
But the book itself is an invaluable compendium for any kind of testing in the PHP world – have a look at it.

Enjoy reading!

XP Days Germany, Day 2 (part1)

Day two is over and I’m lying in my bed, happy but tired, and try to keep my eyes open until I’ll have clicked the “publish” button in ScribeFire.

First things first: Some people said to me that they had read my blog posting on day one. What nearly everybody told me was that they’d had the discussion about either German or English talks in the past. And that they’d had more English talks some years ago. And that it is a strange scenario if Germans talk to an audience of just German people but speak English (and some listeners have difficulties to understand it). Ok, I have to admit: In this case German may be the better option :).
Just to make it clear: I respect this decision, result of experiences in the past. I’m sure that this is pretty well thought-out. And I didn’t want to blame people who had made this decision. It was less about criticizing something or someone but more a public reflection on my own personal feelings and thoughts. Personally, I really love getting in touch with an international community and I’d really appreciate it if this also would happen in Germany. Nonetheless, even more than that I appreciate a well-organized conference with happy people on it – and that’s what XP Days Germany seem to be.

Anything else? Oh, yes, there were some sessions today – two dozens in four parallel tracks, to be precise. I attended “Creating Leaderful Teams to Achieve High Performance” by Deborah Hartmann Preuss. It was a great talk on changing mental role models – as a member of a team, but even more important: as a manager. Because that’s the topic I’ve been obsessed with for nearly one year, it was very valuable for me to hear from her insights, compare, adapt and question her points. To be honest: There is just one I question (and I needed some hours to think about it): I’m not very happy with the term “egoless team”. I know, many trainers make use of it. Maybe I’m too sceptic because of my personal spiritual background. Every time someone starts talking about “egolessness”, I become very carefully: In most cases this is the beginning of deliberation, of suppressing individualism. It doesn’t have to be used this way in Agile, but I know that talking about “egoless …” can be a mighty weapon.
Back to the point I agree with: The key thing is that the term “Agile Manager” is an oxymoron. But what is needed instead is an “Agile Leader”.
A leader as a
– Meaning Maker
– Catalyst for Growth
– Model of Integrity
– Cultural Change Agent
– Facilitator
Deborah Hartmann Preuss explained in detail how she understands each of these roles.
I could mention many details of this talk, but I’ll pick out just two more points: The meaning of retrospectives. “If you wanna do just one agile practise, choose retrospectives.”, she said. Why? Because this is the most important opportunity to step back and reflect as a team. To remind Albert Einstein: A problem cannot be solved on the same level where it has been caused. Stepping back means changing the perspective, the level. Same thing for leaders. Integrating a retrospective in the working routine of the team extends work from single loop to double loop. Single loop work means working on efficiency (doing things right). Double loop work means working on effectivity (doing the right things), because you reflect on your work and learn more. But a decision for effectivity on costs of efficiency has to be made as a top level management decision. Once again, an act which needs a step back and some reflection.

Furthermore, I had other very good talks today: “TDD with iPhone OS” by Tammo Freese and “Science Scrum: Agile Project Management in Science” by Michael Podvinec and Joseph Pelrine.
In addition to that, a very entertaining final of “TDD with the Stars” and Alistair Cockburn’s Keynote on Hard-Agile (subtitled with “Agile is for wimps!”…).

I hope I’ll find some time tomorrow to write more about these sessions. Now it’s time to close my eyes (and hopefully not to dream of Agile Jeopardy: “Was sind Haftnotizen?”)

Powered by ScribeFire.

XP Days Germany, Day 1

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.