Wow, the weekend and also the first day in Chicago are gone. Even before the conference started, I had the opportunity to meet many people whom I only knew from books and blogs. On Saturday night, shortly after arriving at the hotel, I met Scott Duncan (@softqual) and Bernd Schiffer (@berndschiffer ) for a drink. We managed to arrange that over Twitter, very unique experience for me. We met in the BIG bar of Hyatt, with a splendid view over Chicago by night, and slowly warmed up for the conference.
Pizza, Chicago Style (pic by George Dinwiddie)
After some sight-seeing in Chicago (recommended: the speedboat trip with the Seadog!), the dinner took place in a much larger round that the day before. Together with @lisacrispin , @HackerChick , @janetgregoryca , @softqual, @jurgenappelo , @bobfischer and many more, we tried Chicago style deep pan pizza: interesting but it takes a little to get used to it. We discussed topics spanning from agile testing and coaching to foldable bikes and australian music. Never before I got connected to a (formerly) foreign community in an unknown city before!
Developing Agile Leaders & Teams, A Developmental and Transformational Path, by Gilles Brouilette
This morning it really got started. To me, the most interesting and inspiring session today was about why 80% of all leaders are stuck on the heroic development levels “Expert” and “Achiever”, as they were defined by Joiner and Joseph. 15 years ago this might have been sufficient, but in today’s complex and changing world we need leadership that is capable of handling those new requirements. The development stages differ by focus (tactical, strategic, visionary), potential for self-reflection, intention and limits. Regular trainings are only “horizontally” oriented, they are developing new knowledge, skills and competencies, but keep the same mindset. And a new mindset is necessary to achieve the next level. Even worse, to break throught the wall to the post-heroic stages “Catalyst”, “Co-Creator” and “Synergist” you need to switch your fundamental paradigmes: from “OR” to “AND”: not me OR you, true OR false, right OR wrong, winner OR loser, black OR white, but me AND you, right AND wrong (depending on the context), etc. You focus on dependencies, underline collaboration and unity. This theory allows for many connections to other publications: The “Tyranny of the OR” from Jim Collin’s book “Built to Last” describes something quite similar to the here required paradigm shift. A characteristic of the “OR”-paradigm are the emotional needs: looking good, winning, being seen, feeling secure, being right, etc. Dropping exactly those comfort zones and open up your inner self to others, showing your vulnerability, this is what Patrick M. Lencioni describes in his five dysfunctions of a team as trust amongst the team.
Book remommendation: Leadership Agility , by Bill Joiner, Stephen Joseph
Personally interesting would be to know on which level I am currently, the tendency is that you rate yourself a little bit better than your “360°” around you. At lunch I had the opportunity to discuss what I just leart with some very nice and great people from Citrix Online, the company behind gotoMeeting, gotoWebinar, etc. Unfortunately the product owner wouldn’t tell me what the current number one spot on the product backlog is 😉
Creating Agile Lerning Games for Coaches & Consultants, by Elisabeth Hendrickson and Chris Sims
After lunch started a very interesting session in which you could learn how to develop your own games, which you could use in training or coaching. Unfortunately the sesion was so long, that I would have missed a lot of others, if I had not left after the first 45 minutes. Nevertheless I took away a few key understandings: When you’re in a context, where games are looked at as being not appropriate, call it a simulation rather than a game (and comment from the audience: make it about money 🙂 ). The purpose of a simulation is tear down expected or existing retentions towards new findings, when they are in contrast to what people currently believe. Instead of telling: “How you do it, that is completly wrong. Better you do it like I tell you”, you let people discover those things for themselves by doing a simple simulation, from which exactly those conclusions can be drawn. If this makes the conclusion any more valid, I don’t know. I would claim that you could design a game to provoke every kind of learning. Anyway, the value of the game/simulation is not the game itself, but in the debrief afterwards.
Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams, by Darryl Bowler
From this session I had expected a lot more, but it was just a sales presentation for CollabNet TeamForge. The cloud-demo was started at the beginning of the session and was then left running in the background for 20 minutes: it should create some hudson slaves dynamically in the EC2 cloud to build 4 demo projects. When provisioning 4 slaves takes 20 minutes, I can only hope that this is not necessary for each and every build. But I left the session before that question might have been answered.
Let’s stop calling it “agile”, by Bas Vodde And Steven Mak
Instead of the cloud session I walked into a artificially provoked Diskussion, if the word “agile”/”Agile” should be dropped. The arguments were roughly that agility has now reached some market saturation and in order to build a larger community it is not helpful to build artificial walls. The discussion was entertaining, but the result was predictable, of course agile software development stays agile.
Effective Code Reviews in Agile Teams, with Wojciech Seliga and Slawomir Ginter
Code Reviews vs. Pair Programming
I was expecting some concrete recommendations from the last session, how we could enhance the implementation of code reviews. Wojciech and Slawomir both work (directly or indirectly) for Atlassion, the demos and examples were made with Crucible, FishEye and Jira. Since we already have FishEye in daily use, taking Crucible into use should be a no-brainer from a technical point of view, but how to coordinate that? The evenly surprising and simpe answer was: not at all 🙂 You should start with a process as lightweight as possible. Maybe establish a few rules that you should start only one review per day, and don’t comment on code style (my opinion: use Eclipse’s format on save and/or Checkstyle). New team members should start a review for every commit. Pre-commit reviews are only practical when you expect the desaster to happen, thus when a new team member is starting or you are doing changes to a public interface, otherwise post-commit reviews are preferred. The granularity of a review can either be a single commit or all commits related to a Jira issue, you can then start the review from within the Jira issue itself. Depending on the team, some teams have an “under review” state for this in Jira, others leave the issue in “in progress”. It is important to note that code reviews are not a blaming tool, but a learning experience. A mean to pass knowledge and improve quality. The same goals that are achieved with pair programming, so which to use or how to combine? When directly compared, they are different in synchronicity, intensity and permanency (review comments are persistently stored, can even be a knowledge based, while discussions during pair programming are volatile). As IDE they used IDEA, but an Eclipse-Plugin is also existing and currently in focus for development, and most things can also be done with the web UI. Overall I took some ideas and I assume that we will enhance our existing FishEye with a Crucible evaluation license and see where it goes.
Because of the many parallel session, I have missed many. During the discussions in the evening, at the “Ice Breaker”-Dinner, sessions from Robert Martin about Craftsmanship and J. B. Rainsberger about Integration Tests were highly rated, to a great extent because of their very entertaining speakers. Tomorrow both of them have another session … at the same time, so let’s see to which one I will got.
Musik Masti
Before the dinner started there was a “Musik Masti” taking place. I still have absolutely have no clue, what a Masi ist, but there was a stage with acustical instruments, which was open to everybody: thumbs up! Piano, trumpet, guitar … everything was there. Very cool!
I’m looking forward to the second day, full of new discussions and interesting people. Have a good night 🙂
Was this post helpful?
More articles
fromAndreas Ebbert-Karroum
18.11.2020 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Andreas Ebbert-Karroum
Agile Principal Consultant
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.