Tag: kanban

It’s 10 years since the post that changed my career

Posted on by Mike Burrows

Happy New Year! For me it’s a big anniversary: this time in 2013 I had spent the New Year’s break taking the principles and practices of the Kanban Method, and from them abstracting a system of nine values. Then on January 3rd, I published Introducing Kanban through its values. Kanban’s values model was born.

Nine values are quite a lot to hold in one’s head at once, so I soon learned to present them in groups:

  • An initial six, or two groups of three: transparency, balance, and collaboration, then customer focus, flow, and leadership
  • Then understanding, agreement, and respect, which for reasons of brevity are often subsumed under leadership

In most of the decade since, it has been my most-read post each year. And it led to my first book, Kanban from the Inside (2014), which remains a Lean-Agile classic. Great! Now what?

I had no interest in making Kanban any more technical than it already was; if anything, the values model would always draw me in the opposite direction. Neither was I drawn to the emerging Kanban Maturity Model (or any other such model). What I did instead was to allow a common problem to bother me: why do so many people arrive at the training class not knowing why they are there? Tempting as it might have been to see that as a failure of administration or marketing, I saw it instead as a symptom that there were important organisational conversations that simply weren’t happening.

I realised quickly that this problem was far from unique to Kanban. To those that resent having had Scrum or (later) SAFe thrust upon them, the Agile manifesto’s “People and interactions over processes and tools” must ring rather hollow.

That took me away from Kanban into the realms of organisation, leadership, and strategy, to the development of Agendashift, and then sort of full circle, not back to Kanban and Lean-Agile specifically, but to business agility. Ten years on, as practice gets refined through use, as its message gets refined through the telling, and as we dig ever-deeper roots into the available theory, three main topic areas co-evolve together:

  1. As described now in two editions of the Agendashift book (2nd ed 2021), Agendashift the engagement model (thank you Daniel Mezick for describing Agendashift as such) and dialogic/generative organisation development approach (thank you Gervase Bushe & Bob Marshak), a way for practitioners to approach organisations without prejudging what solutions they will employ(/impose/inflict) and instead to help them have those missing conversations – engaging in participatory strategy, as it turns out
  2. The wholehearted organisation, a deliberately minimalistic values-based model of organisation and leadership, a spinoff from my third book, Right to Left: The digital leader’s guide to Lean and Agile (2019, audiobook 2020) that unexpectedly gained a life of its own
  3. The leadership development curriculum Leading with Outcomes, which compared to Agendashift minimises detail relevant mainly to practitioners, and instead distils some easily-learned patterns, strategies, and organisational models relevant to leaders at all levels, leaders in transforming organisations most especially

Explicitly in both Agendashift and Leading with Outcomes and implicitly in wholehearted, we have doubled down on the eighth value of that initial nine-value model, namely agreement. What if we put agreement on outcomes before solutions? One way or another, I’ve been asking that question for most of the past ten years, and I have no doubt that it will keep me going for a good while yet.

I no longer identify as a Kanban guy. That separation was necessary to what followed, but all these years later I remain proud of the work I did there, of that first book, and of the blog post that started it all. Not that I’m planning on retiring anytime soon, but I have long seen it as marking the beginning of the rest of my career.

[Comment on this post on LinkedIn]

Related:

Agendashift™: Serving the transforming organisation
Links: Home | Subscribe | Events | Media | Contact | Mike
Agendashift  Academy: Leading with Outcomes | Trainer and Facilitator Programmes

We help leaders and engaged team members at every level to gain fluency in the language of outcomes – developing and pursuing strategies together, innovating, learning, and adapting as the organisation renews and transforms itself from the inside.

Upcoming events

With me (Mike Burrows) unless otherwise indicated.

June:

Later:

From “What did you do yesterday?” to something better

Posted on by Mike Burrows

Go for it! If the main purpose of your standup is to make sure that everyone is keeping themselves properly busy, then the questions “What did you do yesterday?” and “What will you do today?” are without doubt the basis of a great meeting format.

But be careful what you wish for. If your goals involve 1) the team meeting needs, and 2) learning from the process, those questions can hurt a lot more than they help. Honestly, I’m not a fan at all.

You could try these instead. Understand the pattern, and with practice, it runs itself:

  1. What are we learning from what we recently completed? And is it staying completed? Whose needs did we meet, and how do we know we met them?
  2. What can we get over the line?
  3. What is and isn’t making the expected progress? Are we clear about whose needs we’re meeting, what needs, how we’ll know, and what’s our approach?
  4. Do we have the capacity to look at what’s next, or is that enough until we next meet?

You probably won’t get to that overnight, so some things to try:

  • Instead of reviewing activities (what you did, what you’re doing, etc), try to focus the things that you as a team are trying to produce, in the context of the goals you’re pursuing
  • All else being equal (in bigger meetings, this pattern can work within other interesting ways to structure the work), try reviewing your work most-complete work first, not forgetting to start with celebrating and enquiring into work recently completed
  • Make a point of noticing how the conversations change as you work backwards, and develop your repertoire accordingly – by this stage you’ll likely be noticing not only a performance difference but a language change and changes to people’s expectations and behaviour, and you can build on that until they become habits
  • In all of the above, try keep in your mind and everyone else’s what you’re working backwards from: “someone’s need met” and “all the available learning fully accounted for” (my definitions of done and really done)

I’ve used this “right to left” technique in a range of settings, often supercharging something that really wasn’t working before – standup meetings, risk & issue review meetings, service delivery review meetings to name just three. Right to left is named after Kanban’s board review pattern (you start on the right-hand side of the board with work at or nearest completion) but it’s not hard to apply in other settings.

And it’s more than just a productivity hack. In my third book Right to Left (2019, audiobook 2020), I take that philosophy of working backwards from impact and learning and use it as a lens on the whole Lean-Agile landscape (and more). Further to it not being just a Kanban thing, the book shows how right to left fits very well with the best of Scrum. Contrast that with an all too prevalent left to right kind of Scrum that does the reputations of Scrum and Agile no favours at all, and that scales up in the worst possible way. Fortunately it’s fixable.

This post started out as a LinkedIn post, then a second:

  1. Go for it! (linkedin.com)
  2. Building on that last one… (linkedin.com)

And now a third:

    Like, comment, share!

    You can also take any questions you may have to one of the upcoming webinars – the first three (December 8th, January 12th, February 2nd) all finish with an AMA (Ask Mike Anything) session. Series link: The questions that drive us (eventbrite.co.uk).

    Related:

    Upcoming:

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Leading with Outcomes | Facilitator and Trainer Programmes
    Links: Subscribe | Events | Contact | Mike

    We help leaders and engaged team members at every level to gain fluency in the language of outcomes – developing and pursuing strategies together, innovating, learning, and adapting as the organisation renews and transforms itself from the inside.

    Agendashift roundup, April 2022

    Posted on by Mike Burrows

    In this earlier-than-usual edition (you’ll see why): Friday is pivot day; Interviewed by Mike Leber; Agendashift as framework, 2022 edition; German translations; Upcoming; Top posts

    Friday is pivot day

    Friday would have been roundup day, but we’re saving that for the next big announcement from the Agendashift Academy. Yes, there’s new content, the expected next module in the Leading with Outcomes curriculum, but the real news is more significant than that, a lot of hard work (and not just by me) coming together in a really exciting way.

    If you’re not already on the mailing list, now would be a good time to subscribe.

    Interviewed by Mike Leber

    I was interviewed recently by Mike Leber – see below for the recording, and see also What I really think about Kanban, highlighting what was just one part of what was a wide-ranging conversation.

    Leading with Outcomes. Breaking free from the Solution-driven Paradigm! (linkedin.com)

    Hot on the heels of that one, Friday or soon after I’ll be making an appearance on the Lean On Agile (& Elevate Change) Show, interviewed by Shahin Sheidaei. I’ve had the chance to listen to the podcast already and look forward to sharing that one too.

    Agendashift as framework, 2022 edition

    As announced earlier in the month I’ve updated agendashift.com/framework to lead with the three strategies:

    If you have access to Agendashift’s Commons or more specifically to Agendashift assets, there’s a new framework overview deck, Agendashift framework overview 16x10 2022-04 v3.pptx. Best viewed full screen and with the Source Sans Pro font installed. If you don’t have it, you can request access via the framework page.

    Why is this important? Well, one important source of struggle for organisations and their leaders is that those 1990’s models of change (models still accepted as “doing it properly”) don’t work for most interesting kinds of business challenges, certainly not the kinds of challenges associated with transformation. As my friend Patrick Hoverstadt puts it:

    If the model doesn’t work more than half the time, the model is wrong – so wrong indeed that it can’t be said to be useful.1

    What if we stopped leading with solutions – solutions that are not only likely to be a poor fit to their intended context, are hard to implement, and meanwhile deny everyone the opportunity to do something better – and started leading with outcomes instead? What if we could hold the right conversations – strategy conversations – at the right time, agreeing on outcomes, organising around outcomes, and steering by them? And not just “rinse and repeat” (glibly assuming that this happens for free) but seeking opportunities to do this at every scale?

    Only after the Why and the What if comes the How – Agendashift’s patterns and tools. I’m learning not to get to those quite so quickly as I used to, and the strategies bridge the What if and the How really nicely 🙂

    1 See Patrick’s new book The Grammar of Systems: From Order to Chaos and Back. From memory, so I’m paraphrasing. Highly recommended.

    German translations

    A quick reminder that all of my books are now available in German:

    I still have a few review copies of the recent Agendashift translation left. If you feel a review coming on, please get in touch!

    Over the coming weeks, some of our translated resources will receive updates.​​

    Upcoming

    Top posts

    1. What I really think about Kanban (April)
    2. Updated: Agendashift as framework, 2022 edition (April)
    3. What I really think about Scrum (August 2020)
    4. Video: Leading and Transforming with Outcomes (March)
    5. What I really think about SAFe (October 2019)

    What if we put agreement on outcomes ahead of solutions?

    Agendashift™: Serving the transforming organisation
    Links: Home | Subscribe |     Become an Agendashift partner | Events | Contact | Mike
    Agendashift  Academy: Home | Store
    Resources: Tools & Materials | Media | Books | Assessments 
    Blog: Monthly roundups | Classic posts
    Community: Slack | LinkedIn group | Twitter

    What I really think about Kanban

    Posted on by Mike Burrows

    Previously on this blog:

    My first book, Kanban from the Inside (2014), remains a top book for Kanban so I really ought to complete that list.

    Earlier this week I was interviewed by Michael Leber. The hour (livestreamed) flew by very quickly and I’m very pleased with how it came out, so thank you very much Mike! If you’re on LinkedIn, this is the better link to the recording:

    Otherwise this one:

    It was a wide-ranging talk but we started with Kanban (the method as well as the tool) and I said a few things about it I haven’t really said before. A couple of key quotes:

    I don’t find that [evolutionary change] principle exciting. I don’t get excited about evolutionary change – it’s like the wrong metaphor for a great tool.

    If you’re serious about it, it has got to be with some intent. If you’re just fixing problems just because you see them, it doesn’t actually meet needs, it doesn’t get you to where you want to get to. And if you’re going to get to where you want to get to, you’ve got to have a conversation about where that is, what that looks like, what direction it’s in. … If you’re serious about the outcomes and their obstacles, serious about where you’re going to focus your efforts, serious about understanding the relationships between outcomes, you’re actually doing strategy.

    To be fair to Kanban (the method), it tries harder than most Agile frameworks to get to that, but it doesn’t really get there, and nor will it so long as a tool (the kanban system and its supporting structure) is the predetermined answer. That’s why I am where I am now, non-aligned framework-wise, developing Agendashift as a way to help organisations and their leaders approach change and transformation strategically. If you want change, learn to have the strategy conversations around it. Don’t start with a solution (an Agile framework, say); start with agreement on outcomes. Done authentically – the right people in the room, the results of the conversation not prejudged – the rest follows so much more easily.

    Leading with Outcomes. Breaking free from the Solution-driven Paradigm! (linkedin.com)

    Finally, some of the links mentioned:

    And my books (all of them now available also in German):

    • Agendashift: Outcome-oriented change and continuous transformation (2nd edition 2021)
    • Right to Left: The digital leader’s guide to Lean and Agile (2019, audiobook 2020)
    • Kanban from the Inside (2014)

    What if we put agreement on outcomes ahead of solutions?

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Leading with Outcomes | Home | Store
    Links: Home | Subscribe | Become an Agendashift partner | Events | Contact | Mike
    Resources: Tools & Materials | Media | Books | Assessments 
    Blog: Monthly roundups | Classic posts
    Community: Slack | LinkedIn group | Twitter

    From Reverse STATIK to a ‘Pathway’ for continuous transformation

    Posted on by Mike Burrows

    It seems that my 2014 post Reinvigorating an existing Kanban implementation with STATIK is now gone. It is very likely the first mention of Reverse STATIK, and fortunately web.archive.org has saved it here, but 5 years on let me take the opportunity to revisit it.

    We start with STATIK, the catchy acronym I coined for David J. Anderson’s Systems Thinking Approach To Introducing Kanban, which is quite a mouthful. STATIK looks like this (or at least it did in 2014):

    1. Understand sources of dissatisfaction
    2. Analyze demand and capability
    3. Model the knowledge discovery process
    4. Discover classes of service
    5. Design kanban systems
    6. Roll out

    You may recognise those steps as the chapters of Part III of my first book Kanban from the Inside (hereafter referred to as KFTI); otherwise it was day 2 of the standard 2-day Kanban training. I don’t do much Kanban training these days (I don’t advertise it and for reasons of strategy rather than any falling out I’m no longer affiliated with the certification body), but when I do, I don’t use STATIK.

    My main issues with STATIK aren’t the individual steps (there’s value in them all), but these:

    1. Even avoiding the middlebrow dismissal of “It’s too linear” (often thrown around rather unfairly), it’s much more likely to be understood and used as a discrete intervention (albeit a participatory one if it’s done the right way), not as a model for a continuous process.
    2. Even if I grant that you could in theory bail out of the process at any stage, it does rather assume that Kanban is the answer, so if we are to avoid the accusation of being solution-driven, something else has to come before it.

    Aside (further to that second point, a bit of detail that doesn’t invalidate it): KFTI describes a step 0, ‘Understand the purpose of the system’, a phrase I borrowed (with full credit) from Goldratt’s Theory of Constraints (TOC). That has morphed into ‘Understand fitness for purpose’ (for the service you are applying STATIK to). This is OK as far as it goes, but the faster it turns (as seems to be its intent) into a conversation about metrics, the less time anyone spends actually exploring purpose. If I’m honest, this part leaves me a little cold, though in the interests of balance, it should be pointed out that Kanban still does far more than any other framework I know to encourage its introduction in ways consistent with its principles. If only the others were as careful; if they were, perhaps Agendashift would never have been so necessary!

    My original idea with Reverse STATIK was to retrace one’s steps, working backwards through the STATIK process looking for improvement opportunities. Today, I see it as more than that, and find it useful in two ways, both of which may seem surprising:

    1. Reverse STATIK turns out to be a great way to introduce/teach Kanban too. You can start with the simplest to-do/doing/done kanban board design (not yet a WIP-limited kanban system) and at each step introduce multiple options for improving not just its detailed design, but much of the surrounding organisation design that makes it work. No longer a one-shot intervention, but a rich model for improvement
    2. You can strip out all the kanban-specific techniques, replace them with their corresponding outcomes (outcomes that might be achieved in myriad other ways), and revise for breadth of coverage. A few iterations later (much of it done in collaboration with Dragan Jojic) we arrived at the genuinely framework-agnostic assessment that in the early days was Agendashift’s most important tool (it’s still important today but there are newer parts that are more exciting).

    Aside: I glossed over one important detail there: In most people’s first experience of the assessment tool, its ‘prompts’ are organised under headings of Transparency, Balance, Leadership, Customer Focus, Flow, and Leadership. These 6 values are the titles of KFTI’s first 6 chapters; moreover Leadership incorporates Understanding, Agreement, and Respect, the so-called ‘leadership disciplines’ of chapters 7, 8, and 9.  I make no apologies for retaining these; most people would recognise these values as having relevance in any Lean-Agile context.

    Fast forward to 2019, Reverse STATIK (mostly under the framework-neutral name of ‘Pathway’) looks like this:

    1. Refine existing systems
    2. Improve the service experience
    3. Manage the knowledge discovery process
    4. Balance demand and capability
    5. Address sources of dissatisfaction and other motivations for change
    6. Pursue fitness for purpose

    These headings appear in my aforementioned teaching materials, as an option in the assessment tool, and the spine of the ‘Pathway map’, a visualisation inspired by User Story Mapping (see chapter 3 of the Agendashift book, which also introduces the Reverse STATIK model).

    Instead of (and I say this tongue-in-cheek) doing a bunch of analysis exercises before (tada!) a kanban system is designed, an improvement process that identifies opportunities at a wide range of challenge and sophistication, with kanban or without. The spine starts small, grows in sophistication, and ends on high with purpose, leadership behaviours, and other similarly challenging, bigger-picture issues of organisation design; what detail gets prioritised under whatever heading at any given time is a matter for participatory decision making.

    Relentless commitments to 1) participation and 2) agreement on outcomes as the basis for change are what took me from Reverse STATIK to Agendashift. The former wasn’t quite the 21st century engagement model I was striving for but a decent first attempt, and it lives on, even if quite well hidden.

    pathway-mappingRelated:

    What if we put agreement on outcomes ahead of solutions?

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Leading with Outcomes | Home | Store
    Links: Home | Subscribe | Become an Agendashift partner | Events | Contact | Mike
    Resources: Tools & Materials | Media | Books | Assessments
    Blog: Monthly roundups | Classic posts
    Community: Slack | LinkedIn group | Twitter

    0

    A question among the good luck emails

    Posted on by Mike Burrows

    There’s a contact button on the landing page for Right to Left, and through it I got this question which I have permission to reproduce:

    Keep up the good work, and btw how do you use the Kanban Method these days, after your current progression?

    My reply (verbatim):

    In Right to Left you’ll see Kanban as just one of a set of complementary patterns in the Lean-Agile space (none of them more important than the others), and a more general approach to organisation development and the leadership that goes with that.

    In my own work, Kanban is still in the mix but I’m very definitely needs & outcomes first, not solutions/framework first. STATIK tries to do a bit of that* but it does rather presuppose the answer! I prefer Reverse STATIK anyway, and my very occasional Kanban training uses that. The principles and practices are abstracted in the values, and they live on through the Agendashift delivery assessment (a conversation-starter, not a checklist of practices).

    *To be fair, it does this quite valiantly and self-consistently compared with peer frameworks, but my comment stands.

    And a PS, sent moments later:

    One thing to add: this is not to diminish anyone’s work on Kanban (my own included) or any other framework. Testing boundaries is learning. But it’s also healthy to draw back a bit and broaden one’s horizons from time to time. And integration is also learning.

    Some links to help with decoding the above (I knew my correspondent to be familiar with most of them):

    Autumn workshops
    – Stockholm, Athens, London, Istanbul, Berlin, and online

    Leading change in the 21st century? You need a 21st century engagement model:

    Blog: Monthly roundups | Classic posts
    Links: Home | Partners | Books |Resources | Events | Contact | Mike
    Community: Slack | LinkedIn group | Twitter

    0

    A Grand Unification Theory for Lean-Agile?

    Posted on by Mike Burrows

    The job of chapter 3 of the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile is to introduce a number of important Agile, Lean-Agile, and associated frameworks. I have taken care to describe them not as alternative solutions that must be chosen between, but as patterns to be combined in interesting ways. That’s not a new idea, but what does seem remarkable is how helpful a right-to-left perspective is in explaining how they work together and complement each other. When I say right-to-left, we’re talking not just collaborative, continuous, pull-based, and so on (concepts conventionally associated with Lean-Agile) but something very explicitly outcome-oriented.

    Almost verbatim from the manuscript:

    1. Scrum (and Scrum-based scaling frameworks, if that’s your bag): continuously iterating on and self-organising around goals (short term outcomes) in the pursuit of longer term outcomes – product vision, the team’s mission, broader organisational objectives, and so on
    2. Kanban, making progress on outcomes visible, concentrating effort on the ones that matter most, fostering a focus on completion
    3. XP and DevOps, right across development and production, providing the infrastructure of process, practice, and technology necessary to accelerate feedback on the delivery of outcomes
    4. Service Design Thinking (along with user research, user experience and so on), continuously discovering which outcomes are important
    5. Lean Startup, pursuing business viability through continuous deliberate experimentation, managing for impact (outcomes again), finding and continuously refining a business model that enables customer outcomes to be sustained

    Here it really is outcomes that holds everything together, not (as you might expect) flow, collaboration, or some other shared value or technical principle. This way, we avoid saying “if you dig deep enough, they’re the same” (which I hear from time to time and strongly reject, believing that it does each framework’s creators and communities a huge disservice).

    Neither are we saying “don’t use frameworks”, if (and it’s quite a big if) this means that you must always start from first principles. A sensible way to start is again outcome-oriented and has a measured and pragmatic attitude towards frameworks (quoting this time from chapter 4, Viable scaling):

    • Identify needs – looking at what kind of organisation you’re trying to be and at what you’re trying to achieve  – and the obstacles that currently prevent those needs from being met
    • Agree on outcomes, not just goals plucked out of the air, but the kind of outcomes that might be achieved when these obstacles are removed, overcome, or bypassed
    • On a just-in-time basis, prioritise outcomes and generate a range of options to realise them, using your favourite frameworks as sources of ideas (not excluding other sources, but valuing coherence nevertheless)
    • In manageably small chunks of change and through a combination of direct action and experimentation (choosing between those approaches on a case-by-case basis according to the level of uncertainty and risk involved), begin to treat change as real work: tracking it, validating its impact, and reflecting on it just as we would for product work

    In a nutshell, I’ve described Agendashift, which is of course a right-to-left approach to change and transformation. Other engagement models exist – see OpenSpace Agility (OSA) for another excellent, well-documented, and highly complementary example. Whichever approach you choose, take care to choose one that models Lean and Agile values, lest the dissonance proves too great and you fatally undermine your work, a very real risk. To sow disengagement would be a truly bad outcome!

    Related:

    Subscribe here for monthly roundups and very occasional mid-month announcements

    Upcoming public Agendashift workshops (India*2, US*2, UK, Netherlands):

    Also: Channel #agendashift-studio in the Agendashift Slack if interested in a cozy workshop with me at Agendashift HQ (Derbyshire, England).

    Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
    Links: Home | About | Partners | Resources | Contact | Mike
    Community: Slack | LinkedIn group | Twitter

    We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

     

    0

    Scrum and Kanban revisited

    Posted on by Mike Burrows

    Update: See the August 30th webinar by Steve Porter and Dan Vacanti titled Scrum and Kanban: Make your teams better by busting common myths [scrum.org]. It’s great to see such a collaboration happening, and I’m happy to acknowledge that they are the original source of the six numbered headings below (not the content – that’s still mine). Apologies to Steve and Dan – honest mistake, I should have dug a little deeper.

    Late last week I was invited by Fasih Sandhu to contribute my reactions to a LinkedIn post on the topic of Scrum and Kanban. My initial reaction was “Oh, here we go, 2012 just called”, but I ended up leaving a comment big enough that I had to edit it down for it to fit. Here then is the director’s cut! I don’t for a moment suppose it will resolve the issues once and for all, but it does at least give an opportunity to explain how someone committed to thoughtful integration approaches it.

    Do you think that combining the #Kanban principles and practices with the #Scrum Framework will enhance the collaboration across your agile teams?

    Space did not permit me to address this question on LinkedIn, but had it not contained the phrase “enhance the collaboration across your agile teams” I would likely have not have engaged at all.

    To understand why this phrase was so crucial, here’s the Agendashift True North [1]:

    Everyone able to work consistently at their best:
     • Individuals, teams, between teams, across the organisation
     • Right conversations, right people, best possible moment
     • Needs anticipated, met at just the right time

    I’m interested in enhancing collaboration not just across agile teams (as per the question), but between teams (of all kinds) and across the organisation – the right conversations happening between the right people at the best possible moment, wherever in the organisation or outside of it they happen to reside.  Do I believe that a combination of Scrum and Kanban can help to deliver this? Yes I do, and I can point to multiple projects where I’ve witnessed it happen.

    In a week or so, I will be attending an event on #Scrum versus #Kanban and I am interested to the reaction of my LinkedIn followers to any of the following statements that will be discussed in that event:

    1) Scrum is for product teams; Kanban is for service teams
    2) Scrum is for complex work; Kanban is for simple work
    3) Our Scrum team has evolved to become a Kanban team
    4) We do Scrumban
    5) We do Kanban because we can’t plan out for an entire Sprint
    6) Scrum is revolutionary; Kanban is evolutionary

    Oh dear. “Scrum versus Kanban”. 2012 really is calling. Moving on:

    1) Scrum is for product teams; Kanban is for service teams

    Quick gut reaction: Ugh. Propaganda (at best based on an error of logic, more bluntly a lie based on a misdirection).

    Longer answer, explaining the above but leading to a much less controversial conclusion:

    Yes, Scrum is, by design, for product teams. Scrum.org describes it as “a management and control process that cuts through complexity to focus on building products that meet business needs”. No argument there, and in that context it is well understood and well resourced. For some it’s the framework of choice, for others it’s a good starting point or something you have to know.

    Is Scrum designed for service teams? Not really. Can Kanban help there? In other words, can service teams benefit from Kanban’s visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc? Many can and many do!

    What is also true (and it’s what makes this statement so frustrating) is that visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc are also highly useful to product teams, whether or not they are using Scrum.

    So… Kanban is not only for service teams, and Scrum and Kanban are not mutually exclusive. Boring, but true! And can your product teams afford to ignore the service dimension anyway? Probably not, and some would even start there…

    2) Scrum is for complex work; Kanban is for simple work

    Quick gut reaction: Double ugh. Like question 1, but with a dose of Appeal to authority thrown in.

    I could give an extended answer here, but suffice it to say that if you don’t understand that Scrum and Kanban both seek – in their quite different ways, both technically and philosophically – to help their organisations (not just their products) evolve in the presence of internal friction and external competitive pressure, then you don’t understand them, Agile, Lean, or Lean-Agile very well at all.

    3) Our Scrum team has evolved to become a Kanban team

    Positive, negative, and mixed reactions might be appropriate here – it’s hard to comment on this one without knowing the specifics of the scenario.

    Unfortunately a statement like this could mean a whole range of things, ranging from “We stopped doing a bunch of Scrum-related stuff and we don’t really know what we’re doing” to “We’re now using a number of new techniques in a the pursuit of flow, leaving some older practices behind once we established that it was safe and effective to do so”.

    Minor technicality: By the design of both, ‘Kanban team’ isn’t as well defined as ‘Scrum team’, but I can see how this arises.

    4) We do Scrumban

    As documented [2, 3, and elsewhere], my personal experience of Scrumban has been very positive.

    To celebrate the Scrum part, the teams I worked with very much appreciated the focus of the sprint in the early days of each project; for organisations unused to achieving anything quickly, the experience can be amazing!

    As to the Kanban part, this helped immensely in the pursuit of end-to-end flow (see my answer to question 3 above). This isn’t just better task management, this is integrating a process that starts well before development and finishes long after delivery into production.

    I’m glad to be able to say that Scrumban is better resourced now than previously; see for example the book [4] by my friend Ajay Reddy and (from the same stable) some tools [5, 6].

    5) We do Kanban because we can’t plan out for an entire Sprint

    Quick gut reaction: I find it hard to see this as anything other than a feeble cop out.

    Every team is subject to sources of unpredictability – in fact most teams seem to generate a fair amount of the stuff themselves! And yet there’s so much that remains under your control:

    • How often you plan is up to you (clue: choose an appropriate sprint size)
    • Whether or not you plan with zero wiggle room is up to you (clue: don’t)
    • The confidence you attach to your plans is up to you (clue: understand that this is crucial to the planning process, and that your choices here should be informed by both capability and need)

    6) Scrum is revolutionary; Kanban is evolutionary

    Quick gut reaction: Some truth there, exaggerated for effect, not on its own a useful value judgement.

    Scrum is revolutionary if you’ve done nothing like it before. Over time and as there is more of it about, it will become less and less revolutionary, (a victim of its own success perhaps). And don’t forget that it has evolutionary goals (see question 2 above).

    Kanban is often described as the easier of the two to introduce, but try introducing it in an organisation allergic to transparency!

    Frankly though, discussions about what does or doesn’t constitute evolutionary change quickly get very dry, and in any case I don’t believe that this is a sensible basis for serious decisions about tool integration (and like it or not, every successful Agile adoption is an integration, not just a selection). Nowadays therefore, I prefer to take a more principles-based approach: Start with needs, Agree on outcomes, and so on [7, 8].

    References

    [1] A True North for Lean-Agile? (See also chapters 1 and 5 of [2])
    [2] Agendashift: clean conversations, coherent collaboration, continuous transformation, Mike Burrows (yours truly) (2017, Leanpub)
    [3] Kanban from the Inside (2014, Blue Hole Press)
    [4] The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, Ajay Reddy (2015, Addison-Wesley Professional)
    [5] GetScrumban
    [6] ScrumDo
    [7] Agendashift in 5 principles
    [8] (Non-)Prescription, frameworks, and expertise

    What if we put agreement on outcomes ahead of solutions?

    Agendashift™: Serving the transforming organisation
    Agendashift  Academy: Leading with Outcomes | Home | Store
    Links: Home | Subscribe | Become an Agendashift partner | Events | Contact | Mike
    Resources: Tools & Materials | Media | Books | Assessments
    Blog: Monthly roundups | Classic posts
    Community: Slack | LinkedIn group | Twitter

    13

    Anticipating needs ahead of time

    Posted on by Mike Burrows

    [Originally posted on positiveincline.com September 24 2013, restored to blog.agendashift.com February 13, 2018. Except for the first one, links are to web.archive.org.]

    Last week’s post Stand up meeting, thinking tool, leadership routine included this line:

    In what ways do the activities of this stage help us anticipate what will be needed?

    “Anticipate” and “will”: two very future-focused words.

    That emphasis on the future is captured very nicely in the closing words of the Toyota Customer Promise that I found displayed on a plaque behind the customer service desk at my local Toyota dealership:

    …anticipating the mobility needs of people and society ahead of time

    Think of a service on which you personally rely. Wouldn’t you be delighted if they anticipated your needs ahead of time? What process innovations would be needed in order for that to happen? How could that thinking be translated into your workplace, and how would it then be sustained?

    These are important questions. They’re questions of customer focus, of flow, and of leadership, the three direction values. They’re important because an organisation that works on its capability to anticipate and meet future needs is a fitter organisation, and it’s the fittest that thrive.

    There’s more where this came from! My book is going to be a while, but in the next few weeks you can hear me speak on Kanban’s values at:

    Unfortunately I must report the postponement of the UKSMA annual conference at which I was to give the keynote. I’ll mention it here when it has been rearranged.

    0

    Stand up meeting, thinking tool, leadership routine

    Posted on by Mike Burrows

    [Originally posted on positiveincline.com September 16 2013, restored to blog.agendashift.com February 13, 2018. Links are to web.archive.org.]

    My last post was on the provocative side; to restore this blog’s usual balance, here are some antidotes to some of the problems I described. These are ways to use your kanban board to help you look at your process from the perspectives of customer focus and flow, two values from that middle direction layer [2018: the other one being leadership].

    Imagine you’re facilitating a stand-up meeting in front of your board. If you have a physical board, you’re probably heading (in your mind at least) towards the board’s right hand side so that you can stand looking left across the board. If you use an electronic kanban tool, you can achieve a similar effect by turning your laptop or monitor monitor to the left a bit (ok, I’m kidding).

    Now scan the board from right to left (in other words working your way backwards from the end of your process towards the start) and ask these questions of the columns:

    Customer focus

    • Whose needs are explored in this stage of the process, and how? Whose aren’t, and what risks does that pose?
    • What do we learn in this stage that we don’t (or can’t) know earlier? In what ways do the activities of this stage help us anticipate what will be needed?
    • What is still to be learned? Are outstanding uncertainties best dealt with by pressing on or by going back?

    Flow

    • How do work items leave this stage in the process? By what criteria do we know that they’re ready? How are those criteria expressed? How is the state change communicated?
    • Typically, how much time do work items spend in this stage? How much (if any) of that time is spent in active work?
    • What are the most significant sources of unpredictability? In the work in or the waiting? Waiting for internal availability or for external dependencies to be resolved?
    • How much of this stage’s capacity is absorbed in rework? Or in failure demand, which arrives only because previous work failed to meet customer needs adequately?
    • How do work items arrive into this stage? How do we know that they’re ready to be worked on?

    You may find it helpful to ask some of these questions of individual work items too.

    What we’ve done is to turn a popular protocol for standup meetings into a thinking tool. You can try it with other values, for example transparency (is it sufficiently clear what’s going on here?) or balance (are we overburdened here?), or some other concern that seems relevant.

    Caution: questions like these already assume the following:

    1. That the process has sensible objectives (to deliver the right kind of things)
    2. That the work flow is scoped sensibly (starts with the right kind of questions, finishes with the right kind of result)
    3. That the work flow is organized sensibly (sequenced to generate high value learning as quickly as possible)

    I’ve encountered plenty of processes where these assumptions are open to challenge. For example:

    • A change management process whose objective was the approval or rejection of design changes, disconnected from any actual implementation process. Needless to say, any customer satisfaction delivered out of that process was somewhat short lived.
    • My bank’s account opening process. A frustrating process and several weeks later and I still don’t have online banking, let alone two additional products that I would be willing to pay for. I sense an institutionalised lack of curiosity into my needs and what might be in the way of delivering on them.

    Some acknowledgements are in order:

    • The first set of questions questions are heavily influenced by Michael Kennedy and the model of the Knowledge Discovery Process. That’s a Lean product development model, but I find that many processes are usefully understood in those terms.
    • The “whose needs?” questions (the first bullet) point to the very important question: “who holds a veto on delivery?”. This is one of many good customer focus takeaways from Lean Software Strategies by Peter Middleton and my friend Jim Sutton.
    • The idea of understanding a process by walking through it backwards is an old Lean trick. I don’t know for sure how it was discovered and popularised, but Steven Spear describes very well its use as a leadership routine inside Toyota in his book The High-Velocity Edge.
    • Failure Demand is a concept I associate (in the nicest possible way) with John Seddon.

    These are all great ideas. Combining them with visual management and practised routine makes them (as well as the values) accessible and actionable, don’t you think?

    0