QCon Day 2: Persons, Groups and Teams

Although I did get the feeling that QCon isn't at the same quality level as the last time I was here, I did manage to pick up a considerable amount of new ideas and insights on the first day. Not anything mind blowing, but still worth the trip. So let's see what the 2nd day did bring us.

The day started with a keynote by Keith Adams, a Facebook founding member. He claimed that only 25% of the success of software can be accounted to brilliant teams, tools, frameworks, disciplines and programming languages. The other 75% is added by tuning the system. I'm not sure I fully agree, but I do see that you don't really have a clear understanding of your system's performance until you put it in production. And that's something we do agree on, because he said that if you don't have users, you're not tuning yet (and you shouldn't). I've noticed myself that benchmarks and heuristics don't really give you enough real data to really make your system shine. On the other hand, I think you're already lucky if you managed to pull of a performance or load test in your project. He also started talking on machine learning, but that's a topic that doesn't work for me (yet).

For the second slot, I decided to attend a talk on mobile platforms that should enable you to create mobile apps that can run on iOS, Android and Windows Phone. Since that's a topic that is becoming quite relevant within my current project, I was really looking forward to it. The speaker, Alex Gaber, gave us a short overview of the many tools, platforms and products, but forgot to actually give some decent advice. Worse, he finished within the first 30 minutes of the slot. I couldn't resist the feeling that he didn't really prepare his talk. Nevertheless, I used the remaining time to do some research myself and look at PhoneGap, Appcelerate and Xamarin. It seems that moving towards a native experience is still the prefered approach to get all the functionality of the platform and still a smooth experience. For your reference, I ran into this nice little article that compares Appcelerator to the other platforms. And now that Microsoft has announced a closer cooperation with Xamarin, that platform promised to become even more interesting.

During the break I learned that I missed a great talk on happiness in virtual teams with a lot of valuable tips for ordinary agile team and I liked to learn a bit more about UX design. Consequently, attending the UX virtual team talk sounded like a good idea. I learned about the Design Studio process, an agile approach for UX design tasks and how they use it with virtual teams. Not my cup of tea, but at least I got to bring home another book title I need to read at some point in time: The Lean Startup. I was surprised though that they actually used a group chat to a distributed daily Scrum meeting. I would reckon not being able to see each other as well as read each other's body language is a big impediment.

After lunch I moved to another virtual team related session hosted by Ashley Johnson, a very experienced agile coach which proved to be capable of involving the audience in a unique fashion. He basically give the audience short assignments that you were supposed to complete with your neighbor. Even better, at some point he even managed to get an entire row of seats to work together to complete little task. And that's also the most important message of this track. The only way to turn a group of people in a team is to give them a task to complete. That may sound like an open door, but it's quite a fundamental notion that really helped me understand why our teams are still not real teams.

We practice Kanban and use a feature-driven approach. We have been doing Scrum for 45 3-week sprints and decided to move to Kanban to better support the continuous nature of our work. However, now teams are missing some of the pressure they were used to in Scrum and a clear goal/purpose. With the insights from this session it is clear we really need to look at finding a way to reintroduce an explicit task or assignment.

Another great analogy that made me rethink some of our teams issues is to consider what happens if the wheels of a car are not aligned properly. You don't need a engineering degree in the automotive industry to understand that a slight misalignment is enough to really spoil the driving experience. In our project we've introduced a lot of principles, rules and guidelines, but I think we've failed to really help the teams understand why we are doing this. E.g. what's the architectural vision? Why did we need to introduce so much complexity? What kind of challenges are ahead of us that might affect our technical design? I'm definitely going to give some attention to that once I'm back at the office. Oh, Ashley also recommended another book titled Agile Adoption Patterns.

For the record, the audience agreed that these were important characteristics of the best teams: humility, helping each other, autonomy, tasks, and clear success criteria. Similarly, they also identified some of the worst things a team can suffer from such as: nano management, fear of failure, personal agendas, tasks per person, competition for leadership or an uneven workload.

Part of the same track was a talk by Dana Caulder on how they managed to overcome some of the cultural and time zone differences when working with teams in the US and Poland. Dana was unlucky to have followed Ashley's track, and she mostly confirmed some of the stuff Ashley has been showing us, but I did learn something from her. In her experience a successful team knows each other well. So a great tip is to always use the time that you have to wait for each other during meetings to small talk on weekend plans, someone's family, their pets or traditions, or to make jokes. It can really increase the cohesion of the teams. Hopefully my colleagues will not look funny at me the next time I'm asking those kinds of questions…

Since the last slot of the day didn't include a single decent topic, my last session of the day involved another Open Space discussion. I proposed a topic on how to promote the pride of ownership within the teams, as well as encourage developers to feel more responsible of the code base as well as the product. I was lucky to have both Dana and Ashley in our little group. Ashley provided some background on the psychology behind the responsibility of people and basically told us that it is very hard to make people feel responsible for their choices from the outside. It should come from the person him/herself as part of moving through the stages of a responsibility process. However, generally people feel responsible for the choices that they made themselves or things they've opted in. Obviously that resonates well with Ashley's earlier observation that tasks help transforming groups of people into a team.

All in all a very interesting second day. Now it's time for a drink…