Walking The Spine

In my previous post I introduced the Spine Model – a philosophy of thought for Agile companies. Let’s Walk the Spine to show how philosophy can be applied to the real world.

Walking The Spine

In my previous post I introduced the Spine Model – a philosophy of thought for Agile companies. Let’s Walk the Spine to show how this philosophy can be applied to the real world.


Start with the Need


Over the years I have been all over the world and have observed many teams and their ways of work. An organizational pattern that always seems to surface is what I call “Cargo Culting” – see https://en.wikipedia.org/wiki/Cargo_cult_programming. Simply put the pattern is where people conduct rituals e.g. follow processes without any understanding of what the purpose of this work is. Typically, how this comes about is that a person establishes the work needed to solve a problem at a point in time. This work process is then adopted by the team. At some point the person who established the process moves on yet there may no longer be a need for the work.

I’ve seen accountants doing arduous reconciliations that were replaced by a new system yet they continued with these process regardless. Similar things happen in software development teams where the team follows a ritual but has no idea why. When questioned the people usually say “Because we’ve always done this/followed this process”. The wisdom here is that it’s often very hard for people to see clearly when they are in a system, an external view sometimes provided by a coach can provide insight for change that may have dramatic impact. Be clear on the need that is being solved for.

What is valued in the context of this need?

I believe that all of us behave according to our value drivers. Being conscious of one’s own value drivers as well as the value drivers of others, the team and the organization is possibly one of the most useful insights a person can have. Also having the insight around whether people associate value to themselves by what they do versus who they are (human doing versus human being) is critical. In our competitive workplace I frequently observe an imbalance wherein people associate all of their value to what they do, then in the absence of the work they find themselves lost. Values are also not binary, for example a team may favour flow over simplicity – it’s an “and” discussion.

Making “Principle” decisions

blog-post-visuals-05-oct-princaplesPrinciples are a great tool to guide decision making. I recently was involved in organizing a large industry event with a number of peer organizations. Half way through the exercise we came to the realization that we disagreed on a number of principle issues. It’s harder to address these issues when you are half pregnant, my takeout is that one should always do an Agile Bootstrap when forming a new team. Agile Bootstraps typically allow for a safe space where team members can share their backgrounds and where the team can walk the spine together – through this process it raises where there is disagreement.

Practical steps

blog-post-visuals-05-oct-practicesIn the world of knowledge workers that we find ourselves in, it is imperative that the team is allowed to align their chosen practices to satisfy the ultimate need or outcome. If you have hired smart people who can solve problems with creative thought, then why on earth would you dictate a solution? The first caveat is that in large enterprises there are some metrics that need to be provided by the team that are common across each team so that management can obtain a holistic view of the system. The second caveat is that some practices are just inappropriate for some problems – see Cynefin framework: https://en.wikipedia.org/wiki/Cynefin_Framework. The summary of this is that it really isn’t wise to use Waterfall for work that is not highly repeatable.

A man with a Tool

blog-post-visuals-05-oct-toolsInterestingly this is where many people start. They think that choosing a technology or tool will solve all of their problems. Unfortunately, this is a cognitive distortion. Tools don’t solve problems; humans do so don’t expect tooling to have any effect on the behaviour of the people in the system. Having said this if one adopts best practice then common sense must apply. We are in the world of DevOps and there are best of breed tools in each part of the pipeline. Do some research, your time will be well spent.

The last point to make is that when you have conversations be clear where you are having the conversation – the Spine again is useful for this.

by Jason Suttie


Introducing the Spine Model

EMBARKING ON THE AGILE JOURNEY I’ve seen many organisations who have embarked on Agile journeys. The large enterprises are harder to shift than smaller companies and start-ups. A fundamental truth about enterprises is that they suffer from “silo sickness”…



embarkingonthejourneyv2I’ve seen many organisations who have embarked on Agile journeys. The large enterprises are harder to shift than smaller companies and start-ups. A fundamental truth about enterprises is that they suffer from “silo sickness”, a disabling condition that impedes the flow of value. Smaller companies are easier as they have fewer hand-off points as well as organizational silos. With start-ups one is always conscious to set up the organization right by applying the wisdom that only years of practical learning can provide.

silosicknesv2Enter “The Foundery”, RMB’s Technology Disruption Unit – this is where we want to showcase how to do it right. Being an Agile cheerleader, I wanted to help to shape the unit so that the entire unit is Agile – not only the technology component. My partners have already done some amazing work by creating an empowering and progressive culture. My contribution is to introduce the Spine Model. The Spine Model is a philosophy of thought that helps to set the framework that supports and enables teams wanting to improve their way of work.


spinemodelv2A key pre-supposition of the Spine Model is as follows: whilst hierarchy is sometimes useful it should only guide on what outcomes are needed and NOT how these outcomes are to be achieved. The ‘how’ is the mandate of the team. Autonomy is essential in a world of knowledge workers.

The Spine Model starts with the ‘what’. What is the need that each team is addressing?

We then flow to the values of the team: what does the team value? When talking at the value level, one must understand the organisational values, team values and values of the individuals. Self-awareness of these value drivers can be transformative. I would recommend reading the works of David Lapin on this subject.

Moving to principles: the principles that the teams establish become the means by which decisions are made. The absence of principles that the team agrees on puts the team into a place of chaos as decision making often defaults to decision by hierarchy.

Practices are often the place that people start their Agile journeys, “We’re going to do scrum and it’s going to solve all of our issues”. This is a common misconception and a mistake, the practice is far less important than the ultimate need that it supports.

Finally, we have tools that support the practices. I’m a great believer in tools, never do something more than once manually if it can be sensibly automated.

Simple right? Most things look good on paper, when the rubber hits the road then it becomes interesting. Look out for my next article on how you walk the spine.

by Jason Suttie