There is a lot to say about leadership. Personally, I consider it a skill that needs to be honed – and developed. There are lots of bosses in the companies out there that don’t have a clue about leadership – neither do I. I attended a couple of courses on leadership. It started off with a course called “From colleague to boss”, and I attended the Problem-solving Leadership course with Jerry Weinberg, Esther Derby, and Johanna Rothman. Most of them only made me aware about the things that I didn’t know, and the possible directions that I needed to learn more about. Let’s see where I have failed on leading dramatically in my past.
Continue reading Where I failed to leadTag Archives: it-agile-blog-planet
More learning as a professional
This morning, when I took a look at twitter, I noticed a direct message from Michael Bolton on my latest blog entry on learning:
In your blog post on learning, you’ve left out community, and bafflingly to me, practice.
Wholeheartedly I thanked him for the idea for today’s blog entry.
Continue reading More learning as a professionalLearning as a professional
Testers and programmers are much more alike than some people think they are. Many of us work in organizations, some of them large. There are several dynamics in these larger systems that have an impact on our habits, shape our culture, and influence our private lives.
There is something to say about professionalism, and the practices of our craft. Where and when should we learn about such stuff? Let me tell you my personal story. Though I will refer to software testing, pretty much the same also holds for programming, and most programmers I have seen in the organizations out there.
Continue reading Learning as a professionalScaling Agile – really?
There seems to be a buzz around scaling agile around lately. A couple of weeks ago I saw a tweet from Gabrielle Benefield that made me think.
Why is everyone hell bent on scaling Agile when they have trouble even getting one team going?
That question reminded me about a lesson I learned from Don Gause, and Jerry Weinberg in Are Your Lights On? What’s the problem? Who has the problem? And who should fix it? Let’s see.
Continue reading Scaling Agile – really?Five years of fighting crappy code
Today marks the fifth anniversary of the Software Craftsmanship manifesto. Doug Bradbury asked me the following question:
Do you think that the bar of professionalism has been raised in the 5 years since the Software Craftsmanship Manifesto was published? Why or why not?
My short answer is “yes” – and “no”. Being around since the early days back in November 2008 when I joined the Software Craftsmanship mailing list, and having been involved in the different thoughts on the Ethics of Software Craftsmanship, my longer answer hides in this blog entry.
Continue reading Five years of fighting crappy codeThe worst thing about electronic tools
A couple of weeks back, I became aware of a fact about electronic tools that gives a large drag to using it. I see lots of teams struggle with electronic tools. Most of the times these work with a raped bug-tracking tool used for – well, I think – status reporting towards their ScrumMaster during the daily Scrum meeting. That’s broken on so many levels – at least that’s what most team members reported to me when a particular tool was inflicted on them. The infliction usually happens either by sunken cost syndrome (“we invested XXXXX amount of money in that, you need to use it!”) or other self-imposed factors causes (“we work on twelve different planets”, “this paper thing is too touchy for me”, “we are green here, we don’t kill trees”). Let’s explore some of the reasons behind that, and try to come up with clues on why these are broken, and what I think the worst thing about these is.
Continue reading The worst thing about electronic toolsOver-correction
When I became a swimming trainer, I had to learn various ways to teach kids how to improve their swimming strokes. As part of a seven weekend education course, we not only heard about stuff, but also had to give training lessons to our classmates that proved that we were eligible to the trainer certification. In these courses I learned about a gentle technique that I lately noticed to apply in other fields as well – whether appropriate or not.
Continue reading Over-correctionSoCraTes 2014
I remember when Andreas Leidig approached me in late 2010. He wanted to get a discussion going regarding a conference on Software Craftsmanship in Germany. We decided to meet up during XP Days Germany in 2010, and see what we could do. We quickly agreed on an unconference format, two days, somewhere laid back. Some folks had organized the German Agile Coach Camp and Play4Agile in Rückersbach close to Frankfurt. We decided on that spot as well, and organized everything for 2011.
Early on, we decided that we will need outside support. That was when we started to reach out to other craftsmen, like Micah Martin, Adewale Oshineye, Sandro Mancuso, and many, many more. We had around 10-20 participants from outside Germany with us. All the tales they told us on how they were running things in London, Israel, Finland, you-name-it engaged us. It felt good to be around so many like-minded folks, and receive outside inspiration.
The first SoCraTes – Software Craftsmanship and Testing (un)conference – was a success. We had some track sessions back then, and a full day of Open Space. During the Open Space I joined a session that was looking for how to continue. With all the energy in the room, we placed ourselves on a virtual map of Germany. That was when I noticed, oh, there are a bunch of other folks around me that come from a similar location as I do. That was also when we decided that we needed to keep that spirit going.
One year later, we came back for SoCraTes 2012. Since the first conference we had founded 10 user groups all over Germany on Software Craftsmanship. There was one in Hamburg, one in Karlsruhe, one in Munich, one in Nürnberg, one in Berlin, one in Frankfurt, one in Dortmund, one in Düsseldorf, and one shared around Münster, Osnabrück, and Bielefeld. We created a timeline of events that had happened in the various local communities since our first get-together.
We were amazed about the various events, code retreats, user group meetings, and so on.
We still adhered to reserve space for foreign inspirations at that time. We had 10-20 people from outside Germany with us. However, Rückersbach had just 70 beds overall available. With ten local user groups potentially joining our unconference, we faced a serious problem. From each location just around 5 people would be able to join. So, with such a large community, we already excluded many potential attendees.
The format of the unconference had shifted. We had abandoned previously-set track sessions all-together. Instead we focused on two full days of Open Space. That provided the freedom necessary. Here’s the schedule from the two days in 2012.
At the end of the day, we decided to run the conference again in Rückersbach, but have it organized by a different group of people. We explicitly decided to pass over the organizing responsibility to one of the local groups from year to year.
Last year, the limited amount of beds became a problem. We discussed again what to do about it, and asked the organizers to seek a location that may scale up to 200 participants.
Rückersbach had an advantage: it was close to Frankfurt airport (about a one hour ride by car). That made it easy for people from other countries to attend, since Frankfurt is the largest airport in Germany. It would be hard to find such a spot with more beds in such a good position.
Late last year, the organizers contacted me. Since I am working in Hamburg, they asked me whether I could take a closer look at a potential spot for 2014 that sounded promising. They had 200 beds, and were located in Soltau. That’s about a one hour ride by car outside from Hamburg.
I agreed. When I finally made the trip there, I was amazed. The new hotel was awesome. There are ten meeting rooms all set up with video projectors, flipcharts, and so on, one central place where everyone meets, one large room for the Open Space opening, a bar with space for 170 people in the evening, a swimming pool, decent space outside close to nature. I got back to the organizers and told them that this spot would preserve the privacy that Rückersbach had with it, and that it seemed to be perfect to scale.
Now, I know that the announcement for SoCraTes 2014 is coming closer, and I can’t wait for the registration to open. Unfortunately I probably will only be able to attend on Friday, since I have a trip to the State to make for an AST board member meeting and CAST 2014 in the following week, but I know that I have to be there.
SoCraTes 2014 is scheduled for August 7th (evening arrival) to 9th, probably with a code retreat on Sunday, August 10th. I know it will be awesome. I know it will be full of craftsmanship, coding, and conferring. I know it will be worth my time. I now it will be worth the trip. You should reserve the date, too.
P.S.: Last week, I also heard rumors that the fine folks organizing SoCraTes 2014 are looking for sponsors. There will be different sponsor packages, some with free slots available. You can meet a bunch of fine folks there that are the top-notch in software development in Germany, Europe, and probably even the world. If you want to support the craft, please tell your bosses. It’s worth their money.
P.P.S.: Did you know that the UK folks – yeah, those that heavily influenced us in the first year – brought the same format to their country as well? I attended SoCraTes UK last year, and it was similarly awesome to the German event. They are organizing another event this year in June. Reserve the date as well.
The elite foreman
It turns out that Uncle Bob had some more to say on the role of the foreman, and how it applies in various situations. However, I have totally different experiences.
Continue reading The elite foremanThe situational foreman
A couple of days ago, Uncle Bob Martin blogged about the foreman in software development. In it he makes some claims with regards to a role in software development that acts like a foreman on a traditional construction site. Uncle Bob claims that the foreman should be the master of having commit rights, and granting those to team members that prevailed long enough. While the idea reminded me by-and-large to the practice on some open source projects, I am not so sure whether we should start installing foremen (and forewomen) all over the place. Let’s see why.
Continue reading The situational foreman