Last week, I visited this years Goto Zürich 2013, which is a two-day conference with tutorials wrapped around it. 
Topic areas range from lean start-up over technology to a leaders track. I spent most of my first day on the so-called leaders track as here most talks revolved around adopting agile and lean methods, but also went to some more technical talks in other tracks, too. I’ll summarize most of the talks and my impression below. Btw., the slides to most of the talks can be found on the conference website, more precisely on the schedule overview for the two days.
The conference started out with a keynote by Scott Ambler on his work on Disciplined agile delivery which provides a framework on where decisions are needed when implementing agile methods in a larger setup, drawing from many different methods like Scrum, XP, Kanban, the Scaled Agile Framework and many others. The first part of his talk was mainly concerned with the question if agile holds up to its promise of delivering ‘better’, which he tries to answer with regular surveys. These seem to confirm that team size, location, complexity and methods used do have an impact. Not surprisingly, small team size are more successful than larger, co-located teams better than distributed ones and simple projects are much more likely to succeed than complex ones. And of course, there are still projects using waterfall-like approaches that succeed, while the difference between an iterative and an agile approach are rather minimal. Still, however, the number of project failures are always high, even for simple projects there are more failures than one might expect.
The first talk here was about Spinning by Ralph Westphal, which is well-known e.g. for his association with the Clean Code Developer initiative. His premise was that today’s business reality is a constant change of priority which is at conflict with assuming bigger time boxes during which developers can focus on some goal. His answer is that we should ‘seize the day’ (as Dan North might have put it) and deliver ‘value’ daily. It’s important that this value should be something worthwhile to the customer and the customer should be able to give feedback daily as well. I’m wondering whether it is really always possible to accomplish this, e.g. fixing a bug might require analysis well beyond a day. But even if you might not always hold up to the idea, it might still be a worthwhile guideline for organizing work. Another question which I don’t have an obvious answer for is the question who should be in charge to decide what should be worked on on any given day? Ralph required a thorough triage to be carried out to avoid wasting time, but it’s unclear whether this job belongs e.g. in the hands of the product owner.
Dominik Maximi spoke next about ‘Hostile waters’, e.g. how company culture might influence your chances and approaches to introducing agile in an organization. He made the important point that every company culture exists because it is (or was in the past) successful to work like that. This needs to be respected when you want to change something fundamentally. He then gave a nice overview of the Schneider model on how to classify company culture. Non-representative survey results indicate that ‘agile’ has a similar characteristics to ‘collaborative’ or ‘cultivation culture’, but doesn’t fit in so nicely with a ‘competence’ culture or ‘control’ (no surprises here). Changing the mindset of a company might take up to 7-10 years. Dominik finally discussed John P. Kotter’s work on change steps to implement agile.
I then heard a much more technical talk about ‘performance myths’ by Martin Thompson, who tried debunking ten such myths with hard data, dissecting for instance why functional programming is no silver bullet either. Take away for me was that clean code typically also has good performance characteristics and that good performance is actually not easy to achieve. A last important point was the reminder to actually use available tools, e.g. profilers.
Back in the leaders track, Mischa Ramseyer talked about how to avoid ‘5 deadly management sins’ which he showed were actually nicely summarized in a video interview with W. Edwards Deming in 1984: Lack of purpose, short-term thinking, annual performance review, mobility of management and management by numbers (compare the seven deadly diseases in his Wikipedia article). Ramseyer tries to break the vicious circle, by raising awareness and of course starting with the first disease by defining purpose. He went on to show how personal and business purpose can be related, also showing off some business mission statements from successful companies. To overcome the annual performance review, he proposed to have review by peers. Other important points included craftsmanship and the idea to optimize the whole, e.g. by using the net promoter score as a performance indicator for the whole. The talk was a little bit crammed with too many important aspects which would require much more elaboration, but gave a nice overview of many ideas also from the Management 3.0 movement.
The last regular talk on the first day that I attended was about ‘Scaling Soundcloud’ by Alex Gross which I personally found to be rather disappointing. They seem to use quite a lot of en vogue technology, when it comes to technical scaling aspects. On the organizational part it remained even more unclear what was actually just working by chance and what was done on purpose with a clear vision, the main point here was that with very good people you don’t need much processes. I’m not sure whether my disappointment was due to the content or due to the very sloppy presentation style, I’m sure they’re doing interesting things.
The final keynote of the day was by Dean Leffingwell on his Scaled Agile Framework. I know most of the theoretical framework from Dean’s book on Agile requirements, but had never heard him speak about it before, so I was interested to see where he would lay the main focus on. He outlined where he personally came from, recognizing that many people, Dean included, were not dumb when they went with heavy methodologies like RUP, but that things have moved on. He also pointed out that many aspects of SAFe are just proven methods written down, that people actually live in big enterprises. An interesting number for me was that his smallest client using SAFe has around 450 developers, which to me sounds like a pretty big company. Dean proposed to actually use a bottom-up approach to implement SAFe: start with the lowest (team) level, move on to the next level if you got the lower level sorted out and have a need to align at the program level and if that works, you might consider to go even higher up. The keynote had some interesting points and anecdotes but overall was a little too vague to be really convincing.
And then in the after-conference get-together, two guys were doing improvised electro music with Emacs and Clojure with very nice visualization and Emacs / code being modified all the time projected above them. Great fun!
The next day started with another keynote on ‘Accelerating agile’ by Dan North which was mainly a tell tale on how Dan changed jobs from external consultant (with ThoughtWorks) to developer at some financial trading company and discovered that most processes he recommended in his old job were of no importance and often of no use in his new job. Instead he discovered that it boiled down to very obvious things to make development successful and developers happy: e.g. train thoroughly to ensure the developers understand the domain and get feedback from the real users as fast as possible (daily). Some of these recommendations also seem to be easier in the kind of setup Dan described: it’s not always easy to get this sort of feedback if you’re a contractor building software for some client, for instance. Dan also recommended to prioritize risky stuff over value, at least until you’ve built something that is minimal valuable. He also argued that failing fast actually is succeeding and that doing experiments is not only gratifying but also essential to figure out the right approach. He also mentioned that much of this is easier if you’re budgeting is not built on a silo approach with subsequent begging but if you can get internal venture funding for your efforts.
Then I heard Scott Ambler again, with an Introduction to how lean would provide principles and practices to scaling agile. While he made the valid point that Agile need to be able to prove its bold assertions, I don’t think this particular talk helped. Scott mainly referred to elements from lean and in particular from ‘Lean software development’ as understood by the Poppendiecks. However, their work is already highly influenced by agile processes, XP, Scrum and Kanban. I had a strong feeling that the argument was very self-referential and hence not really useful. I also don’t think Scott presented at least one argument why Lean would help with /scaling/ agile, so overall I was quite disappointed by this talk.
Next was Dan North again on ‘Patterns for effective teams’. I had the impression that he mainly relied on experiences he made since he quit his consultant job, so I wondered how many instances he had seen to be able to conclude he had discovered or named a well-known pattern. Unfortunately he lost sight of time very early on as he got into a very detailed discussion of the Dreyfus model of skill acquisition. But it helped with making his point that failing is a necessary part of learning, so imposing rules for protection against failure is prohibiting learning. Due to lack of time Dan had to rush through some of the other patterns on his slides, but as you can see from the slides, there are some nice ideas, although some pattern names are not directly telling.
I went to a more technical talk afterwards to hear David Nolen talk about ‘Post-functional programming’ which turned out to be about declarative programming with Clojure’s core.logic module. He first showed off the influences, especially Prolog, of course, recommending to get The Art of Prolog at a used bookstore for a dime, as nobody would know about that stuff anymore, which made me feel very old, having worked quite a bit with Prolog during my studies in the 90s. David demoed a lot of code, showing the original Prolog code for comparison where appropriate, but also showing the interaction of the power of combining the declarative approach of core.logic with Clojures fundamental functional programming style. Very nice was his demo (with Sudoko, of course) of the newer constraint logic programming capabilities which seem to be a recent addition to core.logic. This talk was one of my personal highlights of the conference, very down to earth and a good glance over the daily end of the plate.
After some short lightning talks on modern databases that I won’t go into, Alexander Grêt gave an interesting talk about ‘Culture clash’ from a CIO perspective. He was responsible for changing to Scrum in his company with the clear intention of a disruptive change to enable success. He gave the impression that while he had a clear vision and understanding what agile is about, that at the same time he had no knowledge of the details of Scrum and that this actually was exactly the way it should be. This is part of the clash of cultures, especially if teams get all excited about agile but fail to align with the needs of upper management. One interesting observation he talked about was that larger projects fail larger, which he attributes to asymmetry and to the bigger complexities (organizational) that add up. A setup in which you have small projects which might fail is preferred, for which he used a nice metaphor: you can bump with your car into the wall with 1 km/h a hundred times without fatal effect, quite to the contrary when you bump one time with 100 km/h into the wall. Alexander also drew a quite negative picture of many senior management people, pointing out that many prefer more false security over less true security. There is a difference between the meaning of ‘control’ in the sense of measurement and ‘control’ in the sense of taking command, which some seem to keep confusing. Alexander recommended to take (personal) risk to step up and move in an agile direction, to understand leadership as being in control (for your team, e.g.). Showing success will get you the attention that is needed to kick of a transition. Overall a very interesting talk that, given the talk by Dominik I heard the previous day, left me wondering how persistent this change of culture can be and how hard the old habits will fight back.
The closing session of exiting two days was Jurgen Appelo on ‘Helping Melly’ which was mainly about relating many of the management 3.0 points help making people actually like their jobs. The most important part was when he showed the main roadblocks to adopting agile approaches: ability to change organizational culture, availability of people with the right skills, general resistance to change and management support are the top five. Which of course says that management as is is the top roadblock to adopting agile. Jurgen then went on to propose his ‘management workout practices’, e.g. practices to energize people with kudo boxes for instance or to have exploration days to have people develop competence. Most practices were collected from various companies Jurgen visited. This collection seems like a nice anti-dote to the deadly management diseases that Mischa Ramseyer discussed and their recommendations were quite similar, up to using the same example companies and methods.
Overall, this were two really great days I spend in Zurich. I also met with some folks I only knew from the interwebs and that is also very nice, of course. As always after such a conference, you rush home to your day job with your head buzzing, only to discover shortly that you keep treading down the same old beaten paths, but this post will serve as a reminder to me to pick up one or two tricks I’ve learned about.
Holger Schauer
I just found out that the music in Clojure live on stage was performed by Meta-Ex.