[This is something I started to write about five years ago. It began life as a paper, then developed to a series of papers, then an outline for a book. At that point, thoroughly discouraged, I gave up with it. But I keep coming back to it as a useful concept for understanding how agile software development fits in with a not-so-agile business. So now I’m going to try and deliver it as a series of X blog posts, written over Y days/weeks/years until I think I’m done.]
Being interested in building architecture I ran off to the bookshop to get myself a copy. It’s a fantastic book, thought-provoking and full of insight, but it was chapter 2 – Shearing Layers – that really made me pause for thought. Shearing Layers, originally proposed by architect Frank Duffy, is a conceptual model of buildings where one thinks of a building as “several layers of longevity of built components”. Brand expands on Duffy’s original four-layer model and proposes a model of “six S’s” [quoted from “How Buildings Learn”, Stuart Brand, Viking, 1994]:
- Site – This is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context outlast generations of ephemeral buildings. “Site is eternal.” Duffy agrees.
- Structure – The foundation and load-bearing elements are perilous and expensive to change, so people don’t. These are the building. Structural life ranges from 30 to 300 years (but few buildings make it past 60, for other reasons).
- Skin – Exterior surfaces now change every 20 years or so, to keep up with fashion or technology, or for wholesale repair. Recent focus on energy costs has led to re-engineered Skins that are air-tight and better-insulated.
- Services – These are the working guts of a building: communications wiring, electrical wiring, plumbing, sprinkler system, HVAC (heating, ventilating, and air conditioning), and moving parts like elevators and escalators. They wear out or obsolesce every 7 to 15 years. Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily.
- Space Plan – The Interior layout–where walls, ceilings, floors, and doors go. Turbulent commercial space can change every 3 years or. so; exceptionally quiet homes might wait 30 years.
- Stuff – Chairs, desks, phones, pictures; kitchen appliances, lamps, hairbrushes; all the things that twitch around daily to monthly. Furniture is called mobilia in Italian for good reason.
I liked the model but it was commentary around it that really grabbed my attention (quotes elided to remove the building-specific references):
“Thinking in this time-laden way is very practical … it legitimises the existence of different [roles] … all with their different agendas defined by this time scale”
“Most interaction is within the same pace level”
“The dynamics of the system will be dominated by the slow components with the rapid components simply following along … still, influence does percolate the other direction. The slower processes … gradually integrate trends of rapid change within them.”
“The quick processes provide originality and challenge, the slow provide continuity and constraint.”
“An imperative emerges: an adaptive [system] has to allow slippage between the differently-paced systems … otherwise the slow systems block the flow of the quick ones and the quick ones tear up the slow ones with their constant change. Embedding the systems together may look efficient at first but over time it is the opposite, and destructive as well.”
At the time I was wrestling with some of the challenges of running an XP project in a small but rather conservative organisation. Just getting the managers to agree to using what was then a brand-new (in 1997) and little-known approach to software development had required them to take a not-insignificant leap of faith and not all of what they saw was to their liking although, to their immense credit, they continued to support us as a team. The managers disliked joining the daily standup as they felt the detail of what was ‘reported’ left them unable to see the wood for the trees and we, the development team, found it difficult to get what we needed from the standup if we tried to meet the needs of the managers. Similarly, the managers liked the fact that we were able to tell them what the system would do differently in the next two weeks but struggled with the idea that we couldn’t tell them anything further than that; they had customers they needed to deal with who frankly didn’t care about the development process and just wanted some software to help solve some business problems.
What Brand’s chapter on Shearing Layers helped me to see is that there were two different ‘levels of pace’ in our project. Our XP development process was very quick by our organisation’s standards: we planned by the week, delivered a new software build daily, reorganised the pairs twice daily, refactored and integrated hourly, and coded discrete changes by the minute. The managers struggled with this rate of change simply because their processes and agendas were oriented around timescales of months, quarters and years for planning features (rather than stories and tasks), releases to customers (rather than builds) and budgets.
Our solution was simply to introduce some “slippage” between the development ‘layer’ and the management ‘layer’. The managers stopped coming to the daily stand-up and instead got a simple status report before the weekly planning game (they also had visibility of the task board but stopped worrying about exactly what was written on each card and instead just looked for a steady progression of green ticks appearing on cards throughout the week). We introduced a practice of ‘release planning’ where we would take very high level statements about required features, have a quick discussion with the managers (we had no concept of a product owner back then) and then give a very high-level estimate of time and complexity to implement. This allowed us to agree a very rough plan for what each customer release would contain, sufficient to communicate with customers what was coming down the line whilst preserving the fast pace and agility of development the XP process had helped us to achieve.
The key lesson on this project (aside from all the great stuff we learned about XP from actually doing it) was simply to recognise and respect the different rates of change in the organisation. Originally, the slow management processes had dominated the development process, leading to a fairly traditional waterfall approach that was suffering all the usual issues. The introduction of XP was a reaction to the limitations of this development process but it was a mistake for us, the development team, to think that we just had to be eXtreme and the whole business would fall in line with this magical new way of working. Instead we built a two-layer approach that initially allowed the XP team to deliver within the constraints of the slower business processes and, over time, allowed some of the advantages of having an XP development process to percolate up into those business processes.