Business process modelling at Lean Agile Dundee

Last Thursday evening, I gave a presentation entitled ‘Using business process modelling for creating a definition of ready and definition of done’ at the second Lean Agile Dundee meet-up at SolarWinds.

Continue reading Business process modelling at Lean Agile Dundee

Agile is a toolbox

While it’s true to say we use the Scrum framework here at Vision, that’s not the whole picture. As Bertrand Meyer says in Agile! The Good, The Hype and the Ugly (Springer, 2014), “every agile team in the field makes up its own cocktail of agile practices, rejecting the ones that do not fit” (p.vii).

In terms of project lifecycle and team management practices, we are fully embracing Scrum. But Scrum has little or no opinion about engineering and delivery practices, which we complement largely with XP methodologies. The Scrum model assumes the development team will work with a product backlog but has no guidance on how that will be created—tools from AgilePM, DSDM or even PRINCE2 might be considered to supplement Scrum. (I’ve not been with Vision for long enough to fully understand how this is done here but that will come.)

Since I was introduced to it, I’ve always considered myself a proponent of agility rather than being partisan to any particular flavour or methodology: XP, Lean, Scrum, DSDM, Crystal, etc.

My agile journey

I was first introduced to agile through XP (extreme programming) having picked up a book at the 2008 Scotland on Rails conference in Edinburgh. (Memorably, that was the same day my then-wife learned we were expecting twins!) The keynote speaker spoke eloquently and persuasively about how agile approaches to software development had brought huge benefits to his team. I was hooked. I raced home, read the book from cover to cover and began to implement the ideas in my own team.

Then the university I was working for embraced Lean and I was introduced to its five principles, eight wastes, kaizen, kanban and a host of other useful concepts. I saw first-hand how empowering teams to own and change their processes reduced waste and improved productivity, effectiveness and team morale.

Latterly, it was decided that our team should embrace DSDM Atern. From a project management perspective, DSDM/AgilePM is the most complete. I have a terrific fondness for both its structure and flexibility.

Agile toolbox

Beneath the umbrella term ‘agile’ we have a toolbox of practices. Some have been codified into highly defined systems like AgilePM, DSDM and Scrum, others like XP and Lean feel more like loosely-related methodologies grouped into adaptable frameworks.

Within each there is the freedom to mine other disciplines for best practices: business analysis techniques, MSP, P3O, traditional project management tools, etc.

Just as you wouldn’t chastise a plumber for using a joiner’s hammer, it makes no sense to prevent an agile team from using a technique from another discipline if it does the job.

None of the frameworks cover everything. It makes perfect sense to supplement them with tools from elsewhere. DSDM makes that explicit: “for most organisations, DSDM is all that is needed,” the handbook proclaims, “although some gain value from integrating DSDM with project management methods such as PRINCE2 and PMI, or detailed development techniques, such as extreme programming (XP).”

This is one of the most helpful diagrams I’ve found that demonstrates the relationship between agile methodologies and how they complement one another:

Diagram showing agile method coverage

Diagram credit: Agile Project Management in Easy Steps by John Carroll (2012)

Over the next few weeks, I expect my blog posts to focus on aspects of both Scrum and XP in particular, exploring in more depth some of the tools we have access to in our agile toolbox.


Originally published on my work internal blog.

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.

Lean University

I had a great meeting with the University’s Lean team this afternoon.

Lean use elite ninja-like skills to focus on a process, to ensure that it is as waste-free as possible. Key Lean principles are:

  • identifying and eliminating waste
  • continuous improvement of processes
  • ensuring that each stage in a process adds value

Toyota pioneered Lean Manufacturing on these principles in the 1980s and revolutionised automotive production. Toyota is now the most successful automotive production company in the world.

So now you know.

Oh, and the team are fantastic, lovely people.