Agendashift as Good Strategy

[This is the third and last of a three-part series. Start from the beginning: Lean-Agile transformation as Lean-Agile process]

This post has been a while in coming. If you’ve been waiting, apologies! I’m going to cheat a little: what follows is lifted directly from the end of the just-written third chapter (Mapping) of the forthcoming book [Update – it’s now out: Agendashift, clean conversations, coherent collaboration, continuous transformation].


Is it Good Strategy?

To finish this chapter, the promised third reconciliation. This time a very quick reconciliation of your transformation map with Rumelt’s strategy kernel. This model comes from another brilliant book:

Three questions (Rumelt’s model, my words):

  1. Diagnosis: Is your strategy rooted in an understanding of the challenges you face and the opportunities available?
  2. Guiding policy: What gives shape to your strategy?
  3. Coherent actions: Are your planned actions coherent with each other, your guiding policy, and your diagnosis?

By virtue of your transformation map’s construction you should be able to give positive answers to questions 1 and 2, and a partial answer to question 3:

  1. Diagnosis? Witness the obstacles and their respective outcomes from Discovery, Exploration, and Mapping (chapters 1-3) together with the survey analysis that informed Exploration (chapter 2).
  2. Guiding policy? Your strategy was given shape first by the values and prompts of the assessment (chapter 2), and then by the transformation journey steps of this chapter.
  3. Coherent actions? You have identified detailed outcomes that you have reconciled with your broader goals. Moreover, most (if not all) those outcomes align with one or more of the values of the survey, and those values are themselves coherent.

We could add to point 3 that our overall approach to the transformation process is highly coherent with our Lean-Agile sensibilities. Hardly a minor point!

So we’re good then? Not so fast. A solid basis for a good strategy certainly, but a further level of detail is still required. We’ve said what we want to have happen, not the concrete steps we will take and what impact we think they will make. Cue chapter 4, Elaboration.


This was the third of three related posts:

  1. Lean-Agile transformation as Lean-Agile process
  2. Agendashift as coaching framework
  3. Agendashift as good strategy

See also Karl Scotland’s post Good Agile/Bad Agile: The difference and why it matters.


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

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

Agendashift as coaching framework

[This is the second of a three-part series. Start from the beginning: Lean-Agile transformation as Lean-Agile process]

What with last week’s London workshop (sold out!) and work on the new book I’ve got a bit behind my usual blogging schedule. Sorry about that! Every cloud though – here’s Agendashift partner Andrea Chiou debriefing (in Slack) her appearance this week at the Agile NOVA meetup in Washington, DC:

I said, using this style of interview, you can get managers in a room learning about each other’s vision for their most pressing problems, and in doing so you can then see where there is energy, as well as where there are solutions already inherently existing within the org

And:

This differs from almost every other Agile transformation approach I know, except one (I mentioned Open Space Agility). And the reason it works is because it is values-based, and based on mutual exploration and dialogue with managers/sponsors.

I might add here that Agendashift is also about exploration and agreement with participants (not just managers and sponsors), but Andrea does a great job of explaining how Agendashift helps facilitate those early conversations.

Especially in the guise of the Agendashift facilitator day, you can view the Agendashift workshop as a demonstration of three things:

  1. The power of a values-based and outcome-centric approach
  2. How the different techniques we use integrate so pleasingly
  3. An end-to-end transformation process that mirrors (and even exemplifies) a Lean-Agile delivery process.

Part 1 in this series expanded on point 3. Today, we’ll again review the five sections of the workshop, this time as a possible structure for a coaching engagement:

  1. Discovery: Identifying the strategic goals and needs that any coaching must support, setting the right tone in terms of ambition without losing sight of where the real challenges and opportunities lie
  2. Exploration: With or without the aid of the Agendashift assessment, exploring key areas of opportunity in more detail, identifying obstacles, and from those generating a set of outcomes that represent the scope, objectives, and priorities of the engagement
  3. Mapping: Understanding the challenge in enough breadth to be sure of not missing anything important, and keeping the coaching process fed with fresh and important challenges to investigate
  4. Elaboration: Generating, framing, and develop actions
  5. Operation: Ensuring follow-through, maintaining appropriate transparency, accountability, and feedback in the relationship

Just as we discussed in the previous post, this isn’t a completely linear process, in fact much of this needs to happen on a frequent or ongoing basis. There are however some key conversations that do need to be had, and the earlier in the process, the better. A coaching engagement that stands on a platform of agreed needs, scope, and level of ambition is surely healthier than one based on the offer of technical help or of facilitating a process whose goals no-one is able to articulate.

The tools we use and demonstrate through workshops will be used more informally and naturalistically in a coaching context, but they’re still valuable. All the more so, some of them! What coach wouldn’t want to be able to ‘flip’ obstacles into outcomes, identify the drivers behind pet solutions (and thereby open up the possibility of alternative solutions), or turn the vague into something actionable? These are very teachable skills. So too are the highly reusable skills of framing hypotheses and developing actions. Many coaches will find what Agendashift says about organisational design interesting too.

Coming up in the next few weeks are opportunities to experience this for yourself, with events in Hamburg (Feb 9th & 10th), Manchester (March 23rd), Edinburgh (April 6th), and Oslo (April 21st). Don’t see one near you? Get in touch and we’ll see what we can arrange together.

This was the second of three related posts (posts 3 coming soon):

  1. Lean-Agile transformation as Lean-Agile process
  2. Agendashift as coaching framework
  3. Agendashift as Good Strategy

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

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

Lean-Agile transformation as Lean-Agile process

[Update: Section/chapter 2 previously named Analysis is now Exploration. Thanks to Mike Leber for the suggestion made at last week’s Agendashift facilitator day in London. 1. Discovery, 2. Exploration, 3. Mapping – that’s a nice progression! Some edits made to reflect this change.]

Did I mention that I’m writing another book? Writing begins in earnest next week, and the wait is killing me! Nearly three years after Kanban from the Inside, I again feel the compulsion. I have to do this!

The new book’s first five chapters mirror the five main sections of the Agendashift transformation mapping workshop:

  1. Discovery: Identifying strategic objectives, obstacles, outcomes, and change strategies
  2. Exploration: Debriefing your Agendashift values-based delivery assessment, prioritising opportunities, and agreeing scope
  3. Mapping: Building a transformation plan
  4. Elaboration: Generating, framing, and developing actions
  5. Operation: Organising for continuous transformation

If you’re anything like me, you might thinking “Plenty of plausible-sounding words there, but what makes the process Lean, Agile, or Lean-Agile?” It’s a fair question – there are enough linear, top down, cookie-cutter, imposed, consultant-knows-best, and resistance-trumping models out there and we surely don’t need another one! Can we instead demonstrate collaboration, iteration, flow, pull, feedback and the rest?

There’s an old Lean trick that I’ll be employing in chapter 5: review the process backwards, from finish to start, from life at the operational sharp end and back to the fuzzy front end. Here’s a preview, and it describes a process for organisational transformation that with just a few substitutions could easily describe a Lean-Agile process in the product or service space.

5. Operation

We meet frequently to review progress on the changes we have in progress and to share what insights we’ve gathered along the way. We’re validating the impact of our most advanced experiments to help us decide whether or not to adopt them formally. Some of our other experiments haven’t reached that stage yet – we’re still testing changes for their usability (there’s no point in endorsing changes that won’t stick). Still further upstream we keep a small backlog of prioritised and well-understood changes to work on as soon as capacity permits.

4. Elaboration

We’re careful not specify changes until we’re close to needing that level of detail – this isn’t big design up front (BDUF) but a just-in-time (JIT) process. Leaving it until the last responsible moment gives us the opportunity to incorporate feedback from previous experiments (successful changes or otherwise) and to take into account recent environmental changes outside our sphere of control.

Where appropriate (which is much of the time) we use the language of Lean Startup and A3 to frame and develop our actions. We take the outcomes that are the main units of currency of the transformation map and from them form hypotheses, identify who should to be involved in the change (to a significant extent we’re our own customers here, but therein lies a trap), design pilot experiments to test our assumptions, and so on.

3. Mapping

There’s much still be achieved, and it’s important to keep our ideas organised. Call it a planning tool if you like, we use a transformation map, highly analogous to a story map, except that the elements being organised aren’t features, user stories or job stories, but the outcomes we’d like to achieve through our transformation.

[Aside: The analogy is strong – the ‘so that…‘ elements of user stories and job stories are outcomes too of course.]

The categories under which outcomes are organised may describe the stages in a transformation journey or simply identify high level themes; sometimes one evolves into the other. This organisation comes under periodic review as we step back from the day-to-day and reflect on our overall progress.

We prioritise within categories before looking across categories and deciding on what we will work on next. In setting priorities overall, we may choose to give special emphasis to a particular category for a while, or decide instead that it’s better to choose a minimal set of complementary changes from across the board.

2. Exploration

Exploration keeps the transformation map both based in reality and connected with the vision, the output from Discovery. What do we know? What can we find out? What seems to be important? Who should we talk to? Where are the most promising opportunities? What’s our scope?

With Agendashift, exploration is a generative process. Informed by the results from the assessment tool, we collaborate on identifying opportunities and their respective obstacles, then ‘flipping’ those obstacles into the outcomes that will become either the work items or the organising themes on our transformation map.

We do enough of this up front to prime the pump and to get a good sense of what it is we’re really dealing with. We revisit it periodically; as our transformation progresses, so too does our understanding of what’s urgent, what’s possible, and where we think we’re headed.

1. Discovery

What would it be like if everyone were able to work at their best, individually, within teams, and across teams? What if we could have the right conversations between the right people always happening at just the right time? What if everyone always got what what we needed at just the right time too?

Why don’t we have that now? What obstacles lie in the way of achieving that? Can we go from all of that to a set of goals? What kinds of delivery approaches will be appropriate for the kinds of outcomes we seek? Who do we need to engage in the process?

This was the first of three related posts (post 3 coming soon):

  1. Lean-Agile transformation as Lean-Agile process
  2. Agendashift as coaching framework
  3. Agendashift as Good Strategy

If you’re a Lean-Agile practitioner and can see yourself using these tools, check out our partner programme. If you’re a sponsor of change and think this might work for you, check out our partner directory. In either case, check out our events calendar for a public workshop near you. If you don’t see one or you’d like one internally, get in touch.


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

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

The “obvious” question

First things first: the rename mooted in last week’s post has already been implemented. What was the “Agendashift debrief/action workshop” is now the Agendashift transformation mapping workshop. The same content in a more digestible order, with some additional and already-implemented improvements to be announced in the new year.

Anyway…

Remember this picture? It’s an example of the output from a Cynefin four points contextualisation exercise, taken from a training day earlier this year:

IMG_1523

There’s a slightly tongue-in-cheek question I like to ask when debriefing this exercise:

What’s the obvious question to ask about the items in the the Obvious corner?

The answer I’m looking for:

Why haven’t they been done already?

After the teasing comes a serious point that has become a recurring theme for my workshops: Too many organisations are full of smart people who can tell you what’s wrong and can give you a long list of sure-fire fixes, but nothing changes.

You might say that these organisations are uninterested in improvement, but I believe that in many cases it would be more constructive to say that they are incapable of following through. There is little to no visibility or accountability around anything change-related; the feedback loops (whether formal or informal) that do exist are likely to be overwhelmed with urgent delivery-related issues, with no provision for understanding and tracking improvements the systems that allow those issues to arise in the first place.

If that’s true for the Obvious corner, how will they fare in the Complex corner? If they can’t track obvious changes, how will they manage the kind of change that involves experiments – even experiments-within-experiments (pilot experiments) – and all the uncertainty that goes with that? Not well.

Conclusion? If change isn’t happening, don’t blame your staff. Instead:

  • Make sure that improvement work is treated as ‘real work’, prioritised, tracked, and rewarded as such
  • Keep it visible to any managers and other stakeholders whose commitment will be required in order for the more difficult changes to be realised
  • Provide safety, treating success and failure as near equals. Better to keep learning than never to dare anything difficult

Let me leave you with the relevant prompt from the Agendashift values-based delivery assessment:

We ensure that opportunities for improvement are recognised and systematically followed through

How well does that describe your organisation?


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

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

The transformation map

Big day yesterday – it was the occasion of the very first Agendashift facilitator day, the first of many I hope! Here, in all its glory is the transformation map we produced:

transformation_map_leeds_2016_12_05

For the name transformation map we have workshop participant Tony Richards to thank. One of those things that seems obvious in retrospect (but still all credit to Tony), it’s a particular kind of story map (I described it as such), one whose ‘spine’ is a transformation journey.

The detail is driven from the 40+ prompts of the Agendashift values-based delivery assessment. Category by category (value by value or journey step by journey step) we:

  1. Prioritise prompts that represent areas of opportunity
  2. Identify obstacles that prevent the full realisation of the future reality described by the prompt
  3. “Flip” those obstacles into objectives (Clean Language provides some fun ways to do this)
  4. (Optional) Generate actions for those objectives

To set the right context for the transformation mapping process we explore existing strategic objectives and assess the current situation. This process builds agreement, creates opportunities for alignment, and ensures that the resulting transformation strategy is coherent not just by construction, but in context also.

Other learnings

Learnings for me, that is!

Between the outer wrapping of that strategic exploration and the meat of the transformation mapping exercise, most of my workshops have up until now included a series of exercises around hypothesis-driven change (HDC). Here, we take a small number of high priority outcomes, generate actions for them, and then choose just one action to reframe (Lean Startup-style) and develop (A3 style). Yesterday, the transition from this deep dive to the breadth of the mapping exercise felt difficult for some participants.

I’ve not noticed this difficulty in client workshops, but it could be that the facilitator day’s lack of a shared organisational context amplifies a problem of which I was previously unaware. Anyway, I take it seriously.

Long story short, in the next iteration of this workshop, the HDC exercises will be postponed until after the transformation mapping activity. Transformation mapping is now very much the core part of the day, to the extent that I’m very much inclined to rename the workshop as a whole after it!

This change has further significance: deferring the generation of actions makes outcomes the main unit of currency for most the day. It is often natural to use outcomes and actions somewhat interchangeably, but nevertheless I’m sure that this development is healthy, perhaps bringing our consciously non-prescriptive approach into sharper focus. Remember: inclusive • contextual • fulfilling • open!

Keep an eye on our events calendar for more of these public workshops; feel free to ask that we hold one near you (perhaps you can help us make it happen). And if you’d like me or a friendly neighbourhood Agendashift partner to assist you in building your own organisation’s transformation map, don’t hesitate to get in touch.


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

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

A blocker waiting to happen (and it works both ways)

Dependency
A blocker waiting to happen

That’s a rather informal definition and it’s not strictly accurate (some blockers are unrelated to dependencies), but it will do! Certainly it’s more helpful than Wikipedia’s:

[A] dependency is a link amongst a project’s terminal elements.[citation needed]

In our consciously inclusive and non-prescriptive way, the full version of the Agendashift values-based delivery assessment implies two kinds of dependencies:

1.5 We identify dependencies between work items in good time and sequence them accordingly
1.6 We identify and manage dependencies on external teams or services

The first of those is usually straightforward to deal with: we take care not to start a work item (some kind of deliverable – a feature, say) until we know that its dependent work items (other features or required infrastructure) will be in place. In the simplest case, we just sequence work items into some natural order and deliver them one by one. We must be a little more careful if we want to take advantage of our capacity to work on items in parallel, but still the advice mostly boils down to the mantra “Don’t start what you can’t finish”.

That mantra applies to the second kind of dependency also. Here, we know (or really should know) that we can’t finish a work item without some external contribution. Even the best cross-functional team will find itself dependent on others from time to time! Under these circumstances, if our work is to flow smoothly we must be take active steps to ensure that things will come together at the right time.

That in turn means being in the habit of identifying our dependencies in good time, keeping them visible so that no-one makes the mistake of starting work prematurely, and engaging appropriately with the people on whom our work’s completion depends.

2015-02-25-08-01-42
A Story Map with external dependencies:  note the red flags bottom right

Just-in-time: It works both ways

Most people will read “appropriately” as “early enough” – early enough to ensure that our work won’t be delayed. This is a slightly selfish view however, and it’s worth looking at this from the perspective of the team on who we depend. From their side, a piece of work that is started too early is a piece of work that can’t be integrated, tested, deployed, validated, and so on. Ugh! This is the kind of work-in-progress (or inventory) that the organisation as a whole really doesn’t want. If we’re really serious about flow in the presence of dependencies, the Lean idea of just-in-time (JIT) implies some two way commitment!

This is one reason why the concept of service is so helpful. Whether customer-facing or internal, an effective service combines two things:

  1. A strong sense of what we’re delivering, to whom, and why
  2. The ability to manage expectations around performance

service-oriented organisation has both of these firmly established on both sides of all its dependencies, achieved through mainly bilateral coordination, not overly reliant on organisation-wide synchronisation. A very good thing to strive towards.

Do you find yourself continually struggling with dependencies or (the flip side of the same coin) excess organisational inventory? It’s a solvable problem. Get help!


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

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

Scaling without cross-functional teams / Servant leadership un-neutered

Hot off the press from the Øredev conference (great work guys – the conference isn’t even finished yet), videos of my two talks.

Wednesday: Scaling without cross-functional teams. I’m grateful to track chair Martin Rosén-Lidholm not just for inviting me, but for suggesting this provocative title! It’s a brand new talk and I really enjoyed both writing and delivering it.

Scaling without cross-functional teams from Øredev Conference on Vimeo.

Thursday: Servant leadership un-neutered. I’ve given this talk several times this year, and I have to admit that early versions suffered from me trying to pack in too much material. I keep on editing  (I removed a slide between Hamburg on Tuesday and Malmö on Thursday) and it flows much better now.

Servant Leadership un-neutered from Øredev Conference on Vimeo.

Would you like to have either of these talks at your event? Get in touch!


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

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

Better user stories start with authentic situations of need

I drive a Toyota Rav 4 Hybrid. It’s the most sophisticated piece of equipment I have ever owned and I love it, but the satnav has been a constant source of frustration. It’s a lot better now than it was when I took delivery (frankly, it was embarrassingly bad), but one niggle still stands and I’m going to use it as an example.

Do you use the direction list (or “turn list” as it’s sometimes called) on your satnav? Not everybody does, but I like to!

I don’t know if Toyota are fans of user stories, but I can imagine some business analyst at Toyota City writing one that goes something like this:

As a driver,
I want a list of directions
so that I can review my route

Like a million other user stories, it’s short and sweet, a convenient shorthand for the feature. You can imagine the <what> part, (the list of directions) being further elaborated somewhere. Neither the <who> nor the <why> parts add much. Basically, the user story identifies a requirement. Old school! The unfortunate result here is 100% cast-iron mediocrity.

Here’s my personal job story for this feature:

When I’m about to leave the motorway (at 70MPH),
I want to know what’s coming next
so that I can choose the correct lane on the slip road

Had Toyota considered that scenario, they’d know this feature needs to be readily accessible (one click away, not three), easily found (not hiding in a settings menu of all places), and legible without reading glasses (whose idea was blue on blue icons?).

Here’s the relevant Agendashift assessment prompt (we just updated it):

4.1 We take care to understand the needs that will be fulfilled by our work and to explore the circumstances in which those needs arise

We’re not prescriptive, and we’re not insisting that you abandon user stories in favour of job stories. But do remember that to bring your user stories to life, they need to start in an authentic situation of need. And if you can’t think of one, either talk to your customer (Toyota, you can talk to me anytime) or seriously consider dropping the feature.


What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with OutcomesHome | 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

Introducing the Pathway edition

In the weeks leading to Agendashift’s launch earlier this month, a number of things came together at just the right time. Two of those in combination – Clean Language and Cynefin – I blogged about recently. Another key element, the pathway, I have hinted at but not described adequately. It’s time to put that right.

Some background

The online part of Agendashift is built around the values-based delivery assessment, our distinctively non-prescriptive, non-judgemental, methodology-neutral tool. The 2014 version of this was extracted from my book (and not just by me – others had the same idea), and it has been revised beyond all recognition since then, first in close collaboration with Dragan Jojic and more recently by community work, mainly via our Slack group.

The assessment’s tone has changed noticeably over that two-year period. It is of course still organised by those six values – transparency, balance, collaboration, customer focus, flow, and leadership – but the 40+ prompts are much less about specific practices and much more about the outcomes derivable from them. That might seem like an odd change to make, but we find that people buy into those outcomes even when the by-the-book practices that lead to them can seem unattractive.

For example, who wouldn’t want to be able to say this about their organisation:

We understand our performance sufficiently to make timely decisions, to set appropriate expectations, and to guide focussed improvement

Buy into that outcome, and implicitly you’re buying into the changes that will bring it about. Compare that to the older version of this prompt:

We measure lead times and predictability and seek to improve them

With the benefit of hindsight I can sympathise with those that instead of buy-in reacted with push-back! The original wording was well-meant but ill-thought, almost guaranteed to provoke resistance in anyone who has experienced the mis-application of metrics or who wonders why we seem to promote one set of metrics at the apparent exclusion of others.

Outcome, agreement, action, planning

Much of coaching or facilitating with Agendashift can briefly be summarised as follows:

  1. Using the prompts to establish a shared understanding of the current situation, expressed in terms of how well the prompts describe reality (‘scoring’ the prompts)
  2. Using the prompts some sense of what’s important to people – first individually (‘starring’ selected prompts) and then collectively
  3. Prioritising those generic outcomes, then turning them into agreement on more specific outcomes that are more immediately realisable
  4. Generating, framing, developing, and organising actions that we hope will make the most important outcomes a closer reality

This is already powerful, but it’s not quite enough. We need pathways, shorthand for a process that turns something that could feel very multidimensional and amorphous into something sequential that can be tackled step-by-step over a period of time. It turns “a lot of good stuff” into a plan (where that’s warranted) or an agreed way forward (if that’s all that’s needed).

Agendashift’s latest trick is the ability to reorganise the values-based assessment on demand. Here’s a summary chart that illustrates the idea, using the ‘Pathway edition’ template:

screen-shot-2016-09-23-at-11-47-45

Do the category names have a familiar ring? They’re inspired by Reverse STATIK, the ‘Reverse’ a clue that this is not the classic STATIK process that builds up to a Kanban system implementation, but a process of review and reworking that starts with our existing management systems, whatever they are.

In our example, the first category, Refine existing systems, already scores relatively well (or rather, its prompts do), but look at the number of stars! This category contains some of the most basic things to get right, and it would seem that there is strong support for making further improvement here before moving on to more challenging things.

Improve the service experience isn’t as well supported, but there’s a wide range of scores here. Before dismissing this category prematurely it would be wise to explore any differences of opinion. What’s going on here? Differences of understanding of the current situation, of what’s possible, or of the scope of the exercise? Well worth checking.

The next three categories, Manage the knowledge discovery processBalance demand and capacity, and (deep breath) Address sources of dissatisfaction and other motivations for change have moderate levels of support. Sequence-wise, they’re in at least roughly the right order.

The last category, Explore fitness for purpose, has the strongest support, but are we ready to tackle it yet? Would it make sense to tackle the basics before we address things that we know will be more challenging – organisation design, leadership behaviours and the like? There’s no one right answer to that question, but it’s worth asking!

It should be clear now that pathways here aren’t cookie-cutter plans, but starting points to be developed collaboratively. They can be used in conjunction with other tools (story maps and impact maps, for example). They can be cross-checked with other models (the Agendashift transformation strategy model or your favourite Agile implementation roadmap, for example), to find any gaps and help create a more robust plan. Alternatively they can form the basis of a simple working agreement, for example to revisit each category over the course of the next six retrospectives – a 10-minute conversation for 12 weeks of impact!

You can do this too

Are you in the business of Lean-Agile transformation –  a coach, consultant, or manager perhaps? Join our partner programme and you’ll have all these tools at your fingertips. Or you can use the services of one of our growing band of awesome partners, people who know when to put prescription aside, to start listening, and to facilitate rather than impose a process of transformation, a process that takes to you towards the outcomes you want.


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

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

What, no “standup meeting”?

They’re coming thick and fast – another Agendashift release this morning…

Today’s release saw the removal of the term “standup meeting” from our assessment tools. That’s despite this glowing reference to the practice in my book:

If there’s one Agile practice I recommend above all others, it’s this one. I’ve seen teams drop standup meetings when their value goes unrecognized, only to reinstate them just a few days or weeks later as things start to fall apart. Perhaps the very familiarity of the practice makes its value too easy to overlook.

Have I changed my mind? No!

Here’s the old wording of the prompt:

We review our progress frequently, typically during daily standup meetings

And the new:

We share progress on our work frequently and are quick to collaborate as the need or opportunity arises

The old wording stood out as one of the most prescriptive of our 40+ prompts. This matters because:

  • Strong responses might hide dysfunction – for example ritualistic meetings that are achieving little
  • Weak responses might not seem important – “OK, we’re not doing the practice, but so what?” or “We tried that once, and it didn’t work!”

Strong answers to the new wording are more likely to reflect not just an effective practice, but good outcomes in the form of timely collaboration. Weak answers will highlight not the absence of a solution, but the presence of a genuine problem, one that probably ought to be addressed. That’s how all our prompts are meant to work – neither prescriptive nor judgemental but thought-provoking and action-inducing where it matters.

Thank you to Thorbjørn Sigberg, Andrea Chiou and Karl Scotland for valuable help in iterating on that prompt in our Slack community yesterday. Ping me if you’d like an invite.

Do you think you could make effective use of tools like these? The Agendashift partner programme is now open, in a pre-launch phase before we announce our first wave of partners next month.


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

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