Shearing Layers in Software Delivery Part 3: Slippage

Part 1: Recognising Rates of Change

Part 2: A Reasonable Model

Much of the value of a Shearing Layers model comes not from deciding what goes on in each layer but rather what goes on between the layers. Brand says:

“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.”

I love this word ‘slippage’; as an engineer it makes intuitive sense to me that two ‘partially-connected’ things with different purposes shouldn’t be meshed together too tightly. Which is perhaps just as well as Brand doesn’t really go into any detail and only gives a very small direct example (although How Buildings Learn is littered with many indirect examples):

“Pouring concrete on the ground for an instant foundation (“slab-on-grade”) is maladaptive – pipes are foolishly buried and there’s no basement space for storage, expansion [or] maintenance and Services access. Timber-framed buildings on the other hand conveniently separate Structure, Skin and Services while balloon-frame (standard stud construction) over-connects them.”

I don’t really appreciate the difference between timber-framed and balloon-frame housing but cars are my thing and I see many points where slippage is good in a car: between the clutch and the drive shaft so that a gear-change can be smooth rather than jarring, in the differential that allows the inner and outer wheels to rotate at different rates to keep traction whilst cornering, and so on.

But enough with the analogies, what does this have to do with software delivery? I’ll start with a couple of examples of slippage and then talk about practices.

On one project we had managed to get everyone involved, at all the four of the Shearing Layers of my reasonable model, comfortable with our XP-based approach. But perhaps we got a little blase about this. One day the project manager got a call from a senior business manager asking “what the hell this ‘load factor‘ of 2″ was all about. “What are the developers doing if they are only spending half their time programming?” they asked. We made a mistake in revealing too much detail about why we wanted to increase the capacity of the project team in order to meet expanded objectives for the project. Up until that point business management had been very happy with the productivity of the team and the progress of the project, and were comfortable with the idea that the team needed to grow a bit to increase capacity, but we managed to shoot ourselves in the foot simply by unwittingly giving the impression that the team was working at half pace. And whilst this may seem like a trivial example it took an awful lot of time and effort to explain ourselves and to win back the trust of this influential and important manager. The lesson: convert the terminology of the delivery team to concepts appreciated and understood by business management when reporting status or plans.

On another project we had the hardest of ‘hard deadlines’ I’ve ever worked to. Philips had decided to become a headline sponsor of the World Cup for 2006 in their biggest ever spend on a single marketing project, with a big ‘brand awareness’ phase (including a global rebranding exercise) starting before the preceding Christmas and lasting from that Christmas right up to the World Cup itself. Across the whole business there were many projects that had to deliver towards the end of 2005 and ours, providing the ‘global internet platform’ which delivered all the online content and services for the biggest business units in every country was one of them (and would deliver all the URLs that would appear in the various magazine, newspaper and TV adverts from November 2005 onwards; $100m’s of advertising and sponsorship directing people to our system). This project was actually a re-engineering of a system we’d developed on a previous project and there was a simple question from business management, asked towards the end of 2004: could all the necessary new features and functions be delivered by October 2005? Although the previous project had been delivered as a series of 10-week long iterations, prioritised by the business, and with the option to halt the project after each release, this approach wasn’t of interest to the business this time around. They wanted to know that we could make the current system do everything they needed by their deadline or else they wanted to build a new system that covered the gaps. We ran a planning workshop with some senior developers and product owners to determine whether we could deliver something against each of the requirements in the nine months we would have for the project and then internally ran the project using the XP process the team was already comfortable with whilst managing requirements and reporting with business management in a much more waterfall like way. We successfully delivered and even managed to accommodate some unexpected (!) late changes in requirements.

I think there are probably many practices that can aid slippage between the different layers. The ones I tend to rely on the most are:

  • Status Reporting . I’ve not worked on a single project for a large(ish) organisation where there hasn’t been some form of project board to report to, and sometimes more than one. The more expensive or more important the project, the more senior the managers that attend and the more senior the manager, the less well equipped they are to deal with the day-to-day detail of software delivery. This isn’t an issue of ability or capacity, simply one of focus and theirs should lie elsewhere or the business is going to be in trouble. Status reporting introduces slippage between Project Management and Business Management. It should happen at the highest frequency of business management: probably monthly, at least quarterly. Status reports should distill the detail of the project progress, risks and issues, team capacity, etc. into terms and metrics easily understood and actionable by the business. This isn’t about trying to hide things from ‘the business’, simply about ensuring they have the information they need in a form they can use.
  • Release Planning. Release planning adds slippage between both Project and Product Management layers and the Business and Project Management layers. A Sprint Plan covers in detail what is to be built in the next sprint and, in my experience, the Product Backlog has a mixture of fairly detailed requirements that are just not high enough priority to be done yet, plus a bunch of vague statements about features. Release planning takes the higher-level vague requirements and chunks them up into a few sprints’ worth of releases. Planning of releases is done in much the same was as a sprint plan but the later the release, the less detail is used either for describing the requirement or estimating the effort. So the one or two sprints after the one just about to run may have a few high-level requirements with a simple Small, Medium or Large estimation of effort, ones further down the line might contain only one or two very high-level statements. These future plans are not committed to in the same way as the current sprint but represent a reasonable idea of what will be delivered if things don’t change, with the full understanding that, if they do, the release plan might change. Release plans are useful for Project Management to think about future requirements in terms of hiring or infrastructure purchase and also to communicate with Business Management and customers or users about what’s coming ‘down the line’. A a rule of thumb, I find release planning takes about a third of the time as planning a sprint so its a fairly lightweight activity.
  • Internal and Production Releases. Many people are talking about continuous release of software being the ultimate evolution of XP; Bjarte Djuvik Næss has a good summary of a Kent Beck talk on the subject. I’m a fan of the concept, but recognise that it just doesn’t work for some businesses. In the case of the Philips project described above, there was a planned ‘go live’ event for the re-launched websites built on the new global internet platform that was part of the marketing programme. On another project there were a large number of users for the system and a number of support processes around training and content production which could not be delivered at the same rate as the software so quarterly releases were preferred. In any project where the production releases are required at intervals greater than the sprint length I have ‘internal releases’ which are of the quality and completeness of a production release. If ever ‘the business’ wants or needs to take these internal releases into production they can but, under normal conditions, one in every three, five, ten or whatever of these releases is destined to become the ‘production release’: no different to its siblings other than that it happens to be the one delivered at the end of the production release interval. Like Release Planning this introduces slippage between the Project and Product Management layers and the Business and Project Management layers; slower rate-of-change processes consider the new software to come once every 10 weeks, say, whilst the product managers and delivery team continue to plan, build, test and deploy (to a non user-visible environment) continuously, or every week, or whatever sprint length works for you.
  • Project Definition. Prince II has a Project Initiation Document or PID that is used to capture all the project management information necessary to kick the project off; things like key objectives and constraints, roles and responsibilities, exception processes, etc. In an agile project, where each sprint can be thought of as a small project, having a continuously updated PID can introduce slippage between Project Management and Product Manage by ensuring business objectives and constraints are re-validated and re-stated, helping to guide Product Management without Project Management feeling they have to review all the detail of each Sprint Plan. Because its done frequently the Project Definition (the recurring PID if you like) needs to be very lightweight; a two-page or three-page set of bullet points for example. It doesn’t even have to be a document: on the original Philips project we had the customer representative from Philips give a 1-hour presentation on the business objectives for the project at the start of each 10-week iteration. This helped the delivery team understand the context of what they were doing and Product Managers understand the high-level priorities for their Sprint and Release Planning. This is also a good example of how communication that respects shearing layers (the business objectives had to be described in a way that makes sense to the delivery team rather than using a load of business management speak) doesn’t have to be passed from one layer to the next; direct communication is preferable as long as it is appropriate and the purpose understood by all.

There are many more practices for introducing slippage and I may return to the subject later. I’ve concentrated here on introducing slippage between the outer Shearing Layers mostly because that’s where the greatest need for slippage occurs and also because there’s little written about the roles and influence of business management and project management on agile projects (definitely a topic I’ll be returning to). Slippage between Product Management and Software Delivery is also important and I think neither XP nor Scrum do a particularly good job of dealing with it, either assuming it will just be handled by skilful Scrum Masters and Product Owners, or by simply putting the whole team together whenever decisions or plans need to be made.

Advertisements

One thought on “Shearing Layers in Software Delivery Part 3: Slippage

  1. Pingback: On Estimation « Paul Dyson’s Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s