The same things don’t always work

Over my years of getting to know Scrum and the agile way of working, I have experimented with a lot of things.  I have found things that didn’t work and I have found things that did.  I’ve kept the things that did work and tweaked them as needed.  They were good tools for me and informed my thinking around how I succeeded using Scrum.

Then I moved jobs.  I took my toolset with me.  And I tried to use my same logic and thinking.  And people heard my words and too often for my liking interpreted them to mean something completely different.  It was very educational and taught me very strongly that The Same Things Do Not Always Work.

Context is King.
If you’ve built up context around certain ways of working then people know how you got there as they were there with you.  They understand.  They emote.  And when you bring those ideas fully formed into another organisation that have strangely not lived in your head for the last couple of years, they don’t necessarily immediately understand or emote.  And this isn’t their fault…

My failure has been in not understanding that my tool set held the tools that I had decided upon by applying the principles that I understood and in order to use the same tools at a new organisation I had to first back away a little and bring out the principles again to see if those same tools would still uphold those principles in this new organisation.

A simple example: Ship when you’re ready
For more than a year I had been working with a team delivering software which was officially shipped on days that weren’t the sprint boundary.  The team were fine with this.  We always aimed to finish before the sprint that we shipped in.  If we could plan it on the boundary we would, but sometimes it didn’t work out that way – and it didn’t matter.  We were completely fine shipping when we were ready – instead of waiting for an arbitrary date boundary for the sprint end.  Everyone was good.  It worked well.  It felt obvious.

Obviously if there was a large amount of work to do and you asked the team to commit, they can’t commit to earlier than a sprint length.  But – if we’re done, we’ll ship – why wait?

And then it didn’t work…
Fast forward to a new organisation.  We have some work to complete.  We have a ship date.  So we discuss and using the previous pattern from my tool set I suggest – if we’re ready we’ll ship.  If we’re not, we won’t.  Somehow this was interpreted down the lines as: we are going to change the sprint length to 1 week and people will deliver by the deadline or else.

What was the simple “if we’re ready we do it, if we’re not, we don’t” turned into an angsty changing the sprint cadence rush to complete.  But that was the organisation’s interpretation of what was, for me, a clear and obvious way of working.

Which made me think
When going into a new organisation – go back to basics.  Say no to all the broken rules – until you know which ones you can safely break without someone abusing the situation.

Another example: Velocity
For several years I had been using velocity and planning stories in a reasonably reliable fashion. The teams I had worked with weren’t highly passionate about velocity but were focused on the work at hand and usually knew what the next sprint or two held and were willing to push their capacity to try and achieve more points in a sustainable way.  The combination of measurement (to aid planning – and replanning every sprint) with knowing what you’re doing for the short term helped ensure that the team was both productive and reasonably predictable.  This was great for building trust with stakeholders who had legitimate concerns about delivery in the past and it also enabled us to go a faster.

And then it felt pointless…
Fast forward to a new organisation. No sizing. No sprints. So I enthusiastically said we should try a little Scrum.  So now we do a little Scrum.  But we don’t use the velocity or plan beyond the current sprint.  And it works.  And no one actually is worried.  And the stakeholders are okay with everything.  And everything is roses.  So why measure?  And why plan?  When you can be agile and make it up each sprint – because the work is still known in a reasonable fashion.  And we’re as successful as is required of us.

The tool set that I brought with me didn’t result in the changes that I anticipated and in fact possible adds little value right now. I suspect many reasons for that.

Which made me think
Scrum isn’t just a framework.  Context remains King.  You can’t just walk in and apply your learning from another context to the new one without understanding the context and working with the people who are in it.  That doesn’t mean you can’t ask questions and make suggestions – but do just that – rather than judging too early.   Agile is about principles – these lead you to the learning and the tool set.  Always go back to the principles and the spirit and validate – particularly when approaching a new team or new organisation with your existing experience.  Unless, of course, you have the remit to cause revolutionary change.  In which case, go wild!

And there is a point
My failures over the last year have fuelled much introspection and learning.  I’ve opened myself up to question myself around my understanding of Scrum and agile.  And I’ve seen very clearly how no one size fits all.  I have found this a powerful learning experience.  Seeing what you know does work not working any more deepens ones understanding of what it is that you’re really doing.  I’m thankful for these new experiences that have allowed me to grow a deeper understanding of what has worked by understanding why it hasn’t worked as well.

I now hope I keep remembering to not apply my tool set too soon in the future in the hopes that I’ll more effectively apply it with a deeper understanding of the actual context.  Or perhaps I’ll find a more universal tool set to apply.

Advertisements