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.


Permission to Size ScrumMaster?

When I first heard about Scrum one of the distinct messages I heard was of a planning meeting where all involved in the product – devs, testers, business, managers, etc – all sat in a meeting and played Scrum poker in order to agree on the relative size of the work.  This translated into a beautiful scenario where everyone involved bought into how much work is being done and at what rate as they were all jointly involved in the sizing of the work.  There was no frustration at the rate of progress as the velocity was understood and the sizing was communally agreed upon via conversation and mutual understanding.

This is possible a utopia.  But it is an interesting perspective on the sizing game and group buy in.  I’m not sure anyone actually does this.

In a previous post – The dual faces of Sizing – I identified two types of sizing that may occur on a Scrum project.  I avoided the question of who exactly was doing that sizing.  Is it the utopia of all stakeholders who care?  Or is reality, necessity or practicality different from the utopian dream?  And is that utopian dream even desirable?

1. Who sizes for release planning?

Ideally you want the entire team involved.

However you might be able to get good enough with someone who is both familiar with the new stories – possibly having been involved in understanding them and writing them – and who also is highly familiar with the team’s sizing and therefore can give a reasonable approximation as a team proxy.

If you do this, measure the changes so that you can understand the amount of change for future planning.  Metrics are your friend – if you measure, and if you use the measurements effectively to become more predictable in the future.

2. Who sizes what comes into a sprint?

Going back to the opening story – should the business people be involved in the relative sizing of the work that they will not be doing.  No.  Yes.  Maybe. Maybe not.  It depends.

Here are some options – and some ideas as to why it may be good or bad.

a) Only those that actually do the work have a say in the sizing

On the one side, sizing should be an activity for those who do the work.  They actually have to do it, so how can anyone not doing the work actually say anything about the size of it?

The complication of this model is who is “the team”.  Is the ScrumMaster in the team or outside?  Is the Product Owner in the team or outside?  Is the architect who writes no code but acts as an acceleration agent in the team or outside?  It becomes difficult to differentiate who is in and who is out.

The biggest pro is now the team has defined how big the work is.  They buy into the size of the work and they will be the ones committing to doing the work.  This model allows them to have the whole say as to what the work is.

I suspect this is what the majority of teams are doing.  It avoids some dysfunctions by not allowing them to be options (like overpowering stakeholders) and it fits into the ScrumMaster mantra of “Protect the team” and “Let the team decide”.

b) Everyone can come to the party

On the complete other side, collaboration is a key agile concept, including everyone in the process increases the common buy in and understanding of the impact of the work.  These discussions can allow for increased transparency and buy in to the rate of delivering the software.  This could be incredibly powerful for group ownership of the deliverable and allow those not doing the work have a say in the destiny of the project.  It allows them to feel like they can impact the deliverable by them understanding what the impediments and the time sinks are.  This can bring the discussion far closer to allowing the customer direct input into what they actually get – not only with the final solution but also the trade-offs along the way (speed vs features, etc) – which is a good thing.

The difficulty with this model is that significant issues can arise if the relationships with all involved are not of an equal level.  If the CEO is involved with sizing then s/he may significantly overpower or influence the process which may lead to the process becoming meaningless.  If you have a dysfunctional situation in your environment then this is the worst thing you can do as it can significantly impact the team buy in to the size of the work and could be a failure in ensuring the team is protected to do the work the way they feel best.

c) Everyone who has value to add to the conversation should be involved

Is there a middle ground between options a) and c)?

The complication with option a) is that it may exclude people who have valuable insights to offer.  If you exclude the Product Owner from the sizing activity you may lose the conversation that shows that the team has misunderstood the requirement that the PO is putting on the table.  If you exclude other individuals who have value to add, you may also lose their conversations that may help in identifying the full extent of the work.

There are variations on this model – perhaps you could have the PO and/or other involved parties provide the sizing after the initial team sizing.  This allows the team to understand what they believe the work to be – while adding in the additional conversation from the PO and other interested parties after the fact.  This two phase situation would only be needed if there is a dysfunction that allows the team to be overridden by individual power structures.

A dysfunctional example – minorities must have a say!

An example of this dysfunction could be a team with 4 developers, 1 tester, 1 PO, 1 ScrumMaster, 1 Usability expert, 1 document writer all sizing the work.  If the goal of planning poker is to pick the majority view, and the tester, PO, usability expert, doc writer and SM all are voting – and they vote an 8 when the developers are all voting a 13 – by the majority view the story is an 8.  But this may be a dysfunctional decision.

In an equivalent example, assume a team of 4 developers, 1 tester.  If they are the only people voting and the devs all vote 8 and the tester 13 – again, by the majority view the story is an 8.  This too could be a dysfunctional decision.

In both of these examples – the minority needs a say.  If a tester identifies that the testing of this item – their activity – is going to be a significant amount of work on a given story then they need to identify this and the team needs to acknowledge this in the form of discussing and perhaps accepting the tester’s sizing over their sizing as there are factors that they aren’t taking into account when thinking about the sizing.  This is the point of planning poker.  The key is conversation.  The ScrumMaster needs to facilitate this activity to ensure the voices of the minority are heard and not squashed.

So should the Product Owner size?

It depends…

If the PO is going to attempt to significantly influence the team – then no.  If the PO is using the voting opportunity to show up disparities in expectations – then yes.  The difficulty is to work out the POs intentions and to respond accordingly.

The other key reason for the PO to be involved in the voting process is to perhaps engage with a discussion on how we can simplify the implementation.  But that could be done with voting or as just a conversation around voting.

The key problem with a PO voting is clearly that they often are leaders in the organisation and wield more influence in the team and hence may cause problems as a result.  Manage that, and things will work themselves out well.  In fact it may empower the team more by having the PO involved and allowing the team to see that they can vote their way and not be overpowered.  It depends on the PO…

So should a ScrumMaster size?

It depends…

If the SM is going to reduce their ability to facilitate the voting in the previous dysfunctional examples then they should not be voting as their involvement could make them appear partial to a given outcome.

However if the SM is a team member – delivering software as well (which is not an uncommon formation in a Scrum team) then they may have value to add by voting with their team role hat on.

Another scenario that I can see is if the SM is the longest serving member of the team –who has domain knowledge and understanding.  Perhaps they were team members before they transitioned to the SM role, perhaps the rest of the team is newer than them.  In these scenarios excluding them from the sizing activity may lose valuable insights.

However in these scenarios the SM could come in with secondary questions such as – I thought it might be an 8 because we may need to integrate with the old email client which has a difficult monolithic interface – what do you guys think?

To close

I’m not sure the utopian idea of everyone group hugging and agreeing jointly on the size of the work in a meaningful way would occur in reality.  It could be a good experiment.  But it might be messy.

I have always sized as ScrumMaster because I’ve had good insight into the work that the team has been doing.  However in the current organisation that I’m in, I can comfortably sit back and not size as I don’t have the history and I don’t add value to the equation for sizing yet.  So for now, in my currently role, I won’t be sizing anymore and I’ll monitor how that goes.

I noticed most POs prefer not to size – or don’t take sizing too seriously.  Either way, that’s fine with me.

The key goal is as a conversation enabler to allow deeper understanding.  That, and as a metric to help measure the rate of progress in order to approximate the range of potential delivery dates of course!