Scrum anti-patterns – its more than just velocity babe

I wanted to write about some of my on-site experiences with Scrum delivery in inexperienced teams over the last year or so. I often see some anti-patterns management teams often make and the impact that can have on individual teams can be considerable. There are a few mistakes I see coming to the surface with the most inexperienced teams so wanted to list them here. Maybe you recognise some of these in your projects?

You do not need to know what Scrum is, you have an Internet connection, so Google that (!) but let us remind ourselves of those important Agile Scrum values;

• Value individuals and interactions over process and tools
• Value working software over planning and documentation
• Value collaboration over contracts or negotiation
• Value change and flexibility over adherence to plans and specifications

Personally, I think there is a few more we could add;

• Remember people are human and that influences the product
• Metrics like velocity and story points only make up part of the picture
• Be realistic over blindly following an academic scrum approach

Now what I tend to see in the more inexperienced teams is a correlation between lack of delivery experience and the amount of lip service paid to all the above values. You see for Scrum to work, it is one of the few elements of working ‘agile’ that you really must respect the process and subsequently follow properly.

Image references: age-of-product.com

A lot of management teams often struggle with elements such as trust along with things like;

• Setting a target for velocity

Velocity, the most important metric in Scrum, is meant to be an entirely empirical and is meant to be used for estimation – not a goal or a metric by which team performance is measured. Yet what I see is management teams set velocity targets which are often not only misleading, but entirely subjective too. Setting a target of say 60 points per sprint might be meaningless, because what represents 60 points is subjective team to team.

At the same time, velocity *is* something that is within a Scrum team’s control, and it should be upheld and improved over time, but you cannot just set a velocity target! Management teams should help teams improve processes and remove obstacles and not set a quantitive velocity goal.

• Expecting immediate turn-on of maximum velocity

All Scrum teams need to be allowed to get into a ‘rhythm’. Teams spend time building relationships and learn how to cooperate and split work between team members. They need time to understand what is being built and why. Managers *must* allow teams to mature and realise their full potential before estimating velocity.

• Testing, Debt, Maintenance and known bugs along with a touch of slack

More often that not, I see inexperienced Scrum delivery teams working so hard on delivering story points (sometimes through pressure of management having incorrectly set a velocity expectation) that time in-sprint for things such as bug work, testing, maintenance, and flagging and addressing technical debt is forgotten about. Also, a bit of time in-sprint to allow for slack, somewhere between 10-20% I would say.

There can often be a lot of pressure to deliver ‘feature’ and ‘value’ but without investment in quality, the product will suffer over time anyway and move slower in the long run.

Being Human

As I say a lot, there are fleshy human beings in every team. With their messy emotions, feelings and thoughts. A quality Scrum lead will always consider this and remember whilst Scrum is just a framework, careful application of sensitive and ethics-based leadership will get the very best out of your team more often, than an iron-fist approach.

I work a lot with offshore development teams and unless you have spent time out there with them you often as a Scrum master don’t get to see the world from their perspective. In all my projects I’ve recommended the clients management teams and potential customers of the thing being built get a chance to meet the teams, whether it’s a far-flung place in Calcutta to across the Atlantic in the US. Whilst it sounds a luxury, not only building a proper trusting relationship with one another makes a huge difference, it’ll greatly increase how you work far more than just implementing Scrum academically.

Top Tips

Leave room for growth – if you overload and pressure a scrum team, they will often fall over just like real life (!) so, leave a little time for unexpected stuff, problem solving & time to breathe. Your team will thank you for it and you will reap the benefit in the quality of the product.

Use Empirical data to manage expectations – Give the team time for stormin’ formin’ and normin. THEN you can estimate around velocity. Setting unreasonable goals at the outset pushing the team to go faster will encourage them to forget what they are building, and instead to focus just on points delivery.

Summary

If you’d like to know more about Agile, read some of my content here about why be Agile, or why not take a look at Agile Project Management here or if you’d like some consulting (virtually of course) head over to my sister site, MD Technology, my little company that helps organisations get a little bit better at Agile delivery.

Have thoughts, opinions or would like to comment, grab me over at Twitter (@mariodc) to continue this conversation

References

32 Scrum stakeholder anti-patterns https://www.scrum.org/resources/blog/32-scrum-stakeholder-anti-patterns