Scrum and Kanban revisited

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


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

(Non-)Prescription, frameworks, and expertise

Let’s look again at Agendashift in 5 principles, 5 principles for organisational adaptability and 21st century change leadership:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. Organise for clarity, speed, and mutual accountability

Alongside those principles let’s consider also Agendashift’s description as “inclusive, non-prescriptive, and methodology-neutral”. Taking all of that together, what place is there here for skills and expertise in methods, frameworks, and so on? As it happens, quite a lot. It might seem counter-intuitive, but non-prescriptive is an excellent stance for the serious change agent to take.

Just one of the several cool things about starting with needs and outcomes instead of requirements and (pre-selected) solutions is that you give yourself the opportunity to generate and evaluate options (part of principle 4). That’s an interesting process in itself, and here are some of the ways in which a skilled facilitator can encourage diversity and innovation:

  • For every option that involves implementing a tool, we try to think of one that doesn’t (eg to “Implement Slack” we might add the alternative “Get out more”)
  • For every option that involves someone outside our circle providing more accurate inputs, we try to think of one where we we take the responsibility for better and timelier conversations (eg to “Better requirements documents” we might add the alternative “Spend time with customers”)

And some questions:

  • “What has worked elsewhere?”
  • “What would experts from different backgrounds recommend?”
  • “What’s the most radical option we could try?”

To people and teams already familiar with a framework (Scrum, for example), it makes total sense to try things that have worked for similar teams, so long as there’s a decent chance that it will help you achieve the outcome you’re currently focused on. For non-trivial problems, it also makes a lot of sense to understand how other people have solved similar problems outside your framework. For all but the most unusual problems, an expert worthy of that title will have ready access to a range of options and will be able to provide insight into when and why some options work better than others under different conditions.

Industry experience and framework expertise come into their own again with principle 5, organising for clarity, speed, and mutual accountability. Many frameworks have their own answers (technical answers, at least) to how communication and decision-making should work, but only a fool would pretend that it won’t be a challenge to change how organisations operate, especially at scale. Without a good understanding of i) what’s possible and ii) how to help make it happen, you’re stuffed.

The majority of Agendashift partners have deep expertise in at least one Lean-Agile method or framework and a working knowledge of others. No less valuable are the remaining partners that come from the organisation, facilitation, and change side as employees or external consultants, who are used to working respectfully with the technical experts (and vice versa).

If this inclusive (“it’s all great”), non-prescriptive, methodology-neutral thing sounds attractive to you, give Agendashift a closer look. Check out our partner directory, either to find some local expertise or to help you decide that you’d belong there yourself. If you’re a practitioner, check out the partner programme. If a potential sponsor, the unbenchmarking service and the transformation mapping workshop will give you a flavour of the services we and our partners can offer. And for depth, there’s the book: Agendashift: clean conversations, coherent collaboration, continuous transformation.


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

Agendashift in 5 principles

Screenshot 2017-07-25 16.31.36

If you see from me a list of five things, chances are that it maps forwards or backwards* to Discovery, Exploration, Mapping, Elaboration, Operation, the five sessions of an Agendashift workshop and the five chapters of part I of the new book.

Here then is Agendashift in 5 principles:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. Organise for clarity, speed, and mutual accountability

You can read these as 5 principles of 21st century change leadership or 5 principles for organisational adaptability.

1. Start with needs

If you don’t know what the user needs are, you won’t build the right thing [gov.uk]

It’s no secret that I’m an admirer of the UK Government Digital Services’ focus on needs. At GDS, “Start with needs – user needs not government needs” isn’t just spin, but a statement of strategic intent. I can tell you from firsthand experience that if your UK government digital service fails to demonstrate a serious ongoing commitment to exploring and meeting needs, you can expect trouble!

Whether it’s change to products and services or to organisation and process, if your idea of driving change consists of handing down requirements from your ivory tower, you don’t get the needs thing at all. Face it though: you can satisfy a long list of requirements and still not meet needs. (See also: Better user stories start with authentic situations of need).

Neither do you get it if you think it’s ok for your improvement efforts are mostly inward-looking, attending mainly to your team’s efficiency and comfort. If you don’t take time to understand the needs of people outside your four walls, how do you know that you are improving in any meaningful sense?

2. Agree on outcomes

You’d be forgiven for thinking that 20th century change management was all about overcoming resistance to change: trying to convince people, and when all attempts at persuasion have failed, going ahead anyway.

Whether or not that’s fair (certainly there’s truth in it), I believe that 21st century change management is different. Just as we put needs ahead of requirements, we put outcomes ahead of solutions. Agreement on outcomes is gold; once you have that, it’s just a question of how those outcomes will be achieved, the kind of problem that motivates people (not everyone perhaps, but enough people if the outcome is sufficiently meaningful).

3. Keep the agenda for change visible

Agreeing on outcomes and then forgetting them would be quite a waste of effort! To quote the last chapter of my first book (published in 2014):

Shaping the agenda … with the explicit aim of producing a compelling set of agreed upon priorities, goals, and actions

Little did I know it at the time, but chapter 23 of Kanban from the Inside would be the springboard for Agendashift – you can even see where the name came from! Ever since, I have been motivated to help organisations produce their own compelling agendas for change, agendas that whilst remaining true to the Start with what you do now principle still manage to convey a sense of challenge and ambition. You see that sense of challenge and ambition in my proposal A True North for Lean-Agile?, my distillation of what we strive towards.

4. Manage options, testing assumptions

Representing a real alternative to prescription, Agendashift is generative twice over (generative squared?). It contains repeatable and transferable tools first to generate outcomes, and then to generate options for their realisation.

We’ve adopted Lean Startup language for framing options as hypotheses, we take an initial look at assumptions when deciding on which options to select, reject, or hold, and we use an A3-based tool to develop this thinking further. At all three levels of detail we’re bringing assumptions to the surface and devising experiments by which they can be tested. Relentless validation becomes the engine of change; we learn and adapt quickly because we have both the courage and the humility to be wrong.

5. Organise for clarity, speed, and mutual accountability

… it reads like a list on how to align to purpose

Exactly! That was Damian Crawford commenting in the Agendashift Slack on alternative wordings to #5, endorsing this one.

We’re talking transparency, leadership, autonomy, alignment mechanisms, knowledge discovery processes, feedback loops, and so on. Right conversations, right people, best possible moment (an Agile-influenced element of our True North proposal). Pushing authority to the information (David Marquet, author of the fantastic Turn the Ship Around!). For leaders, it means more than just clarity of intent, it means a genuine commitment to the people who will carry it out. And it’s not just about personal style, it has significant implications for organisation design.

Recap

Here again is Agendashift in 5 principles:

  1. Start with needs
  2. Agree on outcomes
  3. Keep the agenda for change visible
  4. Manage options, testing assumptions
  5. Organise for clarity, speed, and mutual accountability

Whether for 21st century change management or organisational adaptability, what principles would you choose? How do they align to these?

*See Lean-Agile transformation as Lean-Agile process for a backwards example.


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Recommended reading

From the “behind the scenes” sections of each chapter of the Agendashift book (part I published on Leanpub in May) I’ve extracted a list of recommended books and other references.

By chapter, you’ll find reading recommendations on these topics:

  1. Discovery: Clean Language, 1-2-4-All (the facilitation pattern)
  2. Exploration: Cynefin, “plan on a page”
  3. Mapping: User Story Mapping, Impact Mapping, Strategy
  4. Elaboration: Lean Startup, A3, Toyota Kata
  5. Operation: Organisation, culture, Systems Thinking, Kanban

Find it here: Recommended reading. See also our Resources page. Enjoy!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

Video: Exercises in Lean-Agile transformation

Two weeks ago I led a big Agendashift-style Discovery session (chapter 1 of the book) for 80+ people as guest of Adventures With Agile’s London meetup. Here’s the video:

Last week I was at Agile Yorkshire. Tomorrow (Wednesday June 20th) I’ll be doing my third meetup in three weeks, when I’m at Agile Peterborough. 75 people signed up so far!


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

A True North for Lean-Agile?

You may have noticed that the blurb for our workshops and for the new book always starts with this:

Imagine… 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

It’s taken from one of our Discovery exercises (chapter 1), an early opportunity for participants to explore different ways of working not from the perspective of prescribed practices, but in terms of what it is like – how it feels, what’s different, and so on.

Some of the groups I’ve facilitated have found the exercise so cathartic that they ask repeatedly for more time. It’s not hard to see why:

  • If you feel that you’re rarely given the opportunity to work at your best, your team doesn’t work well, or you’re painfully aware that teams aren’t working work well together, it can come as a relief to be given the chance to imagine a different reality
  • Whether you’re a front line worker or a manager, conversations happening at the wrong time (or not at all) can be very frustrating
  • For most of us, knowing that we’re meeting needs is crucial to finding meaning in our work

The current text of the book doesn’t identify these words as a True North statement (a compass direction rather than a destination), but it probably should. A True North for Agendashift certainly, and I’d like to put it forward as a True North for Lean-Agile also. It’s consistent with the Lean pillars of respect for people and just in time. Consistent with the Agile manifesto, it elevates individuals and interactions, combining those with a sense of timeliness (I joke that Agile seems to imply lots of meetings, the beginning – one hopes– of true collaboration).

In its favour as a worthy True North:

  • It is easy to understand, worth striving for, and will remain always just out of reach. Transformation must be continuous, not a one-off project
  • It works at every scale – from individual to organisation, and at scales in between
  • In its last bullet, it conveys much-needed senses of proactive discovery (needs don’t get consistently anticipated by accident) and purpose (needs being met)

Also, it’s not specifically about software, or even about product development. That’s a departure from the Agile manifesto, but I have no doubt that this is in its favour too.

So… Does it work for you?

Related:

Screenshot 2017-05-22 13.42.56


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter

If you’ve read Kanban from the Inside…

…what should you expect from my second book?

TLDR: Agendashift wouldn’t have happened without Kanban from the Inside. It is however very much its own book. I think you will enjoy it 🙂

Not only is Agendashift not a book about Kanban – in fact it is very consciously method-neutral –  it makes few assumptions about the reader’s knowledge of Kanban either. In terms of detailed content then, the overlap is minimal and both books stand alone. The resonances between the two are however very strong:

  • The titles of the first six chapters of KFTI make an appearance in Agendashift chapter 2 (Exploration) as the headings of the Agendashift values-based delivery assessment. These are the values of Transparency, Balance, Collaboration, Customer focus, Flow, and Leadership. If you’re wondering what happened to Understanding, Agreement, and Respect (KFTI chapters 7, 8, and 9), they belong with Leadership (which shouldn’t be a big surprise).
  • Reverse STATIK (which was developed while KFTI was nearing completion) reappears in chapter 3 (Mapping), not as an improvement process, but to provide a sense of narrative flow to the transformation map, something the values can’t easily provide.
  • The same sense of respect for a broad range of models described in KFTI part II, in particular Agile, Lean, Lean-Agile, Lean Startup, Cynefin, Systems Thinking, and Scrum. If anything, the appreciation is deepened thanks to experience and integration.

Moreover, you can see the final chapter of KFTI (chapter 23, Rollout) as the springboard for Agendashift, a more thoroughly exercised how-to – not for Kanban, but for continuous transformation, a term not found in the older book. Expect these themes from chapter 23 to be developed more fully:

  • Making the agenda for change visible
  • Pulling change through the system
  • Making a connection between purpose and transformation
  • Identifying increments of change
  • Managing change visually
  • Recognising different kinds of change (and choosing appropriate tools)

The section Identifying increments of change contained the seeds for the Agendashift values-based delivery assessment, which in turn gave rise to the transformation mapping workshop and our now well-rehearsed routines for identifying priorities, obstacles, outcomes, options, actions, and so on. These are covered in chapters 2-4 of the new book.

In short, Agendashift wouldn’t have happened without Kanban from the Inside. It is however very much its own book. I think you will enjoy it 🙂

Read them both:

agendashift-part-1-cover


Agendashift-cover-thumb
Blog: Monthly roundups | Classic posts

Links: 
Home | Partner programme | Resources | ContactMike
Community: Slack | LinkedIn group | Twitter