Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Q&A on Agendashift with Mike Burrows

Q&A on Agendashift with Mike Burrows

Lire ce contenu en français

Agendashift is a values-based Kanban approach to organizational transformation, covering delivery, change and leadership.

InfoQ interviewed Mike Burrows about what Agendashift aims to deliver, how Kanban and Agendashift can strengthen each other, ideas to make changes stick in organizations, results of the depth of Kanban survey, his view on the value of Kanban practices, increasing effectiveness by having an end-to-end process view, recent developments in leadership and doing sustainable change with Kanban.

InfoQ: Can you explain what Agendashift is, and what it aims to deliver?

Mike Burrows: No-one who has read my book Kanban from the Inside or my series of articles here on InfoQ on the Kanban Agendas will be surprised to hear that I have gone “all-in” on values! Agendashift is a realisation in startup form of the last chapter of my book, covering

  1. Values-based delivery – an assessment tool whose templates are organised by value (by default transparency, balance, collaboration, customer focus, flow, and leadership)
  2. Values-based change – using the assessment as its springboard, a hypothesis-driven Lean change management tool
  3. Values-based leadership – supporting the key leadership task of aligning values and purpose within the organisation and with its customers

At the time of writing, my MVP for the first of those is available online in beta, the second exists in workshop form while the online tools are in development, and for the foreseeable future the third will exist entirely as a workshop with follow-on support.

InfoQ: Do you have some examples which show how Kanban and Agendashift can strengthen each other?

Burrows: Agile offers some useful analogies here. The Agile Manifesto (an expression of values) does much to explain the relationship between how Agile works and the kinds of benefits sought by those who buy into it. However, when it comes the body of knowledge of Agile practice, it barely scratches the surface! Worse, following Agile practices to the letter in ignorance or defiance of their spirit is a recipe not for success but for disappointment, frustration, and pain.

With Agendashift, we start by identifying the values and behaviours we most need to work on, and move from there into practice. For example, the values-based delivery assessment template has in the “balance” category this prompt:

  • “We take care not to overburden the system with more work-in-progress than it can accommodate effectively”

We’ve articulated here an important organisational behaviour in a way that exposes much of the intention behind the Kanban Method’s second core practice, “Limit work-in-progress (WIP)”. Helpfully, it also begs other questions: “how much is too much?”, and “how do we define ‘effectively’?”.

If the values are broad and the method’s practices are specific, Agendashift and Kanban switch roles on the change management part. Agendashift is the opinionated one here: Changes should be framed as hypotheses and they should be managed through a transparent, pull-based process, such as the one documented by Jeff Anderson in his Lean Change Method book. Agendashift maintains here a strong relationship back to values-based delivery; the assessment is the springboard for change, and changes (whether triggered by an assessment or otherwise) can be linked back to values and behaviours.

Agendashift embraces Kanban’s “at every level” approach to leadership and its focus on purpose and fitness. We take organisations through a process of identifying their values, articulating some of the key behaviours that exemplify them, and understanding their affinity to existing models (not just my model of Kanban’s values, but Agile’s, Lean’s, and others). Actual organisational priorities for change then become the context within which the role and disciplines of leadership are explored.

InfoQ: Sustaining change can be challenging as people have found out. Do you have ideas on how to make changes stick in organizations?

Burrows: I won’t reiterate what I’ve already said about process and tooling (which do matter). Instead let me repeat a line I’ve been saying for years: how would you expect to succeed without understanding, agreement, and respect?

In the values-based delivery assessment template we have tucked those three values inside the leadership category (a move I anticipated in my book when I referred to them as Kanban’s “leadership disciplines”), but this is not to belittle them. Basing change on a proper understanding of what is being changed and the likely impact of implementing the change doesn’t just reduce the risk of failure for reasons of knowledge; the process of acquiring that understanding can be impactful in itself. It is no secret that it is important not to neglect agreement among those sponsoring change, those implementing it, and and those impacted by it; moreover, achieving it is very much easier when they’re the same people. Though we wish that respect for people was universal and that all change was conducted respectfully, we can all think of examples where disrespectful change came unstuck.

I will add to those a fourth value – transparency – and the related core practice “Implement feedback loops”. Behind this practice is one David J Anderson’s key contributions, that of identifying some vital feedback loops that are too often neglected. Their absence means that valuable opportunities are missed to sustain the ongoing realignment of team, product, and service in the direction of the customer’s deeper needs and the organisation’s longer-lasting goals.

InfoQ: Can you share some results from the Depth of Kanbanland survey with the InfoQ readers?

Burrows: I’d love to! First of all I, I should mention the survey’s (and the underlying template’s) measurement scale. On a scale of 1-4 (there’s no middle option for the lazy):

  1. Barely started - little evidence, if any
  2. Early gains - sporadic evidence, not widespread or consistent
  3. Getting there - evident, but improvement or more consistency needed
  4. Nailing it, consistently - firmly established, widely and consistently evident

Across the six categories, the strongest by some margin was transparency. I wouldn’t anticipate much surprise at that result, though within that category there are some interesting differences at the level of individual behaviours, and in particular those related to feedback loops.

With a survey score of 3.2 (beyond “getting there”, and with more than a quarter of respondents “nailing it”), this prompt scored top not just in the transparency category but across the whole survey:

  • “We review our progress frequently, typically during daily stand-up meetings”

In stark contrast, this one scored just 2.3:

  • “We review regularly the overall effectiveness of the end-to-end delivery process and the policies that govern it”

“Barely started - little evidence, if any” describes more than a quarter here. As I suggested earlier, these outer feedback loops are too often neglected.

The bottom two lowest-scoring categories are hard to separate and have changed places over the course of the survey. They are balance and customer focus, both scoring 2.8 overall. Again, I suspect that few will be surprised. These two prompts are representative of the depth of the challenge we face in our industry:

  • “We maintain a good understanding of how much work our system can accommodate before our effectiveness is compromised”
  • “We actively seek to understand the value and urgency of potential work from the perspective of the end customer”

Respectively, they scored 1.8 and 2.1. The latter of those has a companion that achieved (if that is the right word) the lowest score of the whole survey, 1.6:

  • "We identify early the means to validate the benefits that will be realised by work item after it is delivered"

Perhaps this low score is a function of its awkward wording (a hypothesis we can test next year), but its ranking at or near the bottom is accurate I’m sure.

InfoQ: Why do you think so many organizations struggle to balance work?

Burrows: Experiences vary, but there are some common patterns. In the world of service delivery, requests are typically made in ignorance of current workload, and often with a sense of entitlement too. Given this combination of circumstances, it can seem hard to prevent work from being pushed into the process. In product development the issues are a little different: ideas are cheap, and the customer end of the process – testing, deployment, validation etc – can seem harder technically or psychologically than the work that precedes it. The process fills up with work-in-progress for no better reason than that we give adequate priority neither to finishing nor to its enablers.

At their most excellent, performed with a deep understanding of how the work is really done, service management and project portfolio management can help significantly. Done less well however, they can make things very much worse. This is a significant problem, but we’d caution against rushing to judgement. Instead, and with appropriate sensitivity, we’d rather see the symptoms, causes and impact of overburdened systems made more visible as the initial step towards addressing these issues. The techniques are high on our list of transferrable skills!

InfoQ: Do you have suggestions what organizations can do to become better in understanding the value and urgency of potential work from an end customer perspective?

Burrows: The most obvious piece of advice is to go out and talk to them. Beyond that, these two principles complement each other well:

  1. When dealing with potential work, never forget that the goal is to make choices between alternatives; it is a mistake to consider options only on their own individual merits. Stage gate checklists, for example, tell you only that a work item is good enough to be considered, not that it stacks up against the alternatives. And make sure that decisions are made by people competent to own them; if that’s the customer, then so be it.
  2. Break the portfolio problem down until you’re comparing like with like, broadly speaking. If you’re agonising repeatedly over decisions between (say) urgent product features and background maintenance, you either haven’t organised your potential work well enough, or you have allocated insufficient capacity to important categories (another problem of balance).

With these basics in place, more sophisticated techniques like cost of delay, classes of service and so on scale much more easily.

InfoQ: How about the value that adopting Kanban can deliver in organizations, can you share some insights on this from the Depth of Kanbanland survey?

Burrows: That’s a tricky question to answer from a single point-in-time survey, but we can definitely draw some encouragement. Despite the low overall score for customer focus, this prompt scored well at 2.8:

  • “We continue to own work items until they have been delivered to and validated by customers”

Key end-to-end feedback loops might be lacking, but some end-to-end thinking is in evidence. I’m encouraged too by score of 2.9 for a prompt that echoes Kanban’s respect principle, a principle that (frankly) stands in opposition to dogma and attitudes held in parts of the Agile community:

  • We respect and acknowledge the contribution of existing functional roles, organisational structures and practice”

Implementing change is hard enough without getting off on the wrong foot and needlessly provoking resistance. Respect is a very good guide, and I’m heartened that this message is getting through.

InfoQ: We are researching which Kanban practices can deliver value when used next to mainstream agile methods. What’s your view on this?

Burrows: I’d say “all of them” of course, but let me restrict myself to Kanban’s two most recognisable practices: 1) visualising (with, among other things, kanban systems) and 2) limiting work in progress. In both cases, the most value is gained when the goal is to improve the end-to-end process rather than simply to optimise some small part of it. Have the ambition to extend “end-to-end” far enough upstream that you’re finding new ways to explore customer needs and to shape demand. And don’t let go until you’ve understood the value actually being realised as a result of what you deliver.

InfoQ: Having an end-to-end view on the delivery process matters to increase effectiveness as you mentioned several times. Do you have examples of companies that excel in this? What did they do to get good at it?

Burrows: I recently used the phrase “surprisingly awesome” with a colleague to describe our experience on multiple UK Government Digital “Exemplar” projects. Very transparently, these put user needs (as opposed to policy considerations or preconceived requirements) front and center of all that we did. It meant finding out – by talking to them – what citizens wanted to achieve with these services and the needs that drove those immediate goals. It meant testing prototypes (even paper prototypes, let alone early builds) with real customers. It meant following through after deployment, checking that new functionality really did perform as expected. This is not what we have come to expect in the public sector – surprisingly awesome indeed!

At a smaller scale, I tell the story in my book of the impact that customer validation made on our whole process. Involving the customer (internal customers in our case) in what could potentially be a difficult conversation on either side had a catalytic effect on our process end-to-end. Working backwards, our final implementation steps were performed more carefully, we tested and developed with much closer collaboration with the customer, and we were much less likely to prioritise a piece of work just because it would humour someone temporarily.

Prior to that, a significant portion of my career was in banking. I saw both good and bad there of course, but the best was always characterised by strong customer alignment. This doesn’t happen by accident.

InfoQ: Do you have insight into recent developments in leadership? How can these developments help organizations to increase their agility?

Burrows: I’ve been revisiting Greenleaf’s 1970’s vision of Servant Leadership and comparing it with the “get out of the way, unblock all the things” vision that (very unfortunately) seems to go by the same name now. To me, that latter model seems impoverished, and I hope it’s not too late to do something about it. If I tell you that an early working title for my values-based leadership workshop was “Applied Servant Leadership”, you’ll know that I’m committed to doing my part!

What I love about Greanleaf’s fuller vision of Servant Leadership is the process by which it sustains itself into the future. Zooming out to the scale of the organisation and the leaders Greenleaf refers to as its “trustees”, this process might be described thus:

  1. We help others be successful – removing impediments, meeting immediate needs
  2. We help others find autonomy and meaning in the development and pursuit of the organisation’s values, mission, and purpose in society
  3. We help develop servant leadership in others

Essential to a deeper understanding of Servant Leadership is that middle point, which adds a challenging external ambition. Remove that step, and the result is a turning inward, then stagnation and decline.

InfoQ: If readers want to learn more about doing sustainable change with Kanban, where can they go?

Burrows: The Depth of Kanbanland 2015 survey is still open, which means that readers are free (and very welcome) to try the values-based delivery assessment. Some acknowledgements are in order here: the original English version was adapted in collaboration with Dragan Jojic; French, German, and Italian translations are by Christophe Keromen, Markus Hippeli, and Marco Bresciani respectively; Dutch and Russian translations by Martien van Steenbergen and Nikita Vishnevskiy are in the pipeline.

After that, prioritise some changes, read around the subject, and talk to people who’ve done it before. If the way forward isn’t obvious, get some expert advice and try some experiments meanwhile.

About the Interviewee

Mike Burrows - author of “Kanban from the Inside” (Blue Hole Press, 2014), founder of Agendashift, management consultant, coach and trainer specialising in values-based change, leadership and delivery. Former Executive Director, IT Director and global development manager.

Rate this Article