In the context of a discussion about a scaling framework (it doesn’t matter which one), I was asked yesterday in the Agendashift Slack about recurring patterns I’ve seen or applied in my work and whether/how they’ve been affected by Agendashift.

For the sake of minimum argument, let’s say we’re already using both Scrum and Kanban at team level. Basic (and improving) processes are in place, work is visible, and teams are not massively overburdened. It’s not necessarily how I’d start but let’s call that easily-understood baseline ‘play 0’.

After that, here are five key plays from my playbook:

1. Smooth/speed work through dev – often through managing dependencies better, identifying them before work starts, making them more visible, greatly reducing the appetite for starting work that can’t be finished
2. Make the post-dev process more visible – make any issues there too visible to ignore
3. Smooth/speed work through the post-dev process – better conversations at the start of the process (even before dev), better automation, better management of environments, etc
4. Validation – retain ownership of work well past delivery, validating that the impact on user behaviour is as expected and that needs are being met
5. Work on the team/organisation interface – risk management, change management, service delivery reviews (a favourite of mine), team sustainability (funding, recruitment, skills transfer, etc)

In what order? When do you do these things?

Of course it depends, but notice:

• The need for plays 1-3 should become increasingly apparent to the teams themselves once play 0 has taken effect. More experienced teams are likely to notice the need for them sooner; the most experienced ones will not only contain people who know not only that bottlenecks move, but can guess in which direction (and they’re listed in the most common order). These changes happen fastest when they are encouraged and supported by people who know what to expect. An explicit drive towards continuous delivery is helpful, especially with regard to plays 2 and 3.
• Unlike plays 1-3, plays 4-5 are unlikely to appear spontaneously through a process of introspection. They involve some important attitude changes:
  • Work is only truly ‘done’ when needs have been met (and demonstrably so)
  • It is recognised that the host organisation has needs too, and that unless you want live forever in a small Agile bubble, a certain amount (and style) of mutual accountability is healthy, not a threat.

If I’m working mainly at team level, it’s likely that the five plays will happen in roughly the order presented. Play 4 may involve developing some skills that the dev team might not have in abundance initially (user research & testing, service design, service management, etc). Play 5 may come a lot sooner if the right kind of sponsorship is in place, and it helps immensely if there are managers who can also be considered part of the team for at least these purposes (service managers, delivery managers and project managers in GDS projects, for example).

How Agendashift changes things

Let’s recast these plays as outcomes to be achieved:

1. Work flowing smoothly through dev, dependencies managed well
2. Effective management of the process end-to-end
3. Good collaboration end-to-end and an effective technical platform for rapid delivery
4. Proactive alignment of team and customer, more ‘right thing’ than ‘wrong thing righter’
5. Proactive engagement between team and organisation, setting the tone, metrics consistent with values, better alignment overall

As soon as you have agreement on outcomes like these, the opportunity is there for the taking. Of course there are right ways and wrong ways of going about things (and Agendashift provides some help here), but as per my previous post, Getting to Agendashift’s “Why”:

Because when you have agreement on outcomes, the rest is “just” the how…

Agendashift creates the opportunities for outcomes like these to be articulated and agreed upon, even before deep-seated pain points are fully exposed, thereby accelerating the process. They can be tackled in sequence or in parallel, via off-the-shelf practice or innovation, with or without reference to frameworks. The choice is between you and those that you work with and for, defined to some degree by your role already or left open. Where choices are open, make best use of that opportunity: consider a diverse range of options and make progress by testing assumptions relentlessly (advice that works for product development too).

While we’re here

November 8th (tomorrow) is a key day:

• There’s still one place remaining at tomorrow’s workshop in Cape Town
• Early bird pricing for the London workshop on the 22nd and 23rd expires tomorrow

---

Blog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter
Workshops (see Events):
8th Nov, Cape Town, South Africa; 22-23 Nov, London, UK