Scrum — The Imitation Game
We all have heard about Scrum and Agile. Some of us even think that we work or worked with it in the past. But the question stands: did we really worked with Scrum or any agile framework? Or did we just follow a recipe?
Let’s start with what is a framework:
a supporting structure around which something can be built
So, it’s not a recipe. It’s a “supporting structure” which actually means that if you use it as a single source of truth, then you aren’t doing much.
The Scrum framework is not prescriptive, it’s actually about people and interactions, a way to answer rapidly to constant changes that arise when we tackle complex problems.
When we learn about Scrum there are three major topics that stand out:
- Empiricism — Inspection, Adaptation, and Transparency.
- Scrum events — Sprint, Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective.
- Scrum artifacts — Product Backlog, Sprint Backlog, and Increment.
But there are common mistakes and myths when we look at these topics and try to apply them. In truth, even if you do/use all of them it doesn’t mean you are doing Scrum or even being Agile… Sorry!
I’ll explain…
I do all the Scrum events and therefore I do Scrum…
Common mistake… Just because you do all Scrum events doesn’t really mean that you are using Scrum.
Scrum events, and Scrum itself, are used to maximize value-added to our client. There is no use of having a Daily Scrum if you don’t add value to the product while doing it and this is always a question you have to ask yourself — Does doing X adds value to my product and/or to my team?
But obviously, this can also be a trick question and even lead you to believe that you should stop doing your Daily Scrum, or any other meeting, but in fact, what you should really do is changing your mindset.
Every “getting together” moment should be embraced as an opportunity to share, inspect and adapt.
Agile events always have a purpose and if we want to use Scrum (or any other framework) we should understand the purpose of everything we do and maximize the value of the outcome.
Let’s break it down:
Daily Scrum — Take this moment to discuss approaches and inspect how close are you to the sprint goal.
Every team member is accountable for the result of the sprint. Obviously, we divide to conquer and are not all developing the same topic at the same time, but there is always value when we listen to how another person would approach a problem/obstacle you are having.
It should not be a reporting moment, if the product backlog items are clear and there is a common goal there shouldn’t be a reason to do reporting.
Sprint Planning — This is a negotiation moment. Imagine as if it was a business meeting. There is an initial pitch, usually started by the Product Owner (PO), followed by a discussion around that initial thought but the outcome of the meeting should be a common understanding of a goal for the next iteration and what needs to be done to achieve it.
This is not the time or place to discuss the ‘how’, it can be briefly mentioned, if it makes sense, to get a better notion if the amount of work needed fits the sprint but details do not add any value at this point. More details can be added as more is learned during the sprint and scope can be in fact re-negotiated.
If you are a fellow PO, hi, but let me remind you that although this is a negotiation, the plan should be done by and for the developers. This doesn’t mean you cannot give your opinion — you can and you should — but do not take over the discussion.
Sprint Review — This is literally an increment inspection.
Your stakeholders will probably participate and the objective is to see if the expectations meet the reality. Also, this is a great moment to add more things to the backlog, adapt the product as more is learned.
Again, not a moment for reporting, stakeholders are increasingly being seen as part of the team so they are also aware of the goal, moreover, the product and sprint backlogs are transparent to them thus there is no need for a report.
Sprint Retrospective — Get all of your frustrations out (positively and constructively… of course). But indeed this is the event where people talk about people, where the sprint is analyzed taking into account people and their interactions. Find common ground, use your empathy and focus on what you can improve.
The art of building a backlog
As one of the Scrum artifacts, we look to our product backlog many times for many reasons. Maybe we need to know what is next in the pipeline, what are the next important topics, etc. And thus it should be transparent to anyone who is affected by the outcome of the product it describes. Too complicated?
First things first: what does transparency mean?
In a product mindset before even having a backlog, there should be a product goal. Ask your self:
- Why am I doing this?
- What is the objective?
- Who will benefit?
The answer to all of these questions should be the same throughout the team and stakeholders, it creates the first building block for transparency — “The Vision” — a common vision.
When the goal is set, the product backlog describes what will we do to achieve “The Vision”. But this doesn’t mean that if you have a purpose you have a fully built Product Backlog. It is a living ‘thing’, it emerges as more is learned.
Fellow PO’s, worry not, it is expected that you don’t have all your items fully described and clear. Yes, you are accountable for the product backlog but the responsibility for what is there is shared with the Scrum team.
You need just enough items for the next iteration and of course you can and should refine it during your planning with your team.
The imitation game
There are tons of misconceptions when someone or some company says they do Scrum. I explained my view on just a few of them.
The phenomenon that I call imitation game is that nowadays everyone seems to be doing Scrum (or any other Agile framework) but what is the truth? Some, if not most, use the terms but don’t comprehend its purpose.
Humans tend to try to find comfort zones, it’s only natural when transforming from a classical management model to an Agile framework that we try to make as few changes as possible.
We should all be the drivers of the changes we want to see and if you believe Scrum can help you, by all means, do it. But don’t do it because everyone does it. Don’t do it if you think it will look better in your resumé. Don’t do it just to get more traction in the hiring scene.
Scrum should not become the gourmet food of IT. If you don’t understand it, what is the value?
