LeanAgileUS 2017

Lean Agile US

LeanAgileUS is taking place in Fort Lauderdale, Florida on February 27-28th. It has a real mix of great speakers and content, covering all aspects of Lean and Agile including Scrum, SAFe, Kanban, DevOps amongst other topics. I expect it to be an event where people come together for dialogue about different perspectives. I hope to hear more of “That’s interesting, tell me more” and less of “That’s wrong, and here’s why“.

My contribution will be twofold.

Firstly I have a talk on the Monday entitled “Good Agile / Bad Agile: The Difference and Why it Matters”, which you may recognise as the title of a recent post. I will be exploring some of those ideas in more detail. Here’s the abstract:

Stories of Bad Agile are common, where Agile is a local and tactical implementation, resulting in failed projects and initiatives. Businesses don’t get the results they had hoped for and Agile gets the blame for not working. Good Agile, however, is possible when it is directly and explicitly related to a business strategy. Thus Agile needs to be deployed strategically, with a clear diagnosis of the critical problem or opportunity faced, guiding policies on the approach to addressing the diagnosis, and coherent actions to implement the guiding policies. This talk will show how this approach can lead to Good Agile which is evolved through experimenting as opposed to Bad Agile being instantiated by copying.

Secondly I have a half day workshop on the Tuesday entitled “Enterprise Agility with Strategy Deployment”. This will be an opportunity to learn more about the X-Matrix, experience the process of creating one, and understand how to use it alongside other A3 templates. Here’s the abstract:

Strategy Deployment is a style of organisational improvement that engages the entire workforce in figuring out how the business can survive and thrive. This course will introduce Strategy Deployment using a framework called the X-Matrix – an A3 format which concisely visualises the alignment of results, strategy, indicators, and tactics on a single sheet of paper. With this approach, a transformation can be viewed as a form of Catchball, a Lean process where ideas are passed around an organisation as teams collaborate to experiment and discover solutions. In this way, solutions emerge from the people closest to the problem, rather than being defined and dictated by management.

The whole event is great value for money. Register soon as I’m sure it will sell out!

Strategy Deployment as Organisational Improv

IMG_0159At Agile Cymru this week Neil Mullarkey gave a superb keynote, introducing his rules of improv (left). He suggested that businesses can apply these rules to be more creative and collaborative, and that there is a lot of synergy with Agile. Like all the best keynotes, it got me thinking and making connections, in particular about how Strategy Deployment could be thought of as form of Organisational Improv.

I’ve blogged about Strategy Deployment a couple of times, in relation to the X-Matrix and Kanban Thinking, and Is Agile Working. Essentially it is a way for leaders to communicate their intent, so that employees are able decide how to execute. This seems just like an improv scene having a title (the intent), allowing the performers to decide how to play out the scene (the execution).

The title, and rules of the improve game, provide enabling constraints (as opposed to governing constraints) that allow many different possible outcomes to emerge. For example, we tried a game where in small groups of 4-5 people, we told a story, each adding one word at a time. The title was “The Day We Went To The Airport”. That gave us a “True North”, and the rules allowed a very creative story to emerge. Certainly something that no one person could have come up with individually!

B_SEWU8XIAIXsC5However, given our inexperience with improv, the story was extremely incoherent. I’m not sure we actually made to the airport by the time we had been sidetracked by the stewardesses, penguins and surfing giraffes (don’t ask). It was definitely skimming the edge of chaos, and I can’t help thinking some slightly tighter constraints could have helped. As an aside, I saw these Coyote/Roadrunner Rules recently (right). Adam Yuret pointed out that they were enabling constraints and I wonder if something like this would have helped with coherence?

What’s this got to do with Strategy Deployment? It occurred to me that good strategies provide the enabling constraints with which organisations improvise in collaborating and co-creating tactics to meet their True North. Clarity of strategy leads to improvisation of tactics, and if we take Neil’s Rules of Improv we can tweak them such that an offer is an idea for a tactic, giving:

  • Listen actively for ideas for tactics
  • Accept ideas for tactics
  • Give ideas for tactics in return
  • Explore assumptions (your own and others’)
  • Re-incorporate previous ideas for tactics

Dates For Your Diary

I’ve just updated my Calendar page with a couple of conferences coming up, as well as a new date for my Kanban Thinking course.

LeanUX15, New York, April 15-19

This is going to be a great event, with a fantastic line-up of speakers, covering a wide range of topics. I’m going to be talking about my current ideas on Strategy Deployment. If you use the code LeanUXSpeaker you’ll get 20% off. Prices go up on March 21st!

Agile Cymru, Cardiff, July 7-8speaker graphic-01

Another great event,  with another fantastic line-up of speakers! I’m particularly looking forward to this one because I get to go back to Cardiff, where I grew up and went to school.

Kanban Thinking Course, London, May 30-April 1

I’m running another training course with agil8 again in London. Here’s some feedback from the last one I ran:

  • Really engaging.
  • Found it fascinating and to be honest that surprised me.
  • It felt like a university lecture, in a good way! Very insightful and complete.

Heuristics for Becoming a Learning Organisation at Spark the Change

InfoQ have just published the talk I gave at this year’s Spark the Change conference on “Heuristics for Becoming a Learning Organisation“. This was the first time I introduced the Kanban Canvas, and gives some background to the questions it asks.

Please follow the link to watch, as I can’t embed it here.

Lean Kanban Central Europe 2014

Despite my best efforts, I couldn’t help but get involved in Lean Kanban Central Europe again this year, and have even taken on more of a role by helping co-chair the Kanban track. Its always a great event (one of my favourites) because the people and content are such high calibre. This year looks to be no different.

This year I’m also running a workshop (as previously announced). I hope to see you there!


Lean Agile Scotland 2014

I’m going to be at Lean Agile Scotland again next month. I had to miss it last year, but I really can’t decline the opportunity to be at a conference named after me! I’m running a workshop on “Building a Learning Organisation the Kanban Way”. Here’s the abstract:

In a world of Big Bang Disruption, the need for learning organisations is greater than ever. Businesses need to develop people to be able to continuously solve problems as well as implement solutions. This workshop will introduce a canvas that can be used to apply Kanban Thinking. Participants will work through the canvas, learning how the different parts can help towards enabling continuous improvement.

I’m told there are still a few tickets left. And I have a discount code which will get you 10% off the ticket price. Just let me know if thats of any use and I can send you the details. I hope to see you there!

Applying the Three Horizons to Agile Conferences

Relaxing after Agile2014, Eric Willeke made an off-hand comment about applying the Three Horizons Model to Agile practices. That struck me as interesting and got me wondering about how the concept could be applied to the Agile conference program.

ApplyingI have blogged about the model before as a way of thinking about value (although on reflection I’d now say its more about potential). To summarise:

  • H1 focusses on “extending and defending the core business”
  • H2 focusses on “building emerging businesses”
  • H3 focusses on “creating viable options”

The idea behind the model is to ensure a mix of investment across the horizons. Otherwise, if (or more likely when) the core business dies, it will not be ready with any new and alternative opportunities.


If we take these definitions, but think in terms of Agile practices, rather than businesses we get:

  • H1 focusses on “extending and defending the core practices”
  • H2 focusses on “building emerging practices”
  • H3 focusses on “creating viable options”

In this case, the Agile community would be ensuring a mix of investments across the horizons so that when the current core practices are no longer appropriate or useful, there will be new and alternative ones ready to be used in their place. That leads to the idea of having a conference program which includes an “investment allocation” in the different horizons. For example a 5 track conference could have 3 tracks on H1 topics, 1 track on H2 topics and 1 track on H3 topics giving a 60%/20%/20% allocation. Or a program made up of more traditional role/discipline/interest based tracks could allocate content across the horizons within each track.

The challenge, of course, would be agreeing on what topics are in which horizon. As an example, I might say Scrum and XP are firmly Horizon 1 as tried and tested methods. The various approaches to agility at scale might be Horizon 2 as they are still being explored and refined. Ideas from Beyond Budgeting or Cynefin might be Horizon 3 as they still being understood and experimented with.

The goal would not be to try and suggest any practices or approaches are any better or worse than other. The value would be in ensuring the longevity and continuing success of the Agile movement.

Speaking at Agile2014

Agile 2014

I’m going to be at Agile2014 in Orlando this year – the first time for a few years – and I’m looking forward to reconnecting with lots of people I haven’t seen for a very long time. If you see me, make sure you say “hi!”.

This post is to highlight a couple of things I’ll be doing there, or at least one thing I hope to be doing, and one I’ll definitely be!

First the hope. I’ve submitted a Pecha Kucha on Heuristics for Kanban Thinking, with which I want to introduce the questions asked on the Kanban Canvas. Here’s the description:

This talk will explore how heuristics can be used to frame Kanban Thinking and enable a problem solving capability. I will introduce a set questions which can be used to encourage creative thinking from multiple perspectives, from understanding the problems, to imagining the desired impacts and then designing potential interventions.

Please vote this up to help it get chosen. Otherwise I’ll just have to find another way of talking about the canvas (although I’ll probably run an Open Jam session anyway!).

Secondly, the definite. I’m running a workshop on the Enterprise Agile stage with my friend and former Rally colleague Rachel Weston Rowell. (Its on Tuesday Jul 29, 14:00-15.15 in Osceola A). The topic is Getting the X-Factor: Corporate Planning for the Agile Business. Here’s the description:

The pace of change is accelerating as technology advances, the economy becomes more global and markets become increasingly disruptive. As a result organisations are surviving for dramatically shorter periods of times. For example the average lifespan of organisations on the Standard and Poors 500 index has reduced by over 50 years on the last century, from 67 to 15 years. To survive, businesses need to change the way they operate at a corporate level, as well as becoming more Agile in their delivery capability. This involves moving to a model of co-creating and deploying an evolving corporate strategy, rather than centrally selecting and defining its rigid implementation, in order to create clear alignment, transparency and adaptability.

Join Karl and Rachel as they share the latest learnings from Rally Software’s journey of evolving their quarterly planning and steering. They will introduce one tool they have recently discovered and had positive experiences with, the X-matrix, through which strategy deployment can be achieved. This is a simple, single A3 page format, which visualises the correlations and contributions between strategies, tactics, improvements, results and departments. In this session you will work through completing an X-matrix for an example organisation.

Please come along! We ran this at RallyON, got great feedback, and had a lot of fun.


The BBC Seeds Of Kanban Thinking


Back in 2002 I wrote an Experience Report for the XP/Agile Universe conference in Chicago – one of the precursors to the current Agile Alliance “Agile 200X” series. The title was “Agile Planning with a Multi-customer, Multi-project, Multi-discipline Team” and the abstract was as follows:

Most XP literature refers to teams which work on a single project, over a number of months, for a single customer using a narrow range of technical disciplines.  This paper describes the agile planning techniques used by a team which works on multiple projects, for multiple customers, using a wide range of multiple disciplines.  The techniques described were inspired by the agile practices of XP and Scrum.  A small case study of a project shows how the team is able to collaborate with their customers to deliver maximum value under tight conditions.

I often reflect back on those early years of my Agile journey with my team at the BBC Interactive TV department. We had some great successes (including winning the BAFTA pictured here for the Red Button Wimbledon Multistream service in 2001), and many of the things we did back then have shaped the way I approach my work as a coach now. In particular, and admittedly only with hindsight, I can see the first seeds of Kanban Thinking even though I didn’t have the knowledge to understand that yet. This post will try to map that out in some more detail – it will make a lot more sense if you have read the original paper!

Studying the Context

We did a very crude form of demand analysis in a couple of ways. Firstly, we realised that we worked on “a large number of very short projects, typically of a couple of weeks in length”. Thus we evolved to what  we would now call a Service Oriented Approach  to delivery by treating “all projects as a single ongoing project”. Secondly, we recognised that we had a variety of different response profiles for projects – what we would now probably call Classes of Service. In particular, there were those with “immovable delivery dates, such as a major sporting event like Wimbledon” and others with “unknown delivery dates, due to the nature of channel scheduling”. These unknown dates could be sprung on us at very short notice. In addition, something not mentioned in the paper is that roughly every quarter, one new service would be identified as one which we try to do something different and use as an investment in innovation.

While we didn’t make it as explicit as I now would, we did have a simple value stream, both up-stream and down-stream of the development team’s work. The upstream work happened as each project approached its planned build time and it was broken down into stories and estimated. The downstream work happened during extensive exploratory testing on each set-top-box, especially for Satellite services which required independent testing by the platform operator Sky.

Finally we understood that the specialist skills and disciplines within the team meant that we had an availability constraint for certain types of work. As well as using various practices to minimise the impact of this, we also ensured that we planned with this in mind, being very cognisant about which projects required which types of work so that we could balance the work accordingly, or allow for the fact that a particular area might be intentionally overloaded.

Sharing the Understanding

The fact that in the report only I only gave a passing mention to the fact that story cards were also “put up on the wall to highlight the current work, and to provide a  focus for regular stand-up meetings” says a lot about how much we have learned about the importance of visual management in the last 10 years. We used a very simple form of visualisation by hanging a sheet of plastic photograph holders on the wall. The sheet had a number of wallet slots into which photos were designed to slide, and which conveniently, index cards also slid into. Thus we displayed the weeks cards, and clearly marked them as they were completed so we could easily see progress during the week. This card-wall provided the focus for the week and as I recall, it helped us to talk about the progress work more clearly.

The Excel spreadsheet also provided a simple visualisation of the longer-term plan, and this we posted next to the card-wall. While we only printed it in A4 size, it would easily have scaled to be a form of A3, providing a clear picture of what the current thinking was for the next few months on a single sheet of paper. In addition the ‘provisional’ line gave a very crude indication of the value stream in that projects ‘above’ the provisional line were ones that we had fleshed out into stories with estimates. I have a vague recollection that we also added some form of visualisation of what work was in testing or ready for broadcast, but I don’t recall the details unfortunately. The use of colours on the spreadsheet was simply to help see the size and ‘shape’ of each projects. That is, how many weeks, and how many streams it was planned on taking. I used to think of this as “Tetris Planning”

Containing the Work

The Excel spreadsheet streams provided a very basic form of WIP limit in that it ensured that we never worked on more than three project-platforms at the same time. On other words, if we worked on 3 different projects, each would only be for a single platform (Satellite, Terrestrial or Cable). Generally, however, we would work on a single project across all three platforms, where each platform would be considered a single stream of work. In addition there was also often back-end content generation work, which would also take up a stream.

This way of containing the work could also be described as a form of investment allocation, although we didn’t measure the specific allocations precisely. The simple visualisation did give us a means of roughly seeing how much time (in weeks per stream) we were investing in each platform.

At the team and story level, the card slots described above also provided a very crude way of limiting WIP. Because the plastic sheet only had a finite number of slots we soon learned that once the sheet was full, then we had a strong indication that we had enough work for the week.

Sensing the Capability

The main metric we used was velocity as that was the most documented Agile metric at the time. However, we realised that by measuring velocity over a weekly cadence there was always going to be unavoidable variability. At the time we used a moving average, although I’d love to be able to go back and use other techniques to understand that data such as statistical process control and percentile coverage. I also wish we had better data on the number of stories completed each week. The estimations were very coarse-grained, and we were pretty close to using #noestimates, although without the more sophisticated analysis and forecasting that is around today. It would also have been incredibly valuable to have known about other metrics, in particular the various qualified lead times of the stories flowing through the process.

The two key cadences that we used were the weekly and quarterly ones. The weekly cadence was effectively a review and queue replenishment one, where we looked back on our progress the previous week, and re-planned the stories for the coming week. The quarterly cadence was more of a steering cadence, where we updated the Excel plan with our best guess at what projects would be coming next and what the key dates would be.

Exploring the Potential

This time period at the BBC was one of constant exploration, and it was this aspect, of breaking the “rules” and trying things out, that I probably learned the most from. I didn’t have all the knowledge of the all the models and theoretical underpinnings that I have now, so much of the exploration was intuitive rather than with scientific discipline, but it certainly encouraged me to always try things out for myself, and not just stick to what I had read or heard somewhere.


The LSS Reactor Conference – Tell Us Your Stories

Lean Systems Society Reactor Conference

The Lean Systems Society is hosting a conference in Boulder in September, and as part of the event we are capturing stories about people’s experiences with Lean-Systems. This post is to give some more details on what its all about.

First, who are the Lean Systems Society?

Essentially we are a non-profit organisation trying to bring diverse Lean-Systems thinkers together, be a catalyst for new ideas, and then promote those ideas. A phrase we’ve been using recently to describe when we mean by Lean-Systems is “value first, people-based systems”. A key part of the Society is the Fellowship, a group of people we recognise as having done great work in this area.

Next, what is the Reactor Conference?

The idea is that this will not be a traditional “talking heads” conference but an opportunity for people to actively participate in working with the Fellows and other leaders in exploring or creating something new. The name Reactor comes form the idea that we want to create a container within which a reaction will happen to create new energy. Think “Nuclear Reactor” (but without any negative connotations!). We hope it will be a pretty unique event.

Finally, why the story capture?

One of the ways we are facilitating this is through Cognitive Edge’s SenseMaker technology, using it to capture stories of peoples experiences with Lean-Systems, and then explore the patterns from those stories. Thus, the stories will guide the conversations and work at the conference. The more we have, the better the conference will be, and the more likely we are to generate valuable outcomes.

Please register for the conference if you can, and tell us your stories even if you can’t attend the conference.