Tag: scrum

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.

    What I really think about Scrum

    Posted on by Mike Burrows

    [Comments on this post on LinkedIn]

    Let’s look at Scrum through the lens of last week’s inverse square law of framework scaling, its power as a framework being the product of:

    1. The incisiveness of its point of view – its core paradigms, principles, values, and so on
    2. The ease with which its key patterns combine – both with each other and with those from outside the framework

    Being small, Scrum should do well on both counts; I’ll take them in reverse before returning to how it scales.

    The ease with which its key patterns combine

    Scrum scores really well here.

    Look at Scrum merely as composition of smaller patterns (dangerous, but bear with me just for a moment) and you have to give it significant credit for normalising the practices of daily standup meetings, small-scale planning meetings, retrospectives and so on. Not for everyone an unalloyed good (“too many meetings” is an easy complaint to make if for whatever reason it’s not working), but certainly a mark of Scrum’s success.

    And it gets better: Scrum as a whole is small enough that it combines easily with other things. Scrum+XP has been a thing for a long time. I’ve worked with Scrum and Lean Startup in combination (in the government sector, no less). Scrum+Kanban (Scrumban) isn’t just one thing, but several; in Right to Left I describe four common combinations and elsewhere I have counted more (it’s not hard: just consider the different ways in which their respective scopes might or might not overlap).

    The incisiveness of its point of view

    Here’s where it gets awkward. Scrum isn’t one thing, but two:

    1. Left-to-Right Scrum: the team working its way through a backlog that is determined for it, mostly in advance
    2. Right-to-Left Scrum: the team iterating goal by goal in the direction of its overall objectives

    Left-to-Right Scrum is a process that’s mediocre (or worse) to experience, and doomed to deliver mediocre results at best. And it’s easy to see how it happens:

    • Little room in the project for learning about the customer’s real needs or for exploring different ways of meeting them
    • Thinking that the job of Sprint planning is to fill the Sprint to the maximum, a misconception amplified by story points and velocity (the problem not being that they’re nonsense metrics that cause otherwise intelligent people to bestow mystical properties on Fibonacci numbers, but that they reinforce a dysfunction)
    • Reviews not of what’s being learned about the team’s customers, its product, and the team itself, but of progress against the plan
    • Retrospectives that lack the authority to address strategic issues, and that fail to follow through even on the issues over which it does have influence

    I’m convinced that Scrum would be considerably less prone to these failure modes if only it would maintain a clearer point of view. Scrum’s tragedy is that it’s presented as a backlog-driven process so often that its core paradigm as an iterative, outcome-oriented process gets lost in the noise. And from that failure, disengagement. All that hating on Agile? You don’t need to look far for causes.

    Scaling it up

    For the most part, disappointingly predictable and predictably disappointing:

    • Take Scrum and layer on hierarchies of organisation structure &/or work breakdown structure
    • Plug it into a project/programme structure that almost inevitably works in left-to-right terms and is given no reason to think otherwise
    • Compounding it all, the rollout project – failure after failure, but still we do it!

    Again, the tragedy is that it doesn’t have to be that way. Instead of layering on so much process that you disconnect teams from strategy and organisation development, invite them in! Instead of losing faith with self-organisation, invest in it! Instead of solution-driven imposition, outcome-oriented engagement! Honestly, it’s not that hard.

    We’re in the business of building wholehearted organisations. Need help reorienting your Scrum implementation so that it can work as it’s meant to? Want to put authentic engagement at the heart of your transformation? Get in touch – we’d love to help!

    Further reading:

    cover right to left audiobook.001

    My thanks to Teddy Zetterlund and Steve Williams for feedback on this post, and to Agendashift’s Friday #community Zoom group (details in Slack) for the conversations that preceded it.

    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

    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

    ‘Right to Left’ works for Scrum too

    Posted on by Mike Burrows

    Update: See the landing page for the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile (published summer 2019, audiobook 2020)

    Here’s a conventional, left-to-right [1] description of Scrum:

    A Product Backlog (all the stuff we’d like to do), a Sprint Backlog (the stuff we plan to do this sprint), then a Sprint (a timebox) that culminates in a potentially shippable increment, a review, and a retrospective. Rinse and repeat.

    To me, this is how NOT to describe Scrum. Is it a straw man, put up just so that I can knock it down? Hardly! Not all descriptions of Scrum follow this narrative, but it’s common enough. Complete with a video, here’s a nicely-produced example from a reliable source, the Scrum Alliance: Learn about Scrum (web.archive.org). It’s one of the first pages returned by Google in response to the question “What is Scrum?”.

    The bullet points below are the first few from that page’s 30-second summary, and they’re very close to the commentary on the video:

    • A product owner creates a prioritized wish list called a product backlog.
    • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
    • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
    • Along the way, the ScrumMaster keeps the team focused on its goal.

    If you wanted to describe Waterscrumfall, would you describe it any differently? Perhaps “the team is arm-twisted into pulling an implausibly large amount of work into the sprint (or the project manager helpfully does it for them)”, but little else changes.  Would it help if the process description were prefaced with mentions of agility, complexity, and so on? That must depend on the reader’s frame of reference; if they don’t share our understanding of those words, they’re just noise.

    Let’s try a right-to-left description, Scrum as a pattern of iterated self-organisation around goals:

    A Scrum Team moves towards its Product Vision goal by goal, the team collaborating around a shared goal for a timeboxed interval called the Sprint, at the end of which the team reflects on how well the Sprint Goal was achieved before it prepares for the next one, organising around a new goal. The team’s best understanding of the work required to achieve the Sprint Goal is represented by a Sprint Backlog; options for future sprints are maintained in a Product Backlog.

    The same process, yet so different, and with much less room for misinterpretation. This – I think – is much more like the Scrum that people love. Do you agree? Would you describe it differently?

    Thanks to Steve Porter and Thorbjørn Sigberg for their feedback on earlier drafts of this post.

    [1] Understanding Lean-Agile, right to left

    Suppose you had to understand Lego – and I mean really understand it. Where do you start? With children playing, or with plastic feedstock?

    Source: pixabay.com/en/plastic-polymer-granules-1061731/
    Source: http://www.flickr.com/photos/aukirk/8171237624

    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

    How I read the Scrum Guide

    Posted on by Mike Burrows

    Overview:

    1. The good: Things the Scrum Guide™ reinforces that would otherwise get lost
    2. The ugly: Things that should not be accepted at face value
    3. How I approach it

    I’m going to assume that you have at least a passing acquaintance with Scrum, either as it’s generally taught and discussed, or as defined in the Scrum Guide. The guide itself has been updated in the past few days, there now being a 2017 edition:

    The guide is ©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/.

    I haven’t checked to see when this license model was applied, but nice move.

    1. The good: Things the Scrum Guide reinforces that can easily get lost

    My biggest “Aha!” moment for Scrum was when I realised that it wasn’t about story points, velocity, Fibonacci numbers, and the like. Although tools like these do seem to work effectively enough for some people, others find them a recipe for (i) busywork or (ii) setting teams up for regular disappointment. Small wonder that they’re a popular target for sniping. Rightly, there is no mention of them at all in the guide.

    The guide instead talks of the sprint backlog as both a set of items selected for the sprint, and – crucially – a plan for delivering them. And get this: the sprint backlog is subordinate to something else, the sprint goal:

    As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

    Imagine you’re working in an organisation that typically takes months or even years to deliver anything of note (I exaggerate not). Now give people the chance to work together on achieving a meaningful goal in a matter of days. And again. And again. That’s powerful. Could that be done without Scrum? Does it happen without Scrum? Of course it could and of course it does, but Scrum is often the vehicle by which people experience this for the first time, and that’s something to celebrate.

    I also have to give credit to Ken and Jeff for being explicit about Scrum’s applicability:

    Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

    I don’t highlight this quote as some kind of backhanded compliment, a way to put Scrum back into its box. The domain described here is huge! And it’s important for reasons explored in chapter 5 of the Agendashift book. To operate a Lean, Agile, or Lean-Agile process worthy of that name, you must embrace the idea that the often challenging, sometimes messy, and always necessary work of helping the organisation to change must be treated as real work, to be carried out not just alongside delivery work, but integral to it. The ‘complex adaptive’ part of that quote might be unnecessarily jargony but it refers to the inability of any linear plan to deliver this vital kind of change effectively (see my “Change in the 21st century” keynote).

    Taking these together, Scrum working well means:

    1. Meaningful goals regularly met
    2. The system – the team and well beyond – evolving commensurately

    That’s harder to achieve and even harder to sustain than it might sound, and the guide is honest about the level of challenge involved. What it leaves unsaid is that as soon as Scrum comes to mean ploughing through the backlog, these benefits become increasingly difficult to sustain. It’s why we find support in complementary tools such as Kanban, Lean Startup, and now Agendashift [1] when the returns from Scrum on its own begin to diminish.

    2. The ugly: Things that should not be accepted at face value

    The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

    The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

    There are so many better ways in which the Scrum Master role could have been introduced, and it beggars belief that this section could be edited (yet again) in the 2017 edition and left like this. After an ugly paragraph easily construed as ‘your first responsibility is towards Scrum’ we see a very carefully circumscribed kind of servant-leadership that will surely be read in the light of what precedes it. There are more charitable interpretations, but they depend on assumptions that aren’t made explicit.

    To be a true servant leader, your responsibility is towards your colleagues, your organisation, your customers, other stakeholders, even towards society. Where by-the-book Scrum helps you in those responsibilities, fantastic. Where it gets in the way, it might be time to do something not by the book. A true master at Scrum might find these situations rare, but pity the conflicted rookie! Even if only in the context of these sentences, if it doesn’t bother you that Scrum Masters are certified after just a couple of days of training, it should.

    If we want our industry to do better, we have to look at its systems, ready to challenge a status quo that tends to preserve itself. Scrum has been around long enough to qualify for that kind of scrutiny and whatever their true intent, these widely-read sentences are too open to a cynical, self-serving interpretation.

    In response to my tweet yesterday morning, Neil Killick was quick with this much better alternative:

    With all due respect to Neil, that wasn’t so hard, was it?

    3. How I approach it

    I start from the perspective that Scrum describes some pragmatic solutions to common problems. Do you have multiple customers, far removed from the team? Then you’ll find it helpful to have a highly available Product Owner. Do you need someone to model and facilitate appropriate practices and behaviors? Then bring in a Scrum Master. Are your feedback loops too slow relative to the rate of environmental change? Then plan your work to fill short timeboxes and meet daily.

    Conversely, if you don’t have all of these problems, you might not need Scrum. At the very least, tread carefully:

    • Don’t place obstacles between a team and its customers if they’re already collaborating (yay, manifesto values!)
    • Don’t add layers of process and ceremony where teams are already self organising effectively
    • Don’t allow Scrum’s timeboxes get in the way of rapid flow and rapid change – they needn’t [2], which is why I don’t present this as a technical objection to Scrum

    Nice problems to have, you might argue. And well you might, which why I am significantly more pro Scrum than anti. But I don’t check in my experience, knowledge, or curiosity at the door. Where I see conflict between approaches, I dig deeper, fully expect to find agreement, and am usually rewarded handsomely.

    For the most part, you can leave the self-serving stuff behind (I’ve learned to filter it out). If you are helping to bring clarity and agreement around purpose and goals (things Agendashift and the guide fully agree on), and if you start with needs, seek agreement on outcomes, and so on [3], it’s likely that you’re approaching things in a good way. As time passes you might find that things look less and less like anything you heard in class, but don’t let anyone shame you for that. Expert or rookie (and yes, tread accordingly), you’re responsible. You’re a leader!

    [1] About Agendashift
    [2] Scrum and Kanban revisited
    [3] Agendashift in 5 principles

    I’m grateful to Olivier My, Neil Killick, Johan Nordin, and Karen Beck for their valuable feedback on earlier drafts of this post.

    While we here

    Lean-Agile Strategy Days London (II) – 22-23 Nov, London, UK is just over a week away and there’s still time to book your place. Interested in Lean-Agile change and its relationship to strategy? You should be there! In case you can’t make both days, we’ve just added a strictly limited number of single day tickets.

    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