‘Scrum doesn’t work’

I recently read an article where the author expressed the need to ‘retro’ scrum. It was a lamenting tale of experiences had where the methodology seems to have been applied in a very draconian fashion without any real nod to why the framework exists and when executed well, can really empower innovation, teams, and value.

Disclaimer: I think scrum done well does actually work in a lot of instances….

This is not because it is my job to do this, but because I have spent the last *ahem* years watching it done well, badly, and catastrophically in some cases and have invested time in understanding the why behind the perceived madness. Let’s look at some myths that I was reading about today:

Myth: Scrum favours process over people

In the quest for agility, it is a regular occurrence where I have people tell me that agile means doing what you want and that there are no plans because any type of process is bad. This is NOT what this value means. Just because the agile manifesto values people over process does NOT mean that you can only have one or the other.

Scrum is a framework. Think of a house. You have the roof, the walls, the foundations etc. Each of these things has a purpose to add value to the main goal in keeping you dry, warm, and housed. It serves to provide you the people with what you need to thrive. If you remove a supporting wall, the house could fall down and it no longer serves the people at all. You can remove the supporting wall, but you better know why it is there, what it does, and have something to replace the outcome it is there to achieve. Scrum is exactly the same as this, if you take away something that is designed to facilitate a specific outcome and you do not replace it, you easily can enter chaos. In this case, it means that your people could actually have less freedom to solve problems as they need. For example, the purpose of a sprint review is to assess progress, the purpose of the work, feedback, direction, and to collaborate on all these points of the product with the PO, the team, and stakeholders. If the ceremony isn’t working, a good coach will work with the team to better deliver the outcome so that the team is empowered to achieve the same collaboration so the house doesn’t fall down. A bad coach will just force the point and you are stuck with a wall that hides the bathroom door…

In short: Scrum provides a people-centric framework to empower collaboration and discussion over rag statuses and output-driven lists.

Sounds pretty people over process to me….

Myth: Standups are for management

Wrong. Wrong. More wrong. For those out there who are unfortunate in having the following scenario, please bear in mind it is totally anti scrum to do this. How many times have you seen this?

1. Team very begrudgingly stops working to stand up somewhere and mumbles something about this being a waste of time.
2. Scrum master gets up the jira board on a screen and asks everyone the following questions: What did you work on yesterday, what are you working on today and what blockers do you have?
3. Members respond roughly thus: Yesterday I worked on TIC-145 and is finished. Today I am working on TIC-167 and no blockers
4. Scrum master asks ‘have you updated the board?’ Dev probably responds no and the scrum master updates the ticket status and reminds them they should do this in future.
5. Scrum master then asks for project-based updates on what is happening to the said ticket to be able to report back to the PO.
6. Rinse and repeat.

If this is your life, it is not scrum.

Most people are shocked when I tell them that the only people who the daily scrum is for is actually the scrum team alone. The team may invite the scrum master to facilitate the ceremony as a coach and provide feedback on improving it but that is all folks!

The scrum guide was updated recently to become much more outcome-focused in the stand up. The whole point is to provide a time-boxed space for the team to align in achieving their sprint goal and the questions have changed. I like the following:

1. What progress has been made towards the sprint goal?
2. What are the next priorities to tackle to achieve the sprint goal?
3. Is there anything that is currently putting the sprint goal at risk?

It is not about tickets, it is about collaborating with each other, aligning effort, and assessing any need for adaptation or pivoting either from learnings or outside influences such as unexpected dependencies, etc. Much more useful for a team to be able to work and certainly not a check up on if the team is doing what you think they should be…..

Myth: Tickets are everything, quality is missed….

Self-organising teams that are a slave to moving tickets across a board as dictated by a scrum master are not actually self-organising. A good scrum master coaches a team on navigating challenges during self-organisation and helps to remove impediments that challenge that environment. The very famous triangle of time, cost, and scope are all moveable but one thing never is quality.

Let me introduce you to the definition of done and working principles. I love doing team kickoffs/reboots where we look at the team mission, ways of working, and definition of done. It covers all the bits that less experienced scrum masters always miss: how do we achieve incremental shippable products that excel? Someone may say that something is done, however, the definition of done and the principles of work to support it to ensure quality may look very different. In teams I have worked it has often meant the following basic steps:

1. Design of solution is thought of and preferably collaboratively sense checked to make sure it is delivering the expected benefit. This is just a chat amongst colleagues, sharing is caring.
2. Code written
3. Tests are written (swap 2and 3in TDD which is preferable)
4. Tests pass
5. Code peer-reviewed
6. Feature now production-ready
7. In CD environments: feature now in production

At each point, there is a quality-driven step to ensure that we are delivering value and excellence.

Tickets are there to help you, if they become your stick to beat people with, you are doing it wrong.

Myth: Mythical estimation in story points is, well, pointless

Have you ever been forced by some PM to commit to a timeline that is utterly plucked out of thin air based on something that might be similar? If you have, you probably also know that the timeline you committed to is very unlikely to be accurate and becomes very much about output rather than the value-led outcome…

By focusing on effort rather than time, the scrum team can address lots of things like complexity and dependency to determine whether or not they can commit to delivering the value in a sprint (i.e a timebox, not a date), and if they can’t, what needs to happen to the problem to make sure it is a continuous process of value delivery rather than a long slog of endless now whats. The secret to the success of this is measuring the ROI of business value rather than the features delivered.

When I was in one of my roles, the budget was set to how many story points would be delivered. I flat out refused. Story pointing is absolutely there to measure how the team is learning, be able to prioritise based on how much value it would deliver vs the effort to create (ROI again…) and improving their performance along with value delivery and in being able to, with confidence, commit just enough to deliver it. Time is managed in the sprints, not the points, and delivery is the benefit that the shippable increment provides, not the lines of code. Here is where you might want to employ something like OKRs but that is outside the scrum framework as a supporting exercise. A different discussion!

This does not stop experienced people from being able to say you know what, I reckon we can prioritise that to fit your timelines at all and provides insight through collaborative discussion into how realistic to surmise when that might be.

If you are using it to purely replace time — again, you are not doing it right… However, story points aren't actually in the scrum guide. If you don't do them, you could very well still be doing scrum right…

Myth: Retrospectives are boring

This, quite frankly, can be one reason of many. The most likely ones are that the session is not being used to truly learn and adapt, or that the scrum master is not challenging effectively, or actually that the team are so disempowered that the only thing they can talk about are the basic mechanisms of how they are not being supported by others and that they all experience that together and manage to deliver some of the stuff regardless.

Retrospectives are all about learning how the team can experiment to become a happier, more effective, and high-performing team with purpose and value delivery at its heart. If you are not using that as your goal: You are not doing scrum right…

Reality: In essence

The real outcome of this anti rant is really to say that you may have a scrum master fresh out of their 2 day certification, but ways of working, value-driven delivery, and collaborative innovative working with scrum are so much more than the bad practices we so often see. Come see me, I’ll sort you out! If it still does not work, luckily there are many more different frameworks that solve different problems that might do the trick :)