Our processes on the bingo platform team at tombola are focused around working on those things that add value to our customers (either directly or indirectly) – we try to steer all of our work towards that goal, and work in a way that helps us flow through that customer value adding work in as efficient a way as we can. As a team we focus on ongoing improvement (of process and selves) within this flow, and attempt wherever possible to ensure that where we see constraint or pain in any of our work, we drive efforts towards minimising or mitigating.

We release regularly (many times during a two week time box), and we find the retrospective ritual once every two weeks adds great value. We are a team that values trust and safety in all of our communication. This period once every two weeks to have open, honest, and shared crucial conversations about all that has happened during that period, with an aim to actioning those things that we wish to improve, helps us on that pathway of ongoing improvement.

We have been focusing more heavily recently on the ‘Flow’ of work – taking in all of the theory that exists around constraints, work flow, lean, etc. and seeing if we can achieve better delivery of value to the customer while systematically improving our processes as we go. One of the areas we struggled with (as all teams do) was visibility of work outwith the customer value adding work. What does success look like?

  • Did we deliver upon our agreed goals during the past two weeks?
  • Did our key measurements look good (Mean Time TO Recovery, Change Failure Rate, Lead Time, Deployment Frequency)?
  • Did our customers respond positively to the work we delivered?

(I hasten to add, we’re still in our infancy in tracking and awareness of the above, they haven’t become ingrained yet).

If we were successful, do we know where we weren’t? This is a more challenging one – if we delivered on the key metrics above, is that enough? What about the things that didn’t go so well or could be improved upon? How do we track those?

Introducing the Waste Snake

We were aware that although we have been flowing through work well, goals being hit, etc. that there were things each day that were taking us away from adding customer value.  Since one of our drivers is about making work visible, we knew that there were things we as developers did that didn’t contribute (directly or indirectly) to customer value, and weren’t part of our planned work.  Some of these were minor, some less so:

  • Releasing the website (which although mostly automated, still has some manual testing/checking)
  • Meetings – discussing current or future work, or anything really
  • Chores – OS reinstall, etc.
  • Blockers – waiting on a dependency for any length of time
  • Service continuity – live site issues, investigations, etc.
  • Learning – did you have to interrupt delivery to gain the skills necessary to deliver value?
  • The retrospective itself – will talk about this below

We talked to other teams within tombola, and after discussion and review, we looked at The Waste Snake as a means of helping us understand, categorise, and visualise these things.  We came up with our own definitions of how and what to Feed the Waste Snake (if that document is at all useful, feel free to adapt and apply in your own environment). We even came up with a delightful visualisation of it so that it was absolutely clear when waste was being generated, which could either trigger immediate discussion or become a talking point for the retrospective.

We ran with it for a time box, and during the first retrospective, a number of issues were discussed.  Key among them (even with the guidance) was around the emotive use of the word ‘Waste’.

I deliberately added ‘Learning’ and ‘Retrospective’ above to the list of things that would constitute waste, as they’re a different kind of waste, and not in the slightest bit bad, but under the guidance they fully qualified as ‘waste’.  We weren’t adding customer value and they weren’t (immediately) contributing to the agreed iteration goals that the team was working towards.

They’re both positive elements – they’re investments, they’re the team focusing on how to best serve those goals in future, and improve processes, practices, and self so that the future version of us looks better than the one today.  That’s awesome, though obviously needs to be recorded so that we have that visibility on non-value adding activity so that we can improve upon it and aim to find a way to reduce it going forward.

The team really struggled with the word ‘Waste’ for some of the activities that they wanted to record up there.  For example, spending some time learning terraform so that you can better work on a pipeline improvement task, or spending some time learning vue so that you can better deliver a front end improvement for the customer.  Or crucially, spending a few hours every few weeks talking about things that we’d been through in those past two weeks (a la retrospective).  These are all really positive, growth activities that really help the future version of the team be better.  They’re not ‘waste’ in the traditional sense.

Could we have just changed the definition of waste? Yes, we could have done, but it was the word that raised the most concern.  Humans are fickle creatures, and our language is laced with nuance and implication, and the word ‘Waste’ conjures up something that is generally considered negative, and some of these activities although not immediately positive, are not easily categorised as negative.

Is the waste snake the wrong approach? Absolutely not.  The good thing about all of these processes, rituals, and approaches is that with a mature, collaborative, trusted, safe team you can adapt these to your own local situation.  The waste snake is a brilliant idea, and we wouldn’t have arrived at ‘what works for us’ so quickly if we hadn’t first ventured into the land of snakes.  But as with all of these approaches, there’s never a ‘one size fits all’ approach, and I’m lucky to have a team that adapt and feedback very well to my experimentation of new processes and practices, and we arrived, as a team, at a solution that feels like it’ll be a better fit overall for our culture and mindset.

The Wast Snake is dead, long live Sloa Constrictor!

A snake by any other name would still ssssssmell as sweet? (sorry).  We have adapted our own guidelines after discussion within the team, and we decided to go with a new name for the waste snake.  He still wants us to record the same activities, he still feeds on all of those things that take us away from adding value for the customer.  He’s just not so uppity about the terminology!

The team feel more comfortable about recording activities that aren’t necessarily waste (and indeed, could be considered investment or future growth), but still take them away from adding value, and we’ve lost nothing in terms of our overall aim through this of making our work more visible.

Moving Forward and Discussion – The ‘Agile’ monster

I almost got through this whole article without using the word ‘agile’ – it was deliberate, and it’s born out of my own learning pathway and the discoveries I’m making there around the community at large.  It’s fascinating that the more time I spend trying to become a better leader to my team, and help them flow through work better, the more it feels like I read daily about how ‘agile’ is both an anti-pattern and a dirty word.  People applying ‘scrum’ without thought, people adopting rituals without truly investing in the ‘why’ behind them, or indeed truly then evaluating whether those rituals, process, and practices are actually working and adapting them.  For that team.  In that context.  In that small part of the overall picture.

As you’ll see from above, we do indeed follow some practices and processes that we as a team feel help us with ‘flow’ and help us while we focus on delivery of value.  I see a lot of apologists and a lot of posts as used to happen years ago around the move away from ‘.net’ – ‘If you’re doing it like that, you’re doing it wrong’.  I would describe our approach under the umbrella of ‘agile’ though very heavily adapted for my team and our culture and approach.

We’re not sure yet whether the sloa constrictor will be the answer to helping us with making work visible, but we’re bought into the investigation, and we’re bought into the ‘why’, so we’ll see how that plays out.