Fixing Your Scrum: An Interview with Ryan Ripley

And Ryan's take on scrum anti-patterns.

I was fortunate enough to catch up with Ryan Ripley last weekend, author of the highly popular book Fixing Your Scrum.  I discussed his take on scrum anti-patterns, plus other things agile related, including his insights on scrum values and the future of agile. The format of this blog is written in an interview format, to help convey all his insights from our interview.

About Ryan Ripley

A professional Scrum trainer with, Ryan Ripley has worked as a software developer, manager, director, and Scrum Master at various Fortune 500 companies in the medical device, wholesale, and financial services industries. He is the host of "Agile for Humans," the top agile podcast on iTunes. Ryan lives in Indiana with his wife, Kristin, and three children. He blogs at and is on Twitter @ryanripley.

The Interview

This part of the interview we kick off talking about anti-patterns and how Ryan’s insights can help you overcome a lot of common mistakes that happen from early adopters of Scrum right through to the most experienced.

What do you consider an anti-pattern?

It is typically things like changing the Scrum Framework or performing one of the roles in a way that was unintended. Doing something that is not helping your team to deliver. There are so many different patterns. Like trying to change something that doesn’t really force you to deal with an impediment.

In the book (Fixing Your Scrum), we actually use some strong language around the responsibility of the Scrum Master. A lot of the anti-patterns we discuss in the book comes from Scrum Masters not fulfilling their role correctly.
As a Scrum Master, if you have tolerance for an organisational impediment, then get out of the role. Scrum Masters should have zero tolerance for impediments that prevent their team from delivering valuable increments of product each and every Sprint.

Can you please walk me through some examples of anti-patterns that new teams might make?

Would it be the fault of the Scrum Master, or wider organisational dysfunctions...

The world is complex and there are many things going on here. Part of it could be the Scrum Master only working with the development team. The Scrum Master might come from a programming background or project management background. So, they may be very comfortable with technical people, or comfortable with product people, but they don’t spend enough time with the wider organisation — with the leaders, with stakeholders and with the management.
Photo by Hello I'm Nik 🇬🇧 on Unsplash | An Agile mindset can lead to magical things!
When we describe Scrum, what we really mean is embracing an Agile mindset. So we see the same team colliding with this brand new framework and then you see some things that you mentioned right, you see… people waiting for work, Scrum Masters coding. 

Even worse you see stakeholders sneaking in and assigning work — part of it is the Scrum Master not being in the organisation, coaching, teaching, training and mentoring. And I think part of it is the development team needing to step up and take part in this as well because if you look at the Scrum framework and the Agile Manifesto - the seventeen people that signed the Manifesto, these were developers that wanted a better life for people writing code.
"If you look at the scrum framework — it was designed to decentralises decision making to the Scrum team and often directly to the development team. Can you imagine how this could collide with the way many organisations are set up today?"
A big anti-pattern is people taking a legalistic view of the Scrum Guide. For instance, Product Owners that only owns value, Scrum Masters the process, the development team only delivery. The Scrum Framework demands a collaborative working relationship.Working together to find ways to deliver working software frequently. All three roles can help one another out, yet we often see extremely strict boundaries that don’t really help.
Photo by Vek Labs on Unsplash | With Agile, it is all about moving forward together.

What about team performance compared to ‘velocity’ How do we gauge performance?

Performance means — can a development team deliver an increment of product or software frequently? Are these increments actually valuable to customers? Are we getting good outcomes, are we getting good ROI?

At we have evidence based management which is all about measuring value and performance. The team’s ability to deliver on an idea quickly – those are the kind of things I want to talk about. Velocity is a capacity measurement. Can capacity change the world?

What would a team use instead of story points if they were estimating?

Daniel Vacanti, brought Kanban to North America. Through him I’ve learned to appreciate techniques like measuring Throughput, WIP, Cycle time, Item Aging. If you can measure and manage to those four lean metrics, I believe you will get far better outcomes than just measuring velocity.

In addition, physical team boards are a good practice. If we make our progress as visible and as transparent as possible, then stakeholders are less likely to be confused about the progress the Scrum Team is making towards the Sprint Goal and the larger product vision.

The trade off is that if progress is transparent, then developers don’t have to sit through status meetings. Does that sound good to you? That is a good trade off for everyone.
“Changing the behaviours of a team will eventually change the behaviours of an organisation.”
Values then build up on each other. It is a journey. We make a lot of mistakes each day. Scrum values, needs to be embraced by everyone. Scrum Values is a baseline for behaviour.

Why can’t you scale Scrum?

Simply because companies are not doing scrum well with one, two or three Scrum teams. Companies scale way too early, if you scale too early without getting the basics right you just scale the current disfunction to a higher level. That doesn’t sound good, does it?

Why is Scrum your driver?

I believe in empiricism. Our work is transparent, we can inspect and adapt. In my opinion, Scrum is the best way to bring empiricism to product delivery and companies as a whole. You get to look at real data, align and deliver. For me it is empiricism fuelled by scrum.

When I see bad scrum or dark scrum, deep down I know we can make lives better for people doing the work. It kills me when people fall into anti-patterns. If more people read Fixing Your Scrum, lives can be changed, products would be better and work more joyful.
" I am driven by the lack lack of professionalism in our industry. Scrum — done well — can help bring professionalism to our work."

Will Scrum be practiced —10 years from now?

Yes, 20 years in and we are still just figuring it out. At we now have a course on Professional Scrum with Kanban, bringing Scrum and Kanban together. In the next ten years it will be Scrum/Kanban, Scrum and UX/UI etc. It will be a lot more inclusive towards the framework. I am looking forward to being part of the journey.

To find out more about Ryan's book, click Fixing Your Scrum.

I would personally like to thank Ryan and his team for the opportunity for the interview, good luck with the book!

Until next time, keep it agile!