The book starts off by introducing agile, criticizing waterfall, and going into some more depth on specific named agile approaches. I went through this reasonably quickly as most of it wasn’t new to me. I did not know anything about DSDM though, despite living in Europe for 10 years, so it was nice to read about that.

Things get interesting around chapter 7. The Essence of Agile. I was impressed by the initial table about changing paradigms. It reminds us how fundamentally different the changes that need to be made are, at every level. We clearly see waterfall development on the left, and the idea is to move towards agile development on the right. My attention was immediately drawn to the row headed Management Culture. Under waterfall he writes Command & Control. Under Agile he writes Leadership/Collaborative. I am glad he did. I have been making the connection between waterfall development and command & control management before but wasn’t sure if it was quite right. Despite what many in the Kanban community think, there is a bad old management culture we are trying to move away from, and it is ok to call it command & control, and there is a better alternative that we are moving towards based on leadership and collaboration. And to me that is the fundamental context for any organization adopting agile. Agile might just be about software development, but it belongs to a larger, non-software specific packet that involves a fundamental change to the management culture. If people reject that part of it, or don’t understand it, then success will be prevented. In fact I would have almost done the diagram differently. With column headings “Command & Control” and “Leadership / Collaborative”, and had waterfall and agile as mere cells in the table next to a “software development style” row-heading. To me the management culture just seems bigger and more fundamental than the way software projects are planned and delivered. Particularly in the larger organizations that this book focuses on that probably do a lot more than just develop software.

Another thing I noticed in the table was the idea that in agile, teams bid stories. That is a concept I have not heard of before, or understand, so I intend to look into that further.

One thing he mentioned that I disagreed with was to do with the iron triangle. He wrote that waterfall fixes scope but resources and date are flexible, whereas in agile resources and date are fixed, but scope is flexible. My opinion differs in that waterfall-style (perhaps I don’t mean the theoretical waterfall model, but the approach that command & control organizations use to develop software) projects attempt to fix all three sides, whereas agile insists in at least one side being flexible. I find it perfectly acceptable that a fixed scope project is to be delivered using an agile approach, provided there is some flexibility in the delivery date, and of course costs.

Then he mentions that the heart-beat of agile is the time-boxed iteration. This would have been fine in 2007, but now we have the whole flow based development thing, and especially Kanban showing us that continuous flow can be just as, if not more agile, than iterations. A lot of the rest of the book is based on this assumption that agile implies iterations, which compromises its usefulness these days unfortunately. This is especially apparent in the section on releases. Sure meetings should always be time-boxed, but for me the concepts of cadence and flow have replaced the time-boxed iteration, providing even more flexibility and predictability.

One major premise of the book is that agile is indeed capable of “scaling to the enterprise level”. For me agile, or at least named agile approaches, have always been more appropriate for medium-sized and larger organizations as smaller ones tend not to have the problems that agile methods solve. If you are a small startup, perhaps a group of hackers working on a web based app, communicating very well informally, spending less than 10% of your time in meetings, and delivering value then you really don’t need to go throw Scrum in the mix. You already have what larger companies are looking for when they try agile. Now I wasn’t there in the beginning, but it always seemed to me that agile would be something interesting to try if I were ever in a large enough company to justify it, and from what I read a lot of the proto-agile projects where agile methods were developed were in fact in larger companies. As well as that, whenever I heard the phrase “enterprise agile” I thought of scaling complexity and focus down from the enterprise level and projects down to the story and team level. The idea of “scaling agile up” seemed contrary to the whole point, and almost an oxymoron. The misconception I had when hearing about “scaling agile up” was it is all about compromise. How can organizations get some of the benefits of true agility when they aren’t able to, or prepared to make the necessary changes. This is mostly a philosophical point, but it might be useful to explain how I was thinking as I begun reading the book.

That impression was mostly reinforced by chapter 8, and I started to worry. Not only were we talking about larger organizations (where I assumed at least the teams themselves could be small and autonomous), but teams with several hundred people. To me that is not even a team.

The next section restored my faith with the phrase “Agile is not a trivial fix, or tune-up, for what we have been doing. It is a radical change in practice and culture”. I love that for two reasons. The Kanban community, of which I consider myself a part, likes to downplay how radical it is, claiming it can in fact be done like a series of small tune ups. This might be be true for some organizations that already have a few key cultural aspects in place, but in general it is as radical a change as any other agile method. The second reason is that it is refreshing to see a word like radical in a book aimed at big serious business. I think a lot of coaches etc. try and downplay the radical nature of the changes that are about to take place, and using words like radical and observing the reaction is a good approach for seeing if key stakeholders are even ready for it.

Then he defines the component team. He actually mentions that the name “component” isn’t that important, and the teams could be focused on different things. When I think of a component I think of something that isn’t that huge, and is developed once, and from then on the team is stuck maintaining that component. I much prefer the term “cross-functional team”. And I prefer to see their focus or specialization emerge, as work gets allocated to them (or selected by them) on a variety of criteria, such as capacity, speed, cost, special skills, level of competence required, perhaps a team wants to build up experience in a certain area, or avoid a knowledge silo etc. A good manager will balance the need to expose the team to new stuff that they have to learn, with the need to get things delivered by experienced teams quickly. Over time it may appear as if the team always does work from a certain set of customers, or indeed always on a group of related components, or always does the really urgent stuff, or the critical stuff or whatever. But there are a variety of approaches that could be used. It probably depends on the type of software being developed and where the requirements come from etc.

One issue I have with teams allocated to components is that I could imagine a story, or many stories, requiring changes to several components. This would require too much communication and coordination overhead between teams. Any team should be able to do most of the work itself on any story they might end up with. You don’t want to force a constraint that all stories have to be isolated to a single component, as it requires too much technical knowledge of the architecture during story splitting. In fact during story splitting it might not even be known which components are involved. The story is really just the problem from the users point of view and shouldn’t require any technical knowledge at all to estimate, prioritize, split or write acceptance criteria for.

As far as teams go, they should be cross-functional, and they should be permanent. Projects should be allocated to existing, already gelled teams, rather than forming a team around a project. (This belief was strongly reinforced by reading The Clean Coder, which I intend to review sometime.)

And yes, if such teams don’t exist, perhaps because everyone is in functional teams within functional departments, then these inter-departmental, cross functional teams, or component teams as the book calls them, would have to be created. (The book also uses the term define/build/test team, which is better than component, but kind of over specifies the degree of cross-functionalism required. In my opinion a cross functional team should cover the whole value stream. Whether that is a subset or superset of define/build/test is context dependent).

I like that mentioned that the PO should not just prioritize customer-value-stories, but also refactoring and was it infrastructure or architecture stories. However with 2012 understanding, we would know that refactoring, infrastructure, and architecture happens, and should normally only happen as part of customer value stories. I would reword it to say that the PO should prioritize the payback of technical debt “stories” alongside customer value stories. Which is the same thing basically. A pretty minor point. I almost feel pedantic bringing it up.

I thought maybe the term technical debt was not widely used back in 2007, and that a similar book today should probably have a whole chapter on it. He does actually use the term once, later in the book I believe.

Now we come on to the topic of release planning. I actually found a lot to disagree with here, but later on in the book he actually elaborates and ends up moving closer to how I view the topic of releases etc. I am not sure if teams should be involved in release planning the way it is described in the book. I think as soon as everyone gets together and allocates specific features to specific release dates in the future there is too much pressure to stick with it. Stakeholders with a poorer understanding of agile might interpret as a promise, or might judge the team unfairly every time the plan is updated. Teams may feel under pressure to stick to the release dates no matter what, and get everything in, burning out and compromising on quality etc. I actually go so far as to not specify release dates at all. Just have a product backlog, and teams should be focused on the current iteration, and regular backlog grooming where stories for maybe the next 1 or 2 iterations can be split, estimated, and have acceptance criteria written for them.

Release planning, at least in Scrum, should be something the PO does almost in secret, by looking at the backlog, and the very roughly estimated, and not yet split stories, and combining that with the velocity to get an extremely vague idea about which stories may be finished in which iteration. If this is communicated to stakeholders, that vagueness has to be emphasized! I don’t think this is a weakness of Scrum, but for those looking for more predictability, then I recommend using Kanban, where we can use actual measurements rather than estimates. And no way should the team be expected to delivering certain features by certain dates, especially at the release level. It is hard enough to commit to an iteration, which is why the Scrum Guide has actually removed the concept of commitment and I believe replaced it with the concept of forecast.

I was always the black sheep that refused to commit to delivering the selected stories when we used Scrum at my previous employer. We didn’t use story points or velocity, work was allocated by available man-hours, and we never completed all selected SBIs. In fact “done” required testing by people outside the team, and usually occurred 2 sprints later! I claimed it would have been unprofessional for me to commit to anything given these factors, but everyone else was like “don’t be a dick, commit just means commit to give it a go and do your best, it is not a promise or anything”. I refused to use a word as strong as commitment for something so wishy-washy as “giving it a good go”.

I was very glad when the commitment was removed from the Scrum Guide. Bob Martin actually talks about the difference between an estimate and a commitment, and I agree with it 100%. A commitment is a promise. It is something that will happen. The most I think a professional developer can commit to is beginning, or working on a task. Not completing it, unless it is a small well understood task. Everything else is an estimate or a forecast. Throwing around commitment like a used tissue is just unprofessional, and reduces trust.

Needless to say. I do not support teams “committing” to delivering certain features in certain releases. We shouldn’t forget it is a PO or management responsibility to ensure that the best possible product is delivered by a certain date, and this happens automatically when the backlog is well groomed and prioritized.

I can’t remember who mentioned this, but I heard once that releases are not technical events but marketing ones. The development teams shouldn’t care less when marketing decides to take a snapshot of the currently releasable software and label it a release, perhaps in response to some market event or need. They are too busy focused on the current iteration. But the book comes back to this view later on, which is cool.

Then he started talking about estimating tasks, and assigning them to people, and I realized he was using a fairly old, and inferior, version of Scrum, where things happen in a different order. Some people, like Ron Jeffries don’t even break stories into tasks, in fact, the Scrum Guide has removed the concept of Sprint Backlog Items! It is actually the PBIs that get estimated, during backlog grooming. In the first part of sprint planning the highest priority ones are selected for the sprint according to velocity, and then the team begins to think about the solution in the second part of the planning meeting. Please use the better version of Scrum as defined in the latest Scrum Guide, it is much better than the old version, which has some problems, as described in the book.

The book doesn’t mention backlog grooming, which I consider an omission. In fact backlog grooming should have more time spent on it than any other Scrum meeting. I would say for a larger enterprise, even more time should be spent on backlog grooming, as the initial stories are likely to be larger, and require more splitting etc. The Scrum guide says no more than 10% of a teams time should be spent on backlog grooming. I would use that 10% as a good guideline for an enterprise Scrum team. That is a half-day per week, or a whole day for a 2 week sprint.

One interesting part compared a waterfall scenario with an agile one. In the waterfall scenario everything is planned years in advance, so a salesman is forced to say “no” to an important customer who needed a quick turnaround time. This was contrasted with the agile team who were able to shuffle things around and deliver the important parts on time. What I thought funny was that the salesman was actually professional enough to say “no” to an important customer. In my experience, the salesman always says “yes”, pockets the commission, and uses pressure to force the team to deliver the software in full, on time, without affecting the existing plans.

I would almost be happy to work for a waterfall organization where the salesmen knew enough about the capacity of the team, and were professional enough to say “no”.

We really don’t say “no” often enough in software development.

He mentions that agile requires forced prioritization. Well I think that has changed too. Scrum now only requires ordering, and with Kanban we don’t even order. We simply select the most important thing to do next during queue replenishment.

Another thing I disagreed with was his suggested that for new teams, “individuals work out their expected velocities” and then combine them to get an initial estimated team velocity. That is total nonsense. What is the velocity of a BA? Of a tester? How much working tested software can they deliver as individuals? It is a team measure. It can only be measured, and not estimated. If you want to do some release planning that requires velocity, you have to do one iteration first, measure velocity, then you can do an initial release planning.

A minor quibble I had was his combining Agile/Scrum Master and Team Leader in a single role. I think these are totally different roles. A team leader, assuming you need one, which is a big assumption, might allocate a task to a junior member, a Scrum Master wouldn’t. A team leader might have some authority that the SM doesn’t have. A SM is busy removing impediments to the team, and spreading agility throughout the organization. The team leader is busy developing software.

He has a “requirements pyramid” where he divides the problem domain and solution domain. For him Needs, are in the problem domain, whereas Features and Requirements are in the solution domain. I disagree with this, although it might be a minor philosophical point without consequence. For me all three are in the problem domain. For me we only start to cross into the solution domain when the team begins to discuss the solution in the planning meeting. We are only fully in the solution domain when we have actual written code.

Actually it is more than philosophical. If you think about software development, it is the process of solving problems with software solutions. His pyramid suggests that the problems are actually solved long before they get to the development team. That whoever breaks down a need into a list of features is solving the problem, and that solution is merely being thrown down the chain for the coders to type in. It is a demotivating model. The problem is a problem, right up until the team solves it. They might split the problem into smaller chunks, but they are just smaller problems not solutions.

He also has a solution continuum, where he presents a choice between a minimum solution that “provides minimum benefit but is easiest to implement” and “fully featured solution that delivers additional value”. This doesn’t make sense to me either, and indicates a poorly groomed story. The developer should always implement the simplest possible solution that satisfies the acceptance criteria, and no more. Of course the team may discuss which of a selection of implementation choices is in fact the simplest, but the amount of value that can delivered should be fixed.

There is a great section on decoupling releases from development, which I think could replace the earlier section on releases and release planning.

The “Changing the Organization” section is probably the best and most important. I had not heard of the Zen concept of “Ba” before. I think learning more about it, and discussing it with senior management and observing their reaction is a great idea to predict the level of success with agile to expect. “Creative Chaos” is another such term mentioned in this section. Any manager than smiles and nods at such terms rather than recoiling away has potential to make the most of what agile can provide.

I like the idea of management being organized into teams as well, with their own impediment backlogs. The idea of giving an aptitude test at the beginning to discover if the right attitudes to change are in place also makes sense. The book suggests more training too, in areas like product development and engineering. I would add general modern management training to the list.

Although often hiring or promoting already trained people is a good option. After all one principle I believe in, is you have to trust people to work in the way they see fit. If you hire a traditionalist manager, you have to allow him to work in a traditionalist way. Training him up in agile and expecting him to work in a way he doesn’t believe in is demotivating and disrespectful. It would be as bad as shipping me off to MS-Project training and expecting me to do waterfall planning. Most organizations have people hidden away in teams that already have the right attitude and skills, and are eager to get a chance to put them into practice. Many developers have learned a lot about agile management as a side effect of their interest in agile technical practices. I would rather promote them to a management role than try and train a traditionalist manager to work in a way he finds uncomfortable.

The section on measurement wasn’t as bad as I thought it might be. A lot of useful suggestions, and nothing too harmful.

So to conclude we have a great recipe book. I would hope people don’t apply all the recipes in advance. It is mostly fodder for chefs to consider while developing their own recipes custom made for their organization. I actually think most standard agile approaches like Scrum and Kanban are perfectly fine to start with and allow an organization of any size to discover what particular changes should be made to handles issues of scale. This book, or an updated version of it, could be a useful companion in that process. I certainly wouldn’t go picking and choosing and implementing wholesale the actual methods inside, in advance, because a big enterprise thinks they will need it. The book actually mentions as much towards the end which was good. It could do with an update though, addressing all the points I mentioned above.

It is important to know what he meant by Command & Control, as the term gets thrown around a bit, and there seems to be three main usages of the term.

• The way I have always interpreted it and used it as a negative term for basically traditional management cultures that exhibit the best known aspect of Taylorism: Intelligent managers, remote from the work, do all the thinking, and decide not only what is to be done, but exactly how and dumb, replaceable workers that repeat the physical steps determined by the manager without question. In this case the managers are both issuing commands to the workers, and controlling how they do it. This seems to be how the term is used colloquially by most of the people that I hear use it, as a kind of umbrella term for all the dysfunction-exhibiting types of culture that are at the opposite end of the spectrum from what we are trying to achieve with more modern management ideas.
• If you look the term up in Wikipedia, it refers to the usage of the term in the military. Here command and control are divested in separate roles. Staff of senior rank issue commands in the form of strategic objectives, while those of junior rank exhibit tactical control in order to achieve those objectives. This is more of a neutral usage of the term.
• It is also apparently part of a theoretical model devised by Henri Fayol, which I recently read about on the kanbandev mailing list, but have not yet had a chance to learn much about.

Seddon writes in the prologue a paragraph ending in “these are the principles and practices that constitute command-and-control management”. He specifically mentions the following:

• Top-down hierarchies
• Separation of decision making and work
• Managers making decisions with measures like budgets, standards, and targets.
• Managers learn that their jobs are to manage people and budgets

He also mentions that “our organisational norms are based on command-and-control thinking” and “The separation of decision-making from work, the cornerstone of command-and-control thinking, has its roots in Taylorism…”. So we can assume that Seddon is using the commonly accepted, popular definition of command-and-control.

He compares it directly to systems-thinking, in a table similar to the one on this blog post (where he compares it to “Vanguard’s System Thinking”).

Seddon targets his wisdom mostly towards service organisations, such as local authorities maintaining public flats, that have to react to customer requests in a timely efficient manner. He is inspired by Deming, and the work of Taiichi Ohno who invented the Toyota production system, the root of lean thinking, so I am not surprised to find a close correlation between the ideas in this book and the ideas expressed by the lean software development and Kanban communities. (Although lately it seems many in the Kanban community wish to place it as being a viable option for control cultures, probably for marketing reasons.)

In fact as I was reading the book, I was helping my employer, a typical command and control type company, work with Kanban. As I was reading this book I was thinking, man, if only our managers read this before attempting Kanban, we wouldn’t be struggling so much. As it happens Kanban requires a culture of high collaboration between workers and managers (managers who might not see themselves as part of a software development process but rather a larger business process of which software development is only a small part, so they felt that Kanban was only of limited relevance to them), a sense of ownership of the process amongst workers (completely different to the fear that most non-managers exhibited when Kanban expected them to go idle, or engage in process improvement) and a flow-based rather than batch-based process.

Note I said Kanban requires those things in order to work. Some people believe Kanban can actually cause those things to magically appear, as if a command-and-control manager would suddenly change his mindset after looking at a CFD. It is my experience that a collaborative culture, and a worker owned process is not a result of Kanban, but a prerequisite. But I digress, as usual.

The book provides a gentle introduction to lean and systems thinking in short easy to read chapters full of concrete, real-world examples rather than appeals to academic models and theory. Although many of the examples refer to things like call centers, and plumbing service providers, it is not hard to see how the principles apply to other domains, such as software development. Particularly anyone who has worked with service-orientation or Kanban in the software sector will easily be able to relate to the material. I did notice a lot of overlap with Reinertsen’s Managing the Design Factory, which is not about providing services nor developing and maintaining software, but rather product development, which just goes to show that the basic principles are fairly universal.

I really love the emphasis on learning, learning to think, learning to learn, learning to lead, developing people.

I love that Seddon is not afraid to attack typical sacred cows like targets, certifications and tools. I feel like a lot of people out there involved in process improvement lack some of Seddon’s guts. They fear criticizing obvious dysfunction, claiming it might be disrespecting whoever introduced the dysfunction in the first place, or continues to work in a way that perpetuates the dysfunction. Some people claim that because people gain a sense of self-worth from being really good at working in a dysfunctional way, it is wrong to correct that way because someone loses their self worth. It is a fallacy of course, it assumes the dysfunctions are the “fault” of individuals rather than the system, and also assumes that people would rather not learn new things and perpetuate dysfunction than help improve the system. I can’t imagine Seddon tacitly endorsing dysfunction to spare someone’s ego, and I can’t imagine ever deciding to adopt that approach either.

Heck it seems disrespectful to me to allow someone to keep working in a dysfunctional way rather than help them improve the system.

Anyway it is dinner time so I better wrap this review up.

I loved it, it was one the best books I have ever read, because it felt like it was directly speaking to many of the issues I was facing while reading it, and it helped give me both the courage and practical tips to help fight the causes of the problems we were facing. I consider this book, or perhaps a book similar to it as essential reading for any manager thinking about attempting Kanban. If you aren’t prepared to help fight against command-and-control by following the advice in this book then you will find Kanban rather uncomfortable, and could save yourself and your employees a lot of stress by reconsidering.

I would also recommend it to anyone working outside of software, who hopes to reach the same levels of effectiveness that those in the software development world have been moving towards with the ideas from the lean and agile communities.

There are probably three people that I think need special thanks.

• Corey Haines, as mentioned, for organizing the whole thing.
• Adrian Bolboaca, for giving me the kick start at ALE2011, and conducting an extremely useful Skype session for new facilitators.
• Jim Hurne, just did a whole bunch of work behind the scenes, preparing slides and other graphical materials, I am sure I don’t even know half of what he did, but just from the mailing list activity etc, you can tell he contributed a huge amount.

Some of the themes we tried for activities were:

• Kent Beck’s 4 Rules of Simple Design. Although I think we misinterpreted the last one as “minimizing the size of classes and methods”, surely that leads to a simpler design than minimizing the number of classes and methods.
• TDD as you meant it
• A free choice session where people can choose up to three from No Conditionals, No Iteration, No Data Structures, and All Methods Must be 4 Lines or Less.
• Object Calisthenics
• Silent Pairing

The event could not have taken place without the help of our generous sponsors:

Oh. Any participants that are interested in the offers that global sponsors Codeschool and DNSimple are offering, should contact me to get that hooked up.

There are a couple of other things we didn’t really have time to introduce properly. There is now a Coderetreat Community Contribution Fund (c3f), and a Coderetreat Community Network. If you are interested in attending, hosting or facilitating a coderetreat then check those links out and sign up to stay up to date.

Here are some of the media from the event.

There is a video available here, and a Flickr set here.

Already looking forward to the next one.

The first of the three was SoCraTes 2011 from the 1st to the 3rd of September. The name comes from Software Craftsmanship and Testing, which is an interesting combination. I suspect a few people who would have otherwise been interested in the Software Craftsmanship aspects were turned off by the Testing part. SoCraTes was definitely about the union of those two topics rather than the intersection. It was English speaking too, and great to have some visitors from outside Germany. I even did a lightening talk, where I mentioned that I would be giving all my books away. That’s right, I brought a box full of books and let people help themselves to them.

SoCraTes had an interesting way of scheduling the sessions. Each session was either a big one split into a 30 minute introduction and a hour long in-depth section, while other sessions were just hour long sessions. I tended to move between them a lot. For example on the first day I attended the first 30 minute intro to the Craftsmen Coding Contest, then moved to the in-depth part of the Specification by Example session. Unfortunately I didn’t feel like the second part of specification by example, where they wanted to discuss examples, worked very well without being there for the first 30 minute introduction. I remember going outside to enjoy the great weather and joining another spontaneous, unplanned session happening out there.

After that I saw the first part of Soft Skill Essentials, then went to the Scala Test in-depth session. After lunch I went to the Crafting Object-Oriented Code session. This was one of my favorites. In partners we had to develop a small program according to provided requirements, but we also had to follow a rather extreme set of object oriented, clean code type rules. You might not want to be so strict all the time, but it is a great and fun exercise to help show how these clean code guidelines actually work, by doing them on in an extreme way, on a fairly small simple, easy to understand code base, you can really see what effects these rules lead to.

Later in the afternoon I went to another practical, hands-on session, SOLID for Dynamic and Functional Languages. We split into teams that chose a language associated with a non object-oriented paradigm. I ended up in the Clojure team, and I can’t remember what the other languages were. We were asked to look at code sections that broke a solid principle, and we had to refactor it so it obeyed the solid principle. The main idea was to discuss how aspects of dynamic and functional languages might make the solid principles either unimportant, different, or irrelevant.

The following day was Open Space. I think I attended sessions on “Laws of Software Development”, actually looking at a picture of the board, that is the only one I recognize. I do remember sessions on mentoring, developing SC communities in Germany and the others were mostly just general chats out in the sun.

The discussions on further steps to take regarding software craftsmanship in Germany were interesting. I didn’t think anyone needed to start a SC group up in the Cologne/Bonn area as we already have the Bonn Agile Meetup, and other user groups, that discuss the same topics. I was however inspired to bring the Global Day of Coderetreat to the Cologne/Bonn area though.

The date for the SoCraTes 2012 has already been set and it will take place from August the 2nd to the 4th, with an optional code retreat on the 5th!

ALE2011

The second of the three conferences was the Agile Lean Europe 2011 in Berlin from the 7th to the 9th of September. The whole family came to this one because there was a special spouses and children track with activities and trips organized. Now at this conference all the talks (except keynotes) were 30 minutes long, and they felt for the most part like dragged out lightening talks, or chopped down hour long talks. For me the open spaces were the highlight. I remember some great discussions on things like estimation, and whether we need managers or not. The keynotes were great too. Rachel Davies’ one on the first day was memorable for her comments on enterprise agile, which I seem to agree with. All the keynotes were fantastic. Beyond Budgeting for example is something I am really interested in getting to know more about.

The second day I had to give up a couple of sessions as I was informed I needed to do some last minute improvements to my masters. In the evening a small number of us went on a trip to catch up with the Berlin Lean Startup Group, for one of their meetings and some dinner.

I remember having a lot of thoughts about agile becoming too fluffy, and did a lightening talk about that, and there was some discussion on twitter about my views on coaching that I said I would flesh out in a blog post, but I can’t really remember what it was all about now. The last day was probably the best. I enjoyed all the talks on the Science of Kanban, Relearning Smalltalk, and the Agile Meme. On one of the days we also had a cool open space session “for programmers” with Brian Marick. You could consider it a warning sign if a session at an agile conference was notable for being “for programmers”.

Afterwards my family and I stayed in Berlin for a bit to have a look around.

The next one will be in Barcelona I believe.

Lean & Kanban 2011 Benelux

I enjoyed this one so much in 2010 I decided to go again this year. The whole family came again and we had a look around Antwerp. I won’t go through and comment on every session I attended. The highlights were probably David Anderson’s “When is Kanban not appropriate” talk, Don Reinertsen’s keynote, and the Real Options talk by Chris Matts and Olav Maassen. Would I go again next year? Sure, but there are 3 lean/Kanban conferences all happening around the same time, so maybe next year I could check out the LKCE or the LSSC ones instead.

Not many images on this post, so here is one of my daughter and I in Antwerp.:

It took me a while to read as I had a couple of events come up that I needed to prepare for by putting this book aside and reading some others, so forgive me if the earlier chapters are not as fresh in my mind as they should be. It is a great book and I recommend it. A lot of the ideas currently in the community are based on the fact that product design is different to management and focus on how managers need to think and act in different ways to the manufacturing manager. This book takes a step back and first asks what design managers can learn from manufacturing, and then of course covers what we cannot really apply from manufacturing. This is implied in the metaphor on the title. When I first heard the term "managing the design factory" I thought "no, no, managing design and managing a factory are completely different, this book must be Taylorist or something…". But it isn’t. Everything in it seems to confirm the things we talk about these days regarding the way variability requires a focus on flow and understanding the nature of the work and our capacity rather than simple economies of scale. Once we consider that the book was published in 1997 then we can imagine that the context back then was very different. I wasn’t really involved in the topic back then but I can imagine that the field of design management was probably fairly immature and not yet even tainted by 20th century management thinking optimized for repeatable processes with low variability. I am completely guessing but I imagine the design activities back then were managed in a more ad hoc fashion perhaps by a senior engineer without formal management training. In that context, a book discussing what design managers can learn from the manufacturing world (and what they cannot) makes a lot of sense.

The focus on making decisions based on concrete financial data is one of the important points in this book, as is the idea that design is mostly about the generation of information. Failing tests for example are great because they generate more information than passing ones. It allows us to go back and improve the design. Especially valuable for me as someone involved in software development is the idea that we can modify our decision making process based on whether time to market is more or less important than either total throughput, or reducing costs. With all the hype around Agile and Kanban we sometimes forget that not all software development is a race against competitors, and by realizing that time to market is say less important than other attributes, we can save a lot of money.

There is a good balance between theory and practical tips. Specifically queuing theory, information theory, and systems theory. Everywhere is different after all, and anyone who thinks a simple to-do list of "best practices" is going to optimize product development at their organization is mistaken. You have to understand the theory, and modify the practices to suit your needs. The book doesn’t just pick one situation and describe the practices that suit that situation, rather he covers various topics, and presents various options within each topic that suit different specific needs.

I don’t know if it is a must-read. I certainly got a lot from it, and I expect to really get the most out of it once I have read Flow. I suspect a lot of newer material has already incorporated the real insight of the book. Perhaps if you have some special needs that are not covered by more recent literature on the topic you will find inspiration in this book for maybe diverging from the typical mantras we have all come to accept almost as best practices in say agile or lean software development. I don’t know what things are like in the design and development of non-software e.g. consumer and hardware products for example, but if there isn’t as much new material floating around out there that addresses those needs as their is in the software world, then I could imagine this book is still absolutely current. It is current for software too if I am being honest. Many of the more current books don’t cover everything that this book does.

Anyway, I enjoyed it, and now I am reading "Freedom from Command and Control" by John Seddon. Liking it so far, two chapters in, so stay tuned for a review.

I think it makes sense. There is a degree to which one can claim they are totally different things and should not be compared, but I think they overlap quite a lot, in their goals, the spirit behind them, and they tools they use. You could say for example that Kanban is a change management tool that works by visualizing work and planning according to measured capacity. You could say that Scrum is a planning and scheduling tool with a strong organizational change component. But that leads to a long conversation that you can probably find repeated in many places on the internet.

Kanban however needs some existing process to be applied to. You can’t just start from scratch with a new team, on a new product, and decided to use Kanban without thinking about how the software is to be developed, and how the work will be planned and scheduled. Kanban doesn’t answer those questions, it will just provide some tools for visualizing what is happening, and making small improvements. In this case you could do a lot worse than Scrum. In fact, if you can successfully make a go of Scrum, with a true cross functional team, and deliver small increments of functionality in 30 days or less, you might not even need Kanban. The Scrum already has retrospectives, and the concept of inspect and adapt. Personally I would still make use of the advanced techniques provided by Kanban such as WIP limits, classes of service, explicit policies etc, but as long as the process is still Scrum Guide conform, it is still Scrum. You might call it Scrumban. I once tried to imagine if it would be possible to have a system that is both 100% Kanban and 100% Scrum at the same time, and I think it should be possible but not ideal.

I read Scrumban a while ago, and suspect it is also relevant to this “best of both worlds” discussion, but I would have to reread to be able to say anything interesting about that.

Also let us consider a waterfall organization that has started using Kanban to try and improve the system. After a month or so you are going to have a very flat, stagnant CFD. The cards on the wall will start to yellow with age, negating any use of color to indicate class of service. Anyone using post it notes will start to suffer back trouble after picking them up off the ground all the time. People are going to find answers for this in things like Scrum. Particularly cross functional teams, and well-groomed PBIs that are small enough to be “done” in 30 days or less. Scrum is exactly the medicine a waterfall+Kanban type organization needs.

Not only does combining Kanban and Scrum make sense, they almost seem made for each other in many cases.

Also, Personal Kanban is basically Scrum minus the team considering they both track general “tasks” through the “to-do”, “doing”, “done” sequence rather than tracking customer value through a standardized sequence of steps like normal Kanban. I haven’t read the Personal Kanban book yet, but it would be interesting to know what it borrows from normal Kanban.

So I thought I would help spread the word by posting in my blog about what a great group it is. If you are in the Bonn area, or even Cologne since there doesn’t seem to be an agile meetup there anymore, then check it out.

Here are some relevant links:

• Bonn Agile Meetup Homepage
• Bonn Agile Meetup Blog
• Bonn Agile Meetup on Twitter
• Bonn Agile Meetup Mailing List / Google Group
• The Hashtag is #bonnagile

The theme of the event was "the inner fire". For most people that was the passion they already had for coaching. I definitely had an inner fire too, but it had a different nature. Just as fire keeps us warm and cooks food, it also burns houses and kills people. The inner fire that was driving me to attend something like the coach camp was basically frustration. It also burns but in a different way to passion. I was frustrated at myself for letting my "people skills" slip so much, and also frustrated at the outcome, that my efforts at leading change suffered as a result.

I attended a session on balance, which I hoped would directly address one of the frustrations I had in mind the previous evening. I remain confused on many of the following, I guess knobs that can be tweaked:

• Being a servant leader, getting out of the way and helping others achieve their vision vs asserting my own vision, and placing my own ideas above those of others.
• Serious, professional and boring vs playful, frivolous and abstract.
• How to express passion and excitement without coming across as a fanatic or zealot, or appearing to push an agenda, and thus putting one’s credibility into question.

The session turned out to focus on other topics such as work-life balance and that sort of thing. Still interesting but for me if work-life balance is an issue, you probably have the wrong job. I just don’t really want to separate the two that much. It would be like splitting life into boring and fun bits, why not just arrange things so you can make a living having fun instead? Olaf wrote a follow-up post on the topic here: Spotting the Balance. I may at some point write a post or two on the the particular points I mentioned above.

Then we had an interesting discussion on "The four evil root-causes from hell", which turned out to be more like symptoms than root causes. It was I believe based on the ideas mentioned in How to defend against the 10 things that drive your ScrumMaster crazy.

I then attended a session on "nonviolent communication". The first half was focused on the emotional benefits felt by the session leader. I thought it was a great way to start, once I worked out what sort of information he was trying to deliver and in what form, as I think the point of nonviolent communication seems to lie in the emotional space, rather than the more technical details of what it is, but some of the other participants had difficulty putting it into context without first knowing what non-violent communications was all about. This was however cleared up very well in the second half with practical examples supplied by session participants.

In the afternoon I helped the organizers of the upcoming SoCraTes 2011 conference go through some ideas, and formulate the Call for Contributions. Unfortunately I am far too busy wrapping up my Masters to really take part in the organization or even lead a session, but I am looking forward to attending, and it looks like there are far better sessions being planned than I could come up with anyway.

In the evening we had a few beers and attempted the Kata Potter, not very impressively. On Sunday morning I started off by "exploring my own values and mission", which was pretty introspective, almost naval gazing. It seems I value simplicity. After that I had a go at leading a session called "Leading change without authority or natural talent". I basically just collected a list of tips and ideas from the participants ans wrote them now, someone remarked later on twitter how similar it looked to the list of patterns in the "Fearless Change" book.

The last session I attended was book swashing, where we grabbed some books from the book table, and had five minutes to skim through and pick one thing to write about it, and then pass it on around the circle.

All in all a great event. I did come away with the feeling that I as a developer somehow think wrong, when it comes to dealing with people, and the coaches have a superior mindset in this regards, that we developers have to learn from, which is true to some extent, but I wonder if coaches overstate it because of the lens they are used to looking through. I think to a certain extent the coaches have something to learn from technical people as well, exactly what I am still unsure but it is worth considering.

Some other blog articles on the event are here:

• Agile Coach Camp Germany 2011
• Agile Coach Camp DE 2011

We started off playing Version 3 of the getKanban game which was cool. I had played version 2 before, but did not get totally involved as I was in charge of the graphs, but this time I was fully involved. There was so much content it is hard to decide what to mention. The two biggest things for me were the idea that it doesn’t do any good for the process geek to present the perfect idea and expect everyone to simply accept it and change, as people get emotionally invested in their roles and what they are good at, and don’t want to leave that behind. This is obvious but something I need to be reminded of, as I can get impatient when compromising with what I perceive to be suboptimal ideas. The other main point for me was the discussion about high trust and low trust culture. Kanban is supposed to help a high trust culture emerge, but I think it is more of a symbiotic thing. I think there needs to be some commitment and movement towards a high trust culture before Kanban can be fully utilized. It seems to me like there might be a point where Kanban could be used to reinforce a low-trust culture, if that is the dominant culture present, and those involved perceive a need for e.g. more rules, formality and control.

The discussion on Kaizen vs Kaikaku was enlightening. I did not know about Kaikaku before this workshop, and I had been feeling a need for something like that. The signals that our Kanban system were sending me seemed to be calling out for something stronger than minor kaizen improvements. A lot of Kanban is described as a fairly mechanical process, and the book provides a lot of practical information, backed up with a lot of science from queuing theory and lean manufacturing etc, but I like to think a bit beyond that, and look at it as a system of unpredictable, emotional human beings, so I was delighted to see a lot of focus on the cultural, psychological and sociological elements of Kanban at this workshop. For me that is where the the leadership comes in, realizing that cards on a wall and some pretty graphs are just the easy bits at the beginning. We covered so many anecdotes, other books and I guess concepts, that David finds interesting and relevant for leaders in lean software development. It went way beyond Kanban itself.

There was a lot on where to start, and avoiding calling it a "Kanban Initiative". One extremely important thing that I have to do at work is to change the way we calculate our predictions based on measured data. It turns out cycle times are not normally distributed, so using standard deviations are not appropriate for working out SLAs etc. Instead I intend to look into something called Shewhart’s Method. I have had a bit of a google already, but I think I will need to ask the community for information about it.

There was so much more, I can’t cover it all.

I couldn’t really decide what sessions I wanted to attend so I decided to prepare my Mac laptop for maximum flexibility, and updated MonoDevelop and Eclipse. I had a non-default Ruby installed with RVM and decided to follow the preparation instructions for one of the Ruby sessions just to make sure I had all the gems etc. It didn’t quite work out as nicely as I expected and reminded me of the shambles I experienced last year when Ruby 1.9 and Rails 3 came out, with all the version conflicts caused by the whole gem, rvm, bundler mess. I just put it down to early versions. I still had problems so I deleted my .rvm and started from scratch. I had problems at bundle install, with nokogiri, something to do with the versions of libiconv and/or libxml2 I had installed with brew, which I generally keep up to date. From googling I got the feeling I needed to install a specific version of libxslt from source so I did that, and tried to reinstall nokogiri with gem but still didn’t get anywhere. It felt like using linux in the 90s but a bit worse. At least in linux there were 2 ways to install libraries, from source or as a precompiled package and once it is installed it is available. Here I didn’t really know why some things needed to be installed with brew, some with gem, and some with bundler, and what libraries ended up where. The ruby infrastructure seems to be a lot less elegant than it used to be with all this rvm and bundler nonsense. Strangely I just now tried to do the bundle install again and it got past nokogiri but had problems with mysql2. Probably because I need to install a native mysql library with brew or something.

Anyway, I got there late on the day and my first two choices were full, so I went to the "Space Invaders vs Continuous Testing" one. It was only my third choice because it sounded as if I may really need Visual Studio and Windows to get the most out of it, but I decided it might be fun to try it with MonoDevelop. Technically MonoDevelop worked fine, and did not hold me back at all (the only issue was not being able to install NCrunch, which was not critical to the task). As I missed the explanation at the beginning it took me a while to work out what had to be done, but I was able to make a start, and caught up with most of the others. We really needed more time though. The first 200 points were easy to get, and most of us got that without actually doing any programming, and only one team actually managed to get 400 points. I still feel motivated to work on it, and see if I can solve it at some stage. If I have time I will have to see if it is possible to work on the kata without the server, that tests how well our code actually performs in defending cities against waves of invading aliens.

After the coffee break I attended a session on "Asynchronous Unit Tests in FlexUnit". It was interesting, and gave me a good introduction to not only FlexUnit and asynchronous tests, but to the whole Flex system which is not something I had played with before. We only had 3 participants because Michael Feathers showed up and most people wanted to see what he was doing.

During lunch we had an interesting tour of Bletchley Park, and after that I attended "The Lean Code Challenge" which was a lot of fun. In pairs we were to go through a series of 10 minute iterations building up and modifying a simple console program. We chose to do it in Ruby, because the session provided a minimal Ruby skeleton to work from, and it seemed as good as any other, considering my coding partner didn’t know c# and I didn’t know Flex. So we did ok I think considering we were both basically learning Ruby at the same time. An added bonus for me was improving my Vim skills. I still hadn’t managed to memorize many vim keystrokes, despite doing tutorials every now and then. I tend to forget how to use it effectively and revert to using it in a clumsy way. Pairing with someone who was able to remember a few keystrokes from when he used to use vi a lot really helped me learn some new vim keystrokes too, and it motivated me to improve even further.

One funny observation I made is because of time pressure I probably wrote the worst code at this event than I ever had in the past few years, which seems unfortunate for a software craftsmanship event.

In the evening we had dinner, drinks and an extra session "Personal Codes of Conduct" which was interesting, considering it was not hands on, and nothing to do with code. The discussion afterwards reminded me of some of the very long threads on the software craftsmanship mailing list and made me feel sleepy.

SC2011 did inspire me to think of giving a session at the upcoming SoCraTes 2011 in Germany. I think the best sessions involve:

• Some aspect of a challenge
• Working in pairs or small teams
• Competing against other teams
• Ideally less time pressure so people can come up with good quality code rather than hack something up as time is running out

I am sure I should be able to come up with something.

Here are some other blog posts I found about Software Craftsmanship 2011:

• Take-Away Points From my Software Craftmanship 2011 Session
• Software Craftsmanship 2011 – Thanks & Thoughts
• Software Craftsmanship 2011 – My Takeaways