Liveblog of Michael Feathers' keynote at Agile Cambridge 2013

Posted on September 25, 2013


off the cuff, roughly quoted. Symbiotic Development. Things that have been designed to fit well together.

After the fact summary

Educate people at various levels of the organisation, so they all see that organisation, team and code are all intermixed.

Systems thinking

Michael starts of with a picture of Gerald Weinberg, discussing looking at a development organisation from a systems perspective. Suggesting that this perspective may have been more common in the early days of software development, and it is something that might be valuable to do more of now.

Component teams or feature teams

You need an organisation that is aware enough that these are two ways of organizing software development.

The code matters. We want to make intelligent decisions around teams so we can deal with the longevity of the code.

Teams with permeable membranes

Team members going from one team to the others, teams disbanding and reorganizing.


This was going to save the industry. Does anybody feel saved?

Continuous delivery

This is probably going to have us favour small changes as opposed to big changes. This is going to affect code in ways that we have not had in the past.


One thing that is kind of weird for us, is that code is not as important for us as other primary things. The creation myths of scrum and xp are good for us. Both the first scrum and xp projects were cases where you had developers and business people in an organisation not being able to communicate really well […] you had developers saying “they keep changing their mind all the time” and business saying “the developers don’t know what they are doing”. Both processes define an interface, the sprint in scrum. same in xp. regularization of roles, business determine features, developers give off estimates.

We are seeing a lot more cooperative development where business and development cooperate on a day to day basis, but we are still carrying the effects of these early projects, where there is a chasm between business and development.

Spolsky the law of leaky abstractions. All non trivial abstractions are leaky (Spolsky).

We kind of present the notion in Agile that it is all about features, and later we discover that we were lying. We talk about a feature and then we say “it is going to be three sprints”. “Why?” “Just as a side effect of the way we have done things it is now difficult to do”. “They have not seen the effect on the code of their feature choices, and which are the abstractions that leak”.

Effects on the code

“This change is going to have this effect on the code” the developers say, and then the business go “oh, is it going to have that effect on what we can develop in the future?”.

So much what we do is about Piecemeal Growth.


Educate people at various levels of the organisation, so they all see that organisation, team and code are all intermixed.


Google is one of those organisations that is developed by software developers. Other organisations may not see themselves as such, e.g. accounting firms. They may not see software as an essential part of their business, and are likely to contract that out. There are opportunities to do more with software within many organisations.

It feels like there are lifecycles to organisations. Some last 50, some 500 years. There is a generational effect. There are founders, the next generation, aqcuisitions, reengineering, so an organisation can enter middle age at some point. Organisations that have been around for a while might become conservative when they once were innovative (both in products and how they are organised, see Conway’s Law).

Sometimes you get these really cool effects. In this organisation we were using Fitnesse and it worked perfectly. The ui designer was in another room than the developers, so the developers made an API for the UI, so that also gave them a seam to write the Fitnesse tests against.

You can show visualizations of legacy code to business people, so you can have a conversation, and show “well, this feature you want is affected by the code here, and as you can see that will take a bit more than if you added a feature that added the code over there”. Being able to move in that direction will be really, really healthy for organisations.

comments powered by Disqus
More posts by Willem van den Ende RSS feed Atom feed