Do you really have SCRUM?
Do you know what is Betteridge’s law of headlines? For those of you who don’t know and don’t feel like googling it let me quickly explain. Betteridge’s law is a journalism adage that states that if the title of the article is a question then the answer is probably no. Think for a sec about tabloid newspapers. “Did X sleep with Y?”. If he had slept then they would write “X slept with Y. We have a video” (or something similar).
One more digression: the way I started this article is almost the same how Piotr Przybył started his presentation @BoilingFrogs 2018. Although it is not mine, I feel like I might have your attention now.
Having in mind the Betteridge’s law, knowing the title of this article you may think “Yes, I do have SCRUM and it is perfectly fine”. If you do think so, I won’t try to convince you that it is another way around. Please, treat this article as a kind of feuilleton in which I’d like to share my thought about SCRUM nowadays.
SCRUM in offers
From time to time I receive job offers. Some are personalised, some are not — let me write about job offers for a sec. For the sake of good recruiters, I won’t say that they look nearly the same. What I would like to say though is that almost each of the offers contains several buzzwords. Of course, those trendy words will change depending on the technology the offer is about. It is not something proven but I believe in the vast majority of IT job offers you can find SCRUM/Agile buzzwords. The question I’d like to ask is are those companies really working in SCRUM? If not, what is the reason for putting it in the offer?
What is SCRUM?
For those who don’t know what SCRUM is, let me quickly explain it. Let’s start with copying Wikipedia’s definition:
“Scrum is an agile framework for managing knowledge work, with an emphasis on software development. It is designed for teams of three to nine members, who break their work into actions that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks, then track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums”
However, this definition is correct, it is too brief. “SCRUM guide”, the handbook for SCRUM it’s describing much more. It is not that big, so I’d suggest you should read it if you are into software development.
After the reading, you should now, that not only there are SPRINTS but there is much more. For sure, it describes that there are roles (Product Owner, Development team, SCRUM master), there are the artefacts (Product backlog, SPRINT backlog, product Increment) and there are SCRUM events (sprint planning, daily SCRUM, refinement, retrospective, review).
What is worth mentioning is that SCRUM is only a framework, hence you can adapt it to your needs. But there is a point where you start working in ScrumBut. I won’t say that working in ScrumBut is bad. It is not when you know what you are doing. In a case when you’ve decided to get rid of the review or you don’t have dailies you need to know why are doing so, but in the first place, you need to know why they were mentioned in the Scrum guide and what you are missing. If the decision was made consciously then it’s ok. Otherwise, when eg. you just don’t like showing a client what was done recently, you are afraid of failure, then you should reconsider Scrum (transparency is one of the key things in Scrum). You simply need to know what and why you are doing so.
The “SCRUM” I’ve met
Bearing in mind what I’ve written above let’s take a closer look at the examples of Scrum implementation. When reading them, please think about one question: “should this company say they are working in Scrum?”
Company A
This company really likes the idea behind the SCRUM. Company owner heard about It from a friend, read an article on Wikipedia and decided they should give it a shot. In each team, there are 2–4 members. Because of money, there is no Scrum master in the team. A client is the product owner.
At the beginning of each day, teams have a daily. They do also have JIRA board where they keep track of what everyone is focused on right now.
There are several items in the backlog but they are not prioritised as they are lacking planning/refinement. Every second week each team tries to show the results to the client but sometimes he is not available so they are cancelling the meeting. Teams treat SCRUM as an obstacle — from time to time developers ask “Why do we need so many meetings?”. No one has ever shown them what SCRUM is all about.
Can company A say they do have SCRUM?
In my opinion, they are on a good path because someone saw the real value in SCRUM. What is missing though is a SCRUM master who can show this value to others. People involved in the projects must understand what they are doing and why. Right now, when a team sees no value in having SCRUM events, it’s not a big help for the business. Although they have dailies and other events, they work as they used to.
I won’t say they work in SCRUM; I’d rather say they are “trying to implement SCRUM”.
Company B
Now, please imagine a small business that hires only 16 developers — Company B. They have 4 teams each consists of 3–5 developers. There is only one project manager (let’s name him Mark), but he is busy doing paperwork — taking care of invoices, payments etc.
At some point, one of the employees (what about giving him the name of Peter?) read somewhere about SCRUM. He thought it may help to solve the problems they do have on a daily basis: communication with a client, communication within the team, not organized work and several more. He went to Mark (who was busy as in always) and asked for his opinion about this framework. They spent almost 1 hour talking about it but finally, Peter managed to gain Mark’s interest in SCRUM. Furthermore, Mark told Peter that he will back him up when he will to talk to a client about having test iterations of SCRUM. Indeed he did that. They organised a meeting and showed the client the value of having SCRUM on board. Among the arguments they have used were:
- “We will work in 2-week SPRINT. By the end of each sprint, you will get a working version of your product and you will see what we have achieved”
- “Every fortnight we will have a planning meeting during which you can plan what do you want to do in the next Sprint and in the future”
- “You should not change the priority of things during the Sprint”.
Of course, the client agreed (otherwise I will have to end this story here and obviously it does not make sense).
The next step was to explain Scrum game to the teammates and ask for their opinion. They liked the idea but they didn’t enjoy the number of meetings they would have to attend. After all, they said, “let’s do it”.
So they did.
Before the first sprint, Peter took some time and based on the work they needed to do, created backlog items.
First sprint
On one Monday they started their first Sprint. The first meeting they had was planning. In the previous week, Peter had asked the client when is having time so he can arrange the meeting. Getting that information he sent the invitation to the Team. He’d also invited Mark, so he can be a part of the transformation. The planning was the first time when the client met the whole team. Peter showed them how current backlog looks like and ask the client if everything is in the right order or not. Later, Peter asked the team if they have any questions regarding the work that needs to be done. Indeed they had. After the Q&A session, they knew what, why and how to implement the wanted features. The meeting was planned for 2h but eventually took 3h. Although it lasted longer than planned, everyone was satisfied with the result.
During the Sprint they had standup meetings (known as daily). During those meetings, they were actually standing in a circle and saying what they did yesterday and what they gonna do today. Unfortunately, everyone was facing Piotr and reporting to him. When someone was talking, no one was listening.
Review
The sprint was going that way. Day by day until they reached the last day of the Sprint (yes, they did forget about Refinement) when they had a review and retrospective. On a demo, the client joined them on Skype to hear what was done. Also, Mark joined them just out of his curiosity about how they are doing.
During the review, they showed the client what was done. Many tasks were closed during that sprint, but many weren’t even touched. They explained why it happened and the client accepted the explanation. What’s more, he liked what he’d seen. He liked that he can test the product on his own because he has a working version available for him. He wasn’t aware that having a version opens new opportunities for him: he can start searching for investors earlier. He was over the moon.
Retrospective
As you may assume, after review they had a retrospective. Peter, to show guys what is the purpose of this meeting, opened the meeting. He told what was bothering him in that Sprint. He said:
- He liked that the team see the value in Scrum
- He enjoys that demo went well and the client is happy
- He is not sure if this is the way they should to have a daily
- He doesn’t like that many tasks weren’t done in the previous Sprint.
After Peter, no one said anything. Altogether they decided that the issues raised by Peter and true and something need to be done about them. They thought for a second and found a solution for daily meetings issue. They figure out that if they want this meeting to add value to the flow, everyone needs to answer 4 questions.
- What she/he was doing yesterday?
- What is her/his plan for today?
- Are there any suspected obstacles?
- Does he/she need anything from anyone?
About the not delivered task, they decided that they need to estimate the tasks before committing to them.
At the end of the meeting, Peter asked what the team thinks about the Retro meeting. He managed to get the answer that they were not comfortable with saying what went wrong. That worried Peter, but as he is an intelligent person he asked them the team what do they think about getting out for a pizza during the next retro. Pizza is always a good idea so they agreed.
During the next sprint, they applied the changes from the previous sprint and were improving the workflow they had.
Can Company B say that it works in SCRUM?
Having the description above I’d like to say that for sure there were several issues with their SCRUM. Truly, I would say those issues don’t matter that much as they made the business happy and they saw value in working in it.
Personally, I like the way they got SCRUM. It was not that someone come and said “from now on you are going to work in SCRUM. Handle it.”. In their case, it was a process. Firstly, Peter saw that it might help them. He went to Mark. They talked to the client and the team. The decision was not made by a single person but by the whole team. That’s good.
Secondly, they were trying to do their best. They had SCRUM events, they adopted it to their needs. Unfortunately, there wasn’t anyone in the team who can show them guide them in this transformations. Let’s take for instance RETRO meeting. No one (except Peter) told their opinion. What’s good though is the fact that they addressed Peter’s issues immediately. They managed to find out reasonable solutions. Unfortunately, we can’t tell if they changed their behaviour.
Comparing to Company A I would definitely say that Company B does work in SCRUM… however, this doesn’t mean they don’t need to polish it!
A sentence to recruiters
I hope we can all agree that nowadays Scrum is a buzzword, a jazzy word that everyone wants to include in their offers. But are you aware that it is very easy to check if you really do work in Scrum? Wouldn’t a candidate feel cheated if he/she finds out that you were laying in your job offer? After finding out, will he have doubts about other things you wrote? Is it worth the risk? Starting a relation by cheating is never a good idea.
Conclusion
Summing up this article, I’d like to put a stress on one thing. I do believe that somewhere out there, there are companies that do work in Scrum. They have a nicely organised Scrum that is working and helping the business achieve their goals.
From my experience, I’ve met many companies saying in their job offers that they do work in Scrum, but the truth is slightly different. The fact that someone uses JIRA/Azure DevOps/Trello etc. doesn’t mean that he works in SCRUM.
You should not be ashamed if you work in Waterfall, Kanban or any other framework. You should be ashamed when you say that you work in Scrum while you know you don’t.
That’s all for now! If I missed something or something is unclear please let me know in comments! If you don’t agree with me — let’s discuss!
If you liked this post, don’t forget to 👏!
Originally posted on my blog. 😇
