Agile – Where my Head’s At

Jeremy Deller in front of his Acid Brass Mind Map

Jeremy Deller’s Acid Brass Mind Map


Thanks to Karl Scotland, Agile Methods have been a part of my working practice since the turn of the century.  Test Driven Development, Continuous Integration, Refactoring and Collaboration with the Customer are fundamental to how I lead teams and write code myself.

Despite this I’ve found the term ‘Agile’ itself to be less and less useful.  At it’s worst it appears to be pretty much as the hilarious Half Arsed Agile Manifesto describes it.

More often than not it’s a shorthand for Scrum.  There is nothing wrong with Scrum of course.  I’ve found it hugely effective for delivering certain classes of project.  It also plays well with other methods and tools, something that resonates throughout Henrik Kniberg‘s  excellent ‘Lean from the Trenches’

Which kind of brings us to the point of this post and the picture of Jeremy Deller’s Acid Brass Mind Map at the top of the page.

I’ve finally got round to reading Change By Design, Tim Brown’s book on Design Thinking, having discovered it through the work of Gojko Adzic.

The more I read, the more it resonated with the things that inform and matter to me in my practice.  It shares the Kanban Method‘s humane agenda; like Real Options and Impact Mapping it seeks to generate possibilities and alternatives.  It’s emphasis on collaboration and co-creation with the customer are found in Systems Thinking and XP.

All of which lead me to make my own mind map to show the methods and tools that I learn from and work with:
Agile Mind Map

This is where my head’s at now.  The people, ideas, methods, tools and books that define how I work and what I value.

Posted in Agile, Kanban, systems thinking | Leave a comment

Glass Case Planners

Last week I saw Narek Alaverdyan give an inspiring Agile London talk on his work at transforming their delivery cadence, creating the ability to experiment and fail early, and so deliver more value to the business.

This image, from his talk, of factory staff managing the work from the safety of a glass walled office high above the production line resonated with me:

Glass Case Planners

It reminded me of one of my favourite Anti Patterns, from the book of the same name, “The Glass Cased Plan”:

Often, a plan produced at the start of a project is always referenced as if it’s an accurate, current view of the project even if it’s never updated.

Glass Case Plan

Anti Patterns p222.

In Alaverdyan’s picture it is the planners themselves who are in the glass case, away from the work on the factory floor.

As was clear from Alaverdyan’s talk, for the complex, emergent work which characterises software development this does not work.

Don Reinertsen in ‘The Principles of Product Development Flow’, contrasts manufacturing with product development:

In manufacturing it is both feasible and beneficial to make all our economic choices in one large batch before we start the work.
Some product developers aspire to use the same approach in product development.  They prepare a minutely detailed plan at the beginning of the project and measure performance against this plan.  When they deviate from this plan, they take corrective action.  They aspire to front-load their decisions.  While this is a superb strategy in repetitive environments like manufacturing, it is a terrible one in product development.

Why? In product development, we continuously receive new information from the market and from the design process.  Customer preferences change.  Engineering tasks that looked easy at first may now require breaking the laws of physics.

The Principles of Product Development Flow p38.

It was when reading one of Chris Matts’ blog posts that it struck me that what Reinertsen was describing was the difference between complicated work and complex work:

 If you know in advance what is needed, you are in a complicated system. You can specify and plan in detail to create an optimal delivery at scale (A long lead time and short duration). Hence the space shuttle. Complicated systems struggle to react to changes in context which can cause analysis paralysis. In product development, complicated systems are managed and dominated by experts. The axioms of this paradigm are untested assumptions. This is the realm of early commitment and the slaying of valuable options. As a cautionary note, these systems have the potential to suffer a catastrophic failure if they choose to ignore the context changes.

This distinction between complicated and complex comes of course from Dave Snowden’s Cynefin framework.  Matts’ post is well worth reading in full for an illuminating description of Cynefin.

In order to work in the complex domain you need the people who get the context to be empowered to make decisions.

With no power comes no responsibility

The last time I saw Matts he was wearing a T shirt baring these words.  At first I just thought this was a cute quote from the Kick-Ass movie.

Then it struck me, in every software development endeavour I have been part of, the power needed to be outside the glass case of management, in the work.  Rather than experts looking down on the work, the decision makers need to be positioned to respond quickly to feedback and empowered to do so.

This is the ‘power’ in empowerment.  It is why that word means so much more than the ‘delegation’ which managers such as I are often want to use.

The complex nature of the work means the people doing it know best how to respond to it, shape and direct it.

This is not anarchy.  If a team self organises without any context you are just replacing one glass case with another.  It’s just that the glass case is around the team.

It does mean that as a manager you need to let go and trust the people doing the work. You act on the system, the context people work in, and together find the most effective way of working.

This is not something I find easy to do.  What is easy is for me to bring my expertise to bear on the work.  Doing so ignores the work’s emergent nature.  It is a voice shouting from the remove of a vantage point too distant from the work to act fast on the feedback that comes from it.

What is needed instead is a way to signal when I should get involved, and the people doing the work to have the power and responsibility to act, pulling me in as needed.

Posted in Kanban | 1 Comment

Bjarte Bogsnes Beyond Budgeting Breakfast Briefing – Key Ingredients

Last week I was lucky enough to take part in Bjarte Bogsnes ‘Beyond Budgeting’ Breakfast Briefing organised by Ivar Jacobson International and Rally Software.

A lot of the ground covered in the talk can be found in these articles which I thoroughly recommend reading:

Here I’d like to share what I took away from the event, how I think it relates to the work of other management thought leaders and why it matters to me.

Why Beyond Budgeting?

The problem beyond budgeting seeks to address is the slowness and lack of agility that comes to business that have grown over time. They become ‘sad places to work’.

Bogsnes likened this to the ageing process of man. Whilst ‘age takes us all’ as he put it, it does not have to be the case for business.

The methods and learning he presented showed a way to counter this whilst, critically, keeping the benefits of being big.

Why Start with Budgets?

There is a lot more to Beyond Budgeting than an alternative to traditional, periodic, budgets but the reason to start there is that a budget is often what gives the remit for work to take place.

To do this it conflates a target, a forecast and permission for resource allocation.  The problem is, these are three things that have conflicting purposes.

Bogsnes counters this by splitting these three facets out into:

  • Target
  • Forecast
  • Resource

This immediately made me think of John Seddon‘s:

  • Purpose
  • Measures
  • Method

This comes from Seddon’s book, Freedom from Command and Control. Tellingly, the full title of Bogsnes Talk was “Beyond Budgeting from Command and Control to Empower and Adapt”.

What I like about Seddon’s language is that he starts with ‘Why’.  A Target may set direction but it doesn’t tell you why you are going in that direction.

What I like about Bogsnes ‘Forecast’ is that it casts the measures as explicitly forward looking. It is stating the probable outcome, like a weather forecast.

It is the forecast that gives you a direction of travel.  As Bogsnes says “They might for instance show that we are heading in the wrong direction, towards places that we absolutely don’t want to go.”*

Measure and Forecast come together in the work of Troy Magennis.  He uses “historical cycle time data to answer questions of forecasting and staff skill balancing“.  Check out his Keynote from Lean Kanban Central Europe 2013.

Finally, it is from method that we determine what resource we need, that is what type of capabilities we need to pull in.  These will be different depending on the method we have chosen. For example, we might have a goal of gaining a thousand new customers, we will measure that goal by the number of new sign ups we get but the method for achieving that might be through marketing, through IT or some other means.

Human After All

At the heart of Bogsnes talk was an understanding not only of the complexity of the organisation but also of the complexity of us as humans.

This is a theme that comes up again and again in the Lean/Kanban community and Bogsnes was of course a keynote speaker at this year’s Lean Kanban North America.

I have to admit that I am only just now coming round to the significance of this and Bogsnes talk really helped clarify my thinking on it.

In my appetite for Systems Thinking, seeking to understand “how to act on [the] organisation for improvement”**, to manage the work, not the workers, I have paid less attention to “The Human Side of the Enterprise” – a phrase used by Bogsnes and taken from the book of the same name by Douglas McGregor.

The author whose work I’ve found most useful on this subject has been Daniel Kahneman, channeled through the work of David Anderson.

Anderson’s closing keynote from Lean Kanban Central Europe 2013 is a good introduction to Kahneman and why his work is significant to modern management methods.

Kahneman models the way human process information by way of two systems, that word again.

The differences between System One, intuition, and System Two, reasoning are enumerated in this Wikipedia article.  For the full story read Kahneman’s Thinking fast and Slow.

Why I find this useful is that it is acknowledging the fact that our experience of the world, and so the world of work is mediated through what makes us human.

To discount it, to talk only of the system in which we humans operate is to remove the very thing that enables us to engage with it and make it better.

It’s why language, and choice of language is so significant. A good example of this in Bogsnes work is his use of the word “translate” rather than “cascade” for how information is disseminated through the organisation.

Think for yourself

Bogsnes talk took the form of an experience report.  He told the story of what happened and is happening at Statoil.

He was offering experience, not a management recipe.  As Bogsnes says, with a management recipe, someone has done the thinking for you.

What I take from thought leaders like Bogsnes, Anderson, Magennis and Seddon are method and ingredients.

You can adapt method. You can substitute ingredients, choose how much of them to use and when to use them.

There is a risk that when taking the ingredients from one recipe and putting them in another you end up with something inedible.

Get your use of ingredients right and the results will taste good.

You need to think for yourself.  Experiment.  Think about language.  If it isn’t working, change it.
** Freedom from Command and Control a better way to make the work work, John Seddon, 2003 p.14

Posted in Communication, Kanban, systems thinking | Leave a comment

C64 style terminal in OSX

My good friend @megastoat pointed me to these great Commodore 8Bit True Type Fonts.

Here they are in action in the OSX terminal:

C64 Terminal

And here is the .profile for the login message:

Posted in C64 | Leave a comment

Impact Mapping with MindMup

I’m a big fan of using Impact Mapping to set software development off on the right foot.  It does this by ensuring you are working towards a measurable goal; thinking upfront about who is going to help you achieve that goal and how they are going to do this.  It helps you do this before you get into what it is you are going to build so giving you a better chance of actually building something useful.

Whilst the Whiteboard remains my preferred place to do impact mapping, at Base79 we’ve recently been playing around with using MindMup for this too.

Here’s one we made earlier:

Impact Map

We’ve separated the Measure of the Goal into a node of its own.

We use different colours to call out the Goal, the Measure of success in achieving the goal, the Actors, the Impacts and the Deliverables.

You can you can use keys 1,2,3 to select a whole level and then set its colour.

I think a nice addition to MindMup would be if it could default to a given colour depending on where you are in the hierarchy of the map.

Posted in Communication | Leave a comment

Lean/Kanban – The Perils of Partial Adoption

Following a conversation on Twitter with Al Shalloway I thought I’d post this reflection on the perils of partial adoption when introducing Lean and Kanban into an organisation.

In his book “Systems Thinking in the Public Sector” John Seddon talks about the Dutch city of Delft’s method for social landlords to let their properties.

It is a method that is based on available capacity, vacant properties, being directly advertised to those who need them, i.e. the source of demand, with feedback on which applicants for these properties had been successful advertised in the same media so that unsuccessful applicants were able to check the qualifying conditions of the successful applicants.

In the UK this process was adopted but crucially combined with an existing practice of maintaining a database on which applicants had to register before they could apply.

Seddon sums up the folly of this partial adoption:

“The Government’s scheme took an idea that was developed in Holland, modified it to fit with existing practice and, as a result, removed its essential value.
This is a classic example of copying without knowledge, rather than seeking first to understand the thinking and principles behind the original design”

I have lived this. Whenever the lean adoptions I have led have faltered and shown signs of this, it is this description from Seddon’s book that haunts me.

Whether it has been management insisting on man hour estimates when presented with data based cycle time forecasts or stagnation caused by a failure to control WIP I think of the naive and partial adoption of the ‘Delft Model’ as described by Seddon and set about fixing where we were going wrong.

I will be talking about these experiences as part of my Dare 2013 talk in a couple of days time.

Posted in Kanban, systems thinking | Leave a comment

Why I Love Baby Signing

Last November, Sasha Felix, founder of baby signing programme Sing and Sign asked parents to write about their experiences of Baby Signing for the Sussex addition of ABC Magazine.

You can read it in the online version of ABC magazine (Select Page 27 at the top of the page).  or here it is in glorious plain text:

“Change my nappy, change my nappy!” This was the first sign our then ten month old boy Elco used.

This was quickly followed by ‘Eat’, ‘Drink’ and ‘Sleep’  Elco

His being able to tell us his needs so clearly was both a joy to behold and a huge relief as it removed the frustration, for him and for us, of not being able to know what he wanted from us.  No longer was there the trial and error round of, is it his nappy? is he hungry? Is he thirsty? Is he tired?  He could just tell us!

For this alone baby signing is for me a ‘must have’ for parenting, but it is so much more than this than an expression of needs.

As the weeks went on, Elco started to use signs to tell us about things he could see, or things we had done.  He would combine signs together, ‘Cat’ and ‘Sleep’ to tell us about seeing a neighbour’s cat asleep on the lawn.

Signing was the enabler of some deeply emotional and memorable exchanges.  I remember returning from a business trip to the US to find mummy and baby Elco standing on the door step, Elco signing ‘Daddy’ to me as I got out of the taxi.

Elco, as I gather is common with lots of children who learn baby signing, experienced a ‘signing explosion’ at about twelve months when he suddenly started signing all sorts of things.  Everything had been going in and suddenly it all came out in a rush of communication and expression.

As he learnt to talk he would combine words, or approximations of words with signs. So the signs for ‘train’ and ‘cake’ together with the sound ‘Mu’ for ‘Mum’ recalled our day trip travelling on a steam train and mummy buying us all some cakes.

On top of all this, the sing and sign classes are an absolute joy for both parent and child.  Joining in the songs with the other mums and dads both helps to cement your knowledge of the signs in your own mind but also make the whole class cohesive.  We still have friends we keep in touch with from Sing and Sign.

I am not ashamed to say how much I enjoyed it when a favouite song, like ‘Change my nappy’ made an appearance in the class.  It was a bit like going to see your favourite band and them playing one of your favourite songs, there was such an emotional resonance.

Having the parents and children all join in and engage in the same way is key.  After all you are aiming to communicate with your child, to share things, what better way to do this then by sharing in the songs and activities in the class;  Where oh where oh where is Jessie?

Elco is now five years old and will still occasionally come out with a sign, normally accompanied with large guffaws of laughter, ‘Beans on Toast’ is a favourite of his.

The CDs of the songs from the class remained a firm favourite long after he had learnt to speak and the Sing and Sign books, both the Jessie Cat book and the Signing Dictionary took on a second life as bed time story books long after their original purpose had been superceeded.

 When Elco’s little brother Louie came along earlier this year, we started singing and signing with him from day one.  When it’s getting towards bed time and he is starting to get a little fractious, we sing him the ‘Bathtime’ song and his little face lights up as we sign playing in the water, seeing the little boat and the little fish.

This to me demonstrates the real value of ‘Sing and Sign’, that it is activating the intelligence and desire to communicate that are there in children from the start.

It gives them a way to express their wants and needs but also to share their view of the world with you.

You are not teaching them to sign so much as to communicate.  It just happens to be with signing.  As speech comes along the signs drift away, the signs and the songs having played their part.

I am normally the last person to offer advise to new or soon to be parents but I make no apologies for extolling the virtues of Sing and Sign.  It’s wonderful and I can’t wait to start taking our youngest to classes in the new year.

Posted in Communication | Leave a comment

Telephone Game Fail

Here at Base79 we do a weekly Technology show-and-tell for the dev team where one member of the team talks about a technology, practice or method they are using.

This week I did a session on Specification by Example, talking about how we use it across our various workstreams.

To make the session a bit more interactive I thought I’d do a paper version of the telephone game, or Chinese Whispers as we call it in the UK.

In this version, we start with a written phrase which is then translated into a picture, then back into writing, then back into a picture and so on until the final written phrase emerges at the end of the chain.

This was supposed to illustrate how information gets lost or distorted with each translation, as it does when a Requirements Document is translated into a Functional Specification and User Acceptance Tests and into the Code itself.

The exercise didn’t quite pan out as I expected.  Either I chose a phrase which was too resilient to translation or our dev team are completely attuned to each other and excellent communicators because this is the result we got:

Tour De France - Telephone Game

Tour De France – Telephone Game

Posted in Communication | Leave a comment

Fun with OAuth, gdata and the Google APIs Client Library for Python

One of the fun aspects of working in IT is the way the simple things you think you have a handle on give way to more complicated technologies as the problem space changes.  Going from ASCII to Unicode is a good example of this, a transition greatly eased by this great Joel Spolsky piece.

Recently I have had to move from the simple familiarity of Username/Password authentication to OAuth.  Changhun Oh has provided a very useful guide to the OAuth dance.

I need to use OAuth to allow me to programatically post Specification by Example Feature files to a Google Sites Wiki.

Google provide a great page on how to use the Python Google APIs Client Library to authenticate with OAuth 2.0 but if you’re using the older gdata APIs, such as the Google Sites API then it is not immediately apparent where you go next once you are authenticated.

After some digging around I found a blog post by Shraddha Gupta  which showed you how to munge the two together.  The example given was for gmail, below is my soup to nuts example for Google Sites:

Posted in OAuth, Python | Leave a comment

BDDX 2012 Take Aways

This year’s Agile Testing and Behaviour Driven Development Exchange, BDDX, took place last Friday, 23rd November. It was full of great insight and I wanted to record my take aways from the event.

A central theme of the day was of stepping back, looking at how we see the world and testing to see whether it is still the required fit for what we were aiming to achieve.

In the opening keynote, Dan North started with Chris Argyris and the concept of ‘Double Loop Learning’ which Benjamin Mitchell has done so much work in bringing to the Lean/Agile community. Dan North summarised it as

“Double Loop learning is about stepping back and saying ‘is that even the right process? Are we even on the right track?’

He set us the homework to go and find out more about Argyris and Double Loop Learning.

Dan North and Gojko Adzic then proceeded to draw a model of software development, Mike Cohn’s picture of software delivery in Scrum and then move from that to a picture of a continually shipped product which starts off ‘rubbish’ but improves via feedback from the business.

This is in line with Guy Kawasaki’s rules of “Don’t Worry be Crappy” as long as you ‘Churn Baby Churn’ from his Rules of Innovation.

My key take away from this talk was that existing models of software delivery “declare success to early” to use Gojko Adzic’s phrase. That is, all to often we model the delivery of capability which has the potential to affect change rather than the impact of the change itself.

Saying we are done before that potential has been realised is premature, we are not answering the fundamental question of why we did the work in the first place and whether it was the right thing to do.

This is where Impact Mapping comes in, taking the focus away from ‘what’ has been delivered and shifting it to ‘why’. This is not a million miles away from John Seddon’s Purpose, Measures, Method.

This systemic view of the world was reiterated in there being a number of references to Kanban in the talks. Andrew Burfoot & Walter Badillo from Go Viral talked a lot about their Kanban systems, and their adherence to the rule of “value trumps flow, flow trumps elimination of waste.”

Chris Matts in his talk described Feature Injection as being a pull system, with the customer pulling value from the system through the value chain of features.

Just as the keynote urged us to step back from our view of software delivery and ask questions of it, so Chris Matts in his description of Feature Injection showed us how to do this at the scale of individual requirements.

Using specific examples, a model of the world is built up with each new example either confirming or breaking the model.

Like Dan North, he too set us a homework, to play ‘Break the Model’ with Lego bricks.


When I got home, I had a go at this and was struck by how deciding whether a piece fits the existing model is by no means black and white. You have to probe a bit. I started by modelling the bricks as being flat rectangles, then extended the model to include colour, then adding depth.

I then came across this piece which I really struggled to fit into the model. As I thought of how to describe it in terms of geometry, it dawned on me that I was only using a geometric classification by default and that it didn’t have to be the only way of modelling the bricks.

If the purpose of the model was to identify all the lego bricks that could be joined together to make something then did the size and dimensions matter at all? Children rarely care if their Lego models are uniform in colour. Could we instead just group together all bricks that can be joined to each other?

The shape of the model and the level of detail it contains is determined by the reason you are building it in the first place. We are back at “Why”

This put me in mind of Eric Evans’ Domain Driven Design. I was lucky enough to do Gojko Adzic’s two day Specification by Example course earlier this year. The lightbulb moment for me on that course was when Gojko referenced Evans “Refactoring to deeper insight” when we found that the model in one of the exercises did not adequately fit the behaviour we wanted it to support. The new behaviour had broken the model and we needed to change it for it to continue to be of use.

Having a model which we apply and make use of until it is superseded by one which is a better fit, either because the world has changed, our understanding of the world has changed or what we need the model to do has changed is a pattern we see throughout software development, from the processes we use down to the individual features we develop.

It is also one we find far from the world of software development. Throughout the day at BDDX I kept finding myself thinking of a book I read about twenty years ago, back when I was studying Art History in the early 1990s.

In his book Art and Illusion, subtitled “A study in the psychology of pictorial representation”, the Art Historian E H Gombrich opens his chapter “Truth and Stereotype” by quoting Immanual Kant

“The schematism by which our understanding deals with the phenomenal world…is a skill so deeply hidden in the human soul that we hardly shall guess the secret trick that Nature here employs.”

In a chapter which takes in the Bayeux Tapestry, Cezanne’s views of Mont Sainte-Victoire and Durer’s Rhinoceros he describes how the selective preferences, tools and mediums of artists affect the information images convey, and that over the years, the information pictures were expected to provide “differed widely in different periods”

When encountering something new, artists have selected an existing schema to apply to its representation and then adjusted and adapted from there. “The familiar will always remain the likely starting point for the rendering of the unfamiliar”

He concludes by saying:

“What matters to us is that the correct portrait, like the useful map, is an end product on a long road through schema and correction. It is not a faithful record of a visual experience but a faithful construction of a relational model.

Neither the subjectivity of vision nor the sway of conventions need lead us to deny that such a model can be constructed to any required degree of accuracy. What is decisive here is clearly the word ‘required’. The form of a representation cannot be divorced from its purpose and the requirements of the society in which the given visual language gains currency”

Again we are back to “Why” What is required?

What I find exciting about both the Lean/Kanban community and the BDD community is that both are actively engaged in encouraging and accelerating the breaking and correction of the models we use to underpin our work and so always be looking to improve what we do and how we do it.

Posted in BDD, Kanban, systems thinking | Leave a comment