Agility is a Strategy, Agile is a Tactic

Agile Manifesto

Ron Jeffries recently blogged about his reflections on the Agile Manifesto, and what he wished the authors had done and said differently with hindsight. His conclusion was that he would have rather focussed on practices.

I have a different perspective.

My concern with an even stronger focus on practice is that it would lead to even more Cargo Culting than we see already. People simply copying practices they see and hear about in the hope that implementing them by the book will magically lead to them being Agile. We would end up with more teams using the autonomy encouraged by Agile to choose the way they work, but with no alignment to the original goal of improving business results.

Worse still would be even more conversations about things “not being Agile” than we see today. As Jabe Bloom recently tweeted: ‘the statement “X isn’t Agile” fills me with meh‘.

I much prefer Joshua Kerievsky’s take on what he calls Modern Agile. I think he has taken the opposite approach by trying to take what we have learned over the last 20 years and describe the intent. I would describe what he calls disciplines as strategies, and I believe the transformation of an organisation to have greater agility to be an example of what the Lean community call Strategy Deployment.

Let me explain.

Strategy Deployment, like most Lean ideas, has its roots in a Japanese term, Hoshin Kanri. The literal translation is “Direction Management”, but a more colourful translation “Ship in a storm going in the right direction”. This brings to my mind the image of everyone using all their skills and experience to pull together, with a common goal of escaping turbulence and reaching safety. Thus Strategy Deployment is an approach to organisational improvement which engages he entire workforce in figuring out how the business can survive and thrive.

Significantly, this means a shift from organisations operating on the basis that senior management knows best, and tells employees what to do without thinking or asking questions, to one where they propose direction and ask for feedback and enquiry. Instead of assuming that they know the right answers as a facts, Strategy Deployment assumes that any suggestions are opinions to be explored and challenged, with the possibility that they may turn out to be wrong, and making it acceptable for people to change their mind.

What leadership proposes, therefore, is strategy, using it as a form of enabling constraint to guide and open up possibilities of what could be achieved. This is as opposed to defining tactics as a form of governing constraint, dictating action and closing down any alternatives that could be explored. A useful metaphor here is the one used by Dave Snowden of types of skeleton. An enabling constraint is like an endo-skeleton (e.g. humans) – formed on the inside, maintaining coherence and allowing growth. A governing constraint is like an exoskeleton (e.g. crabs) – formed on the outside, protecting and limiting growth.

By being clear on strategy, and allowing and encouraging the whole organisation to use their skills, knowledge and experience to discover appropriate tactics, it is possible to enable autonomy while maintaining alignment. In this light, all the various Agile practices are simply tactics (and very good ones) to help organisations achieve greater agility as a strategic goal.

In other words, Agility is a Strategy, Agile is a Tactic.

Although obviously its not quite a simple as that! I’m not sure that many executives would actually say that greater agility was a strategic goal. However, some of the primary outcomes that agility enables are relevant as strategic goals. I like to use the dimensions identified by Larry Maccherone as a starting point:

  • Productivity – amount of delivery
  • Responsiveness – speed of delivery
  • Predictability – consistency of delivery
  • Quality – delivering the thing right
  • Customer Satisfaction – delivering the right thing
  • Employee Engagement – delivering sustainably

And all of these would help achieve more general strategic goals such as focussing on new markets, regions, technologies, business models etc.

What’s all this got to do with the Agile Manifesto?

It seems to me that what the Manifesto authors had identifies was a different set of strategies to deliver successful software, and a thought experiment, I wondered what the Manifesto might it have looked like if it had been written as a set of strategies. I’m not suggesting actually rewriting it but it seems like an useful idea to explore. This is what I came up with:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work, our strategies have become to:

  • Empower teams around economies of flow
  • Reduce the batch size of value delivery
  • Explore the evolutionary potential of solutions
  • Sense and respond to feedback

Why did I choose those?

Empower teams around economies of flow – “Individual and interactions” is about people, working together as part of a value stream, using their collective expertise to maximise the flow of delivery.

Reduce the batch size of value delivery – “Working software” is about those teams  delivering valuable software early and often in smaller batches, using incremental and iterative approaches.

Explore the evolutionary potential of solutions – “Customer collaboration” is about working closely with customers to discover how to meet their needs through empathy and experimentation.

Sense and respond to feedback – “Responding to change” is about using the smaller batch size for knowledge discovery as well as value delivery, and using that information to create feedback for continuous change.

What would you choose?

This is just one interpretation. It was not an easy exercise deciding what to include, and what to leave out, and its at least the 3rd version I have some up with. I’m sure people will have different opinions. I’d love feedback on what they are! Please leave a comment on what your strategies are to achieve greater agility.

Agile Manifesto Strategies

VN:F [1.9.22_1171]
Rating: 5.0/5 (5 votes cast)

Are we tabby cats trying to emulate cheetahs?

Credit: Dennis Church

Credit for the title of this post goes to Sam Murphy, Section Editor at Runners World UK. Those of you who have seen me recently we will probably know that as well as being an advocate of Lean and Agile, I also have a passion for running, and I subscribe to Runners World. Sam used this title for an article of hers in the September issue, which struck me as having lots of overlaps with how I go about coaching and consulting in businesses. The gist of it was that when training, rather than trying to copy what elite athletes do, we should find out what works for ourselves. Sound familiar?

Here’s some quotes:

Dr Andy Franklyn Miller … concluded that ‘a very unique and customised strategy is used by each swimmer to excel’. And if that’s the case, is looking at what the elites are doing and aiming to replicate it the best way to maximise our own sporting success? Or are we tabby cats trying to emulate cheetahs?

Is a very unique and customised strategy used by each successful organisation to excel? Is looking at what these organisations are doing and aiming to replicate it the best way to achieve success? Or are we tabby cats trying to emulate cheetahs?

Dr George Sheehan, runner and philosopher, said “We are all an experiment of one.’

and

Ultra runner Dean Karnazes … writes “I always encourage people to try new things and experiment to find what works best for them.’

It seems athletic training is not so dissimilar to building a successful organisation! Rather than just copying what we may have seen or read about working elsewhere, we should encourage organisations to try new things and be experiments of one. That’s what Strategy Deployment is all about!

Or (to close with the same quote Sam closed her article with) as Karnazes also said:

‘Listen to everyone, follow no-one.’

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

Kanban Deployment with the X-Matrix

This is a continuation of my musings on Strategy Deployment, the X-Matrix and Kanban Thinking (including Strategy Deployment as Organisational Improv and How Do I Know If Agile Is Working). I’ve been thinking more about the overlap between Strategy Deployment and Kanban and come to the conclusion that the intersection of the two is what could be called “Kanban Deployment” [1].

Let me explain…

To begin with, the name Strategy Deployment describes how a centralised decision is made about strategy, which is deployed such that decentralised decisions can be made on defining and executing plans. The people who are engaged at the coal face are the people who are most likely to know what might (or might not) work. In other words its the strategy that is deployed, not a plan.

Similarly, Kanban Deployment can be used to describe how a centralised decision is made about kanban as an approach to change, which is deployed such that decentralised decisions can be made on defining and executing processes. Again, the people who are engaged at the coal face are again the people who are most likely to know what might (or might not) work. Its kanban that is deployed, not a process.

With this perspective, we can look at how the X-Matrix could be used to describe a Kanban Deployment in terms of Kanban Thinking. (For a brief explanation of the X-Matrix see a post on how we used the approach at Rally).

The Results describe the impact we want the kanban system to have, and the positive outcomes we are looking to achieve with regard to Flow, Value and Potential. Just like with ‘regular’ Strategy Deployment, an economic model as recommended by Don Reinertsen is likely to provide clues as to what good results would be, as will a good understanding of fitness for purpose.

For Strategies we can look to the Kanban Thinking interventions of Study, Share, Stabilise. Studying the system is a strategy for learning more about the current context. Sharing knowledge is a strategy for creating a common understanding of the work and the way the work is done. Stabilising the work is a strategy for introducing policies which will enable and catalyse evolutionary change.

The Indicators are equivalent to the Kanban Thinking intervention Sense. These measures of improvement, while proxies, should give quick and regular feedback about whether the kanban system is likely to lead to the results.

Lastly the Tactics are equivalent to the Kanban Thinking intervention Search. These are the specific practices, techniques and policies used as part of the experiment that are run. The Kanban Method core practices can also provide guidance as to what tactics can be used to design the kanban system.

While I’m not sure I would want to be overly rigid about defining the strategies, I find the X-Matrix a useful model for exploring, visualising and communicating the elements of a kanban system and how they correlate to each other. As with all tools like this (i.e. A3s) its not the template or the document that is important, its the conversations and thinking that happen that have the value.

[1] I did consider the name “Kanban Kanri” for the alliteration, but apart from preferring to minimise Japanese terminology, it’s probably meaningless nonsense in Japanese!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

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
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

How Do I Know If Agile Is Working?

Moving the queen

Moving the queen, Gabriel Saldana, CC BY-SA

“How do I know if Agile is working?” This is a question I’ve been asked a lot recently in one form or another. If not Agile, its Scrum, or Kanban or SAFe or something similar. My usual response is something along the lines of “How do you know of anything is working?” And there generally isn’t a quick and easy answer to that!

I’ve come to the view that Lean and Agile practices and techniques are simply tactics. They are tactics chosen as part of a strategy to be more Lean and Agile. And becoming more Lean and Agile are seen as important to make necessary breakthroughs in performance in order to deliver desired results.

With that perspective, then the answer to “How do I know if Agile is working?” is that you achieve the desired results. That’s probably a long time to wait to find out, however, as it is a trailing measure. It is necessary, therefore, to identify some intermediate improvements which might indicate the results are achievable, and leading measures can be captured to give hat earlier feedback.

The lack of a quick and easy answer to “How do you know if anything is working?” is often because Lean and Agile have been introduced as a purely tactical initiative, without any thought to how they relates to strategy, what measurable improvements they might bring, and how any strategy and improvements will lead to desirable results. In fact very few people (if any) know exactly what those desirable results are!

I’m increasingly trying to work the other way – what the Lean community call Strategy Deployment. For any transformation to work, everybody in the organisation needs to know what results are being strived for, what the strategic goals are that will enable the necessary changes to get there, and what measurable improvements will indicate progress. Then the whole organisation can be engaged in designing and implementing tactical changes which might lead to improvement. Everything becomes a hypothesis and an experiment, which can be tested, the results shared and adjustments made.

In other words, Strategy Deployment leads to organisations becoming laboratories, where Lean and Agile can inform hypothesis on strategies, improvements and tactics. I think its the secret sauce to any transformation, which is why I’ll be talking about it more at various conferences over the rest of the year.

The first one is Agile Cymru in a couple of weeks. There’s a few tickets left, and considering the line-up of speakers, and the ticket cost, its incredible value. I highly recommend going, and I hope to see you there!

 

VN:F [1.9.22_1171]
Rating: 4.0/5 (2 votes cast)

Understanding SAFe PI Planning with Cynefin

3128266497_077f9144af_z

Within SAFe, PI Planning (or Release Planning) is when all the people on an Agile Release Train (ART), including all team members and anyone else involved in delivering the Program Increment (PI), get together to collaborate on co-creating a plan. The goal is to create confidence around the ability to deliver business benefits and meet business objectives over the coming weeks and months – typically around 3 months or a quarter.

To many people this feels un-agile. Isn’t it creating a big plan up-front and defining work far ahead? However, a recent experience led me to realise why its not about the plan, but the planning and the dynamics of the event itself. In Cynefin terms, PI Planning is a catalyst for transition and movement between domains.

Let me explain.

Before PI Planning, and a move into an ART cadence, many organisations are in Disorder, relying on order and expertise when they should be using experiments and emergence. The scheduling of a PI Planning event triggers a realisation that there is  a lack of alignment, focus or vision. In order to prepare for the event people have to agree on what is important and what the immediate objectives, intentions and needs are. In short, what does the Program Backlog look like, and what Features should be at the top. The conversations and work required to figure are the beginning of a shallow (or sometimes not so shallow!) dive into Chaos.

During PI Planning is when the Chaos reaches a peak, typically at the end of Day One, as it becomes clearly apparent that the nice ordered approach that was anticipated isn’t achievable. More conversations happen, decisions are made about the minimum plausible solution and hypothesis are formulated about what might be possible. This is when action happens as everyone starts to pull together to figure out how they might collectively meet the business objectives and move the situation out of Chaos into Complexity.

After PI Planning there is still uncertainty, and the iteration cadences and synchronisation points guide the movement through that uncertainty. Feedback on the system development, transparency of program status and evolution of the solution are all necessary to understand progress, identify learning and inform ongoing changes. This may require subsequent dips into Chaos again at future PI Planning events, or over time the ART may become more stable as understanding grows, and PI Planning in the initial form may eventually become unnecessary.

It is this triggering of a journey that makes me believe that PI Planning, or equivalent “mid-range” and “big-room” planning events, are a keystone to achieving agility at scale for many organisations. I wonder how this matches other’s experience of successful PI Planning meetings? Let me know with a comment.

VN:F [1.9.22_1171]
Rating: 4.0/5 (2 votes cast)

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.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban Thinking Workshop in London

Kanban-thinking-banner

I have another public Kanban Thinking workshop coming up in London (March 5-6), in collaboration with Agil8, and to fill the last few places, I can offer a discount! Book now, using the code KS25 to get 25% off the standard price, and get 2 days of fun, discover how to design a kanban system by populating a kanban canvas, and learn how to make system interventions which have a positive impact.

To wet your appetite, here’s a couple of photos from a recent workshop. (Click for larger versions).

IMG_1371IMG_1370

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

A Kanban Thinking Pixar Pitch

I’ve been using the Pixar Pitch as a fun way for teams to discuss and explore the problem they are trying to solve by telling a story about what has been happening that led to the need for a kanban system. I thought it might be useful to use the formula to tell a dramatised story of what led me to first try using a kanban approach, and why that led to Kanban Thinking.

The Pixar Pitch

Once upon a time there was a team who were using Scrum to manage their work. They were cross-functional, with a ScrumMaster and Product Owner, developing and supporting a suite of entertainment websites for a global new-media organisation.

Every Sprint they prioritised and planned the next couple of weeks, developed and tested functionality, fixed live issues, released updates when ready, and reviewed and retrospected their work.

And every Sprint the team was unhappy with the way they were working. The Product Owner felt that the developers could be more productive, and the developers felt that the Product Owner could be giving more guidance on what build. Stories were completed, but features took a long time to release as the team thrashed to get the functionality right, meet commitments and increase velocity.

So every Sprint they inspected and adapted. The Spring length was shortened to get quicker feedback. The style of User Stories was adjusted to try and focus more on value. And yet things did’t improve significantly.

One day they decided to stop focussing on doing Scrum, and start using ideas from Kanban, experimenting with some different approaches that they hadn’t previously tried.

Because of that they stopped using Sprints and de-coupled their cadences, reprioritising their ready queue every week, planning only when they had capacity to start new work, releasing and reviewing every fortnight, and retrospecting every month.

And instead of breaking work down into small User Stories that would take less than 2 weeks, they focussed on finishing larger MMFs, which might take months in some cases.

And they paid more attention to their Work in Process, in particular making sure they only worked on one large new feature at a time.

And instead of the Sprint Burndown they tracked their work using a Cumulative Flow Diagram, Parking Lot and Lead Time report.

Because of that the whole team became more focussed on delivering valuable features, were more collaborative in how they figured out what the details of those feature were, and were more reliable in when they delivered them.

Until finally everyone was working well together as a much happier group, delivering much more value, and in a good place to continue to improve.

Kanban Thinking

The point of this story is not to try and make one approach sounds better than another, or to suggest that any approach can be a bad choice in some way. Rather it is that the team learned about what would and wouldn’t work by asking questions about their process and experimenting with all aspects of it. The end result might have ended up being exactly what an expert or consultant might have recommended or coached. That’s OK, because what is important is the understanding that was created about why things are as they are. This capability to solve problems, as opposed to implement solutions, sets a team up to continually evolve and improve as their context changes.

This principle – helping teams to solve problems rather than implement solutions – is what fascinated me about kanban when I first came across it and started exploring how it could be used. Its what ultimately led to the emergence of Kanban Thinking as a model for helping achieve this, and the Kanban Canvas as a practical tool.

VN:F [1.9.22_1171]
Rating: 3.5/5 (2 votes cast)

Looking back on 2014

This is a little later than I would have liked, but 2015 seems to have had a busy start! As I look back on last year, the main thing that stands out for me was my decision to go solo. As a result, the second half of the year was an interesting learning curve for me, and as I look forward to 2015, I’m please with the way events have unfolded, and excited by future possibilities. In particular, I’ve been able to focus more time on Kanban Thinking, including put together the downloadable Kanban Canvas, and writing more about how I use it.

On the topic of writing, you can read the blog’s 2014 annual report for the full statistics. The highlights for me were the fact that I had my busiest day, and I managed 23 posts – a significant increase from 2013. I hope I can maintain, and even continue to improve that number. Also interesting is that the top 3 posts remain the same; Kanban, Flow and Cadence“,What is Cadence? and Fidelity – The Lost Dimension of the Iron Triangle. Its nice to see Running the Ball Flow Game come in at number 4 – I love playing that game in workshops and it always seems to generate good discussion and learning. Finally, Making an Impact with Kanban Thinking is at number 5, and given that this is a recent post, I hope this bodes well for the future of Kanban Thinking in general.

The other big passion of mine in 2014 was taking up running, which I mentioned a when I posted on Estimates as Sensors. According to MapMyRun, I did a total of 177 runs, with an average run of 5.11 miles (giving a total of 904.5 miles), and a longest run of 17 miles. My average pace was 9:06 min/mile and my fastest pace was 4:31 min/mile.

For posterity, here’s my PB’s for the 2014

I’m currently training for the Brighton Marathon (watch this space for a call for sponsorship) so I’m also expecting those number to go up (or down for pace!). As part of my running addiction, I’ve become involve in my local parkrun community – something I gave a lightning talk about at LKUK14.

Thanks you for reading this blog, and for the continued support. I look forward to more of the same in 2015, and hope I get to meet many of you in person. Please let me know if you’d like me to work with you, or just say “Hi” if you see me at a conference or event.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)