Impact mapping at the first Lean Agile Dundee

Group of people having meeting using laptops
Photo by Rawpixel on Unsplash

Last night I attended the first ever Lean Agile Dundee meetup at the offices of SolarWinds MSP, there were six of us—four Solarwinds employees, another chap and me.

Having attended a few Lean Agile Edinburgh events (the next one being next week at the Skyscanner offices), I was excited to learn there was a similar event starting in Dundee which is significantly closer for me.

Welcome

The welcome was warm and enthusiastic, the platters of food were plenteous and as I sat keenly at the front I chatted with the guy next to me.

“What do you do?” I said, feeling like a member of the royal family for asking that.

“I’m just a software engineer here at SolarWinds.”

“There is no just in software engineer,” I said.

“Thank you,” he said with a smile. “You’ve passed my test.”

A short conversation later I learned that he was also a fellow St Andrews alumnus and we talked about people we knew in common from the School of Computer Science.

Impact mapping

The main (and only) speaker was Santiago Lizardo Oscares, a software engineering manager also at SolarWinds. He spoke about his experience of using impact mapping—a simple planning technique that communicates assumptions.

I’ve used impact mapping a couple of times, mostly when deprecating services so we could clearly see which audiences would be impacted and for making decisions about what to do to facilitate the transition. But it can equally be used when introducing new services.

At its simplest, an impact map comprises four columns, or four levels of a mind map:

  1. Goal (Why?)—Why are we doing this? This is the goal we are trying to achieve. It can help to make this SMART (specific, measurable, agreed upon, realistic, time-based).
  2. Actors (Who?)—Which stakeholders will be positively or negatively impacted? Who are the users? Who can produce the desired effect and who can obstruct it?
  3. Impact (How?)—How will these stakeholders be affected? How should their behaviour change? How can they help us achieve the goal, or prevent us from succeeding?
  4. Deliverable (What?)—What can we do as a delivery team or organisation to support the required impacts? These are the deliverables, the software features, the organisational activities. These can be anything from epics, through user stories to simple tasks.

Much like user stories, the real value here is in the conversations that it encourages within the software development team. As well as reading the diagram from left-to-right, it can also be helpful for developers to read it from right-to-left to trace back from a feature they are developing to understand why they are developing it.

Impact mapping can be a useful tool for writing user stories:

  • As an Actor (Who?)
  • I want Deliverable (What?)
  • So that Impact (How?)

Example

After his presentation, Santiago ran through a practical example with us.

The goal we were presented with was to double the attendance of the next Lean Agile Dundee (probably in three months’ time) from 6 to 12.

We identified the actors as the organisers, previous attendees, and other Lean Agile groups, and then set about looking at how these actors could help achieve the goal—move from EventBrite to Meetup.com, provide incentives, share on social media, word of mouth, etc.

It was a useful example, I’m just sorry that Santiago stopped the exercise after completing just the organiser branch. It would have been helpful to have at least completed the map in full as a first pass, not least because we attendees could have taken away some practical ideas of how to help grow the event.

Conclusion

The evening was over within the hour, but wasn’t that entirely in keeping with Lean Agile. I really enjoyed the evening—meeting new people, discussing useful tools and how to improve communication and processes. I’ll definitely be back and may even offer to give a talk.

If you are interesting in Lean, Agile, Scrum, DSDM, XP, Kanban and live in Fife, Dundee or nearby definitely keep a look out for the next meeting. Check Eventbrite and Meetup for details. I’ll also try to remember to post the next date here.

Find out more

You can find out more about impact mapping in the book Impact Mapping by Gojko Adzic.

Lean Agile Edinburgh meetup at Royal London, March 2018

You can watch the recording of the live stream above.

  • 14:33 Introductions
  • 18:45 Welcome from Royal London (hosts)
  • 23:50 Kathy Thomson—Explain and explore
  • 42:00 Krish Bissonauth—CIA model
  • 1:24:00 Greg Urquhart—What does Agile even mean now?

Last night I took the train down to Edinburgh for my second Lean Agile Edinburgh meetup.

Started in June 2013, Lean Agile Edinburgh is an informal and social monthly meetup to discuss and share all things agile, lean, kanban, scrum, etc. At most meetups we have talks, workshops/activities or Lean-Coffee discussion sessions.

Yesterday’s meetup was kindly hosted by Royal London at their new offices at Haymarket Yards in Edinburgh, a short hop, skip and a jump from the railway station. Last month’s was hosted at the other end of Princes Street, in the Amazon Development Centre Scotland offices at Waverley Gate.

The evening began with an opportunity to network and chat with folks over pizza and refreshments, before we took our seats for three excellent presentations.

Explain and explore

The first session was a very hands-on, get out of your seats and move about exercise lead by Kathy Thomson, a scrum master at Royal London.

We were each given a postcard and pencil and invited to answer the following question in either a word or short phrase: “What does agile transformation mean for you?”

I wrote something like, “Iterative change that is collaborated on by a team towards a shared goal”.

With our postcards completed we were invited to stand in a large open space to the near the presentation area, and turning to the person next to us explain our answers.

Next we were invited to exchange our cards with someone else, and then someone else, and so on until we had effectively shuffled the cards. I ended up on in the middle of the room. This was the ‘explore‘ part of the exercise.

And then again we were to pair up with the person next to us and explain to them the card we were holding. Which, obviously, was now not our own card. Interestingly, I felt less defensive about explaining this card. And I appreciated seeing someone else’s perspective on the same question.

Somehow, I ended up with two cards for this one! And I can’t remember either of them.

And then we were off around the room again, quickly exchanging cards, and pairing up to explain our new cards to one another. Mine simply said, “Pace”.

It was a really interesting and useful exercise, even with a room of about 60 people.

Control Influence Accept model

Returning to our seats, Krish Bissonauth, an Agile coach at Royal London, introduced us to the Control Influence Accept model (or CIA model).

This is a versatile problem-solving and stress-management tool that identifies three ways to respond to challenges:

  • Control—identify the elements of the situation over which you have control.
  • Influence—identify the elements over which you have no control but which you can influence.
  • Accept—identify the elements over which you have neither control nor acceptance, which you will simply need to accept and adapt to.

I loved the Clarke Ching quote he finished with. It spoke about social comparison—why do your Facebook friends’ holidays and kids look so much better than your own? It’s simple: their lives are just like ours but they only share the good stuff. So it is with books we read and presentations we experience about Agile and DevOps: we see the good stuff and we feel bad.

His message: stop comparing yourself to the “Facebook” versions of Agile and DevOps, and start comparing yourself with how you were doing three weeks ago, three months ago, three years ago, and feel proud of the all the hard work you are doing and the progress you have made.

What does Agile even mean now?

The final talk was by former Skyscanner product delivery director, and current Agile 4-12 consultant Greg Urquhart.

There was much in Greg’s talk that resonated with me, but it was what he called his “cut the Agile bullshit-o-meter” slide that I found most helpful. He had set himself the task of limiting his definition of what agile is to just five bullet points. This is what he came up with:

  1. A culture of experimentation constantly generates validated learning.
  2. Teams have missions, mastery and the autonomy to act with no strings attached.
  3. Software is frequently delivered to users. We learn its value through serious use.
  4. Teams and resources align beautifully to strategic objectives at all times.
  5. Minimum viable bureaucracy.

If you’re not doing these five things, he argued, then you’re not agile.

Towards the end of his talk he advocated for what he called scientific engineering (learning work) and argued that this more than lean and agile (knowledge work) would bring about the most effective and productive change.

This aligns with another talk I attended recently in Perth at the Scottish Programme and Project Management Group conference, where one of the speakers encouraged all the project managers and business analysts in the room to start to get familiar with big data and data analysis. It’s what the most valuable companies in the world are doing—Apple, Google, Amazon, Facebook. They are using data (massive amounts of data) to design and refine their products.

I walked away from last night’s meetup feeling encouraged and more animated. It has certainly given me a lot to consider, a couple more tools under my belt, and a little more clarity about the direction I want to take my career.

Thanks Lean Agile Edinburgh.