3 Mistakes I Had Led to Ineffective Scrum
ScrumMaster and my Start-up stories
Maybe you are used to the concept of Scrum and have already applied Scrum to your project team successfully. Or, maybe not! This blog’s idea is to record some experiences from my first start-up. Some years later, I will re-read my writing and see how I have followed my dream and how my team has helped me transform into a better one.
First of all, to clarify: I’m not a ScrumMaster, and I’m instead a team player who tried to apply Scrum to a project and for my team. Is Scrum as effective as the rumor, or as many developers said that ‘Scrum’ was just another professional- way to keep pushing them to follow the process?
I would love to share the first mistakes I recognized after the first ineffective Scrum in this blog.
1. Disregard the benefits of Daily Scrum Meetings
Story #1: “Do we really need to meet each other every day?”
I believe some of you hate meeting as much as I do. The word “meeting” evokes a bored feeling deep inside me of wasting time, talking more than working, and only in-effective discussion. Just think of a meeting in the morning every day echos in my head again: Do we really need to meet each other every day?
During applying Scrum to the latest project, I brought the same prejudice about meeting into the project: NO daily scrum meetings. It would be more than enough if I had proper other meetings such as sprint planning meetings, sprint review meetings, sprint retrospectives, and backlog refinement. Moreover, the development team members have enough to do, have enough stress to carry, and do not need an extra annoying person to mess up with their working style.
What a nightmare! I abandoned my development team by thinking so.
- I did not know what blocked them from moving further.
- I did not know what the team needed from me or what I could do to help the team hit the goal.
- I assumed the team was doing well without me.
I totally understand each developer has their big own “I.” Instead of asking for help, they preferred to find solutions by themselves first. However, not all developers have a good sense of self-management. Therefore, they sometimes could not manage their workload so well, which damaged their work-life balance.
This mistake came from my misunderstanding about daily Scrum meetings. Daily Scrum meeting is not about controlling and pushing the team to follow the plan. The biggest mission is to promote quick decision-making, which could lead to replan to adapt to the actual situation.
A daily 15 minutes meeting can solve many problems as I ever thought. The 3 powerful questions:
- What did you accomplish yesterday?
- What are you working on today?
- Are there problems that block you from moving further?
can visualize an effective working day for your team member and improve the communications among us. Thence, I can help them on time without waiting for any “S-O-S Calling.”
We can have insight into the project’s progress through these questions for the PO and ScrumMaster. People hate being tracked and controlled. But the sharing of thoughts about the current problem work as excellent as mental treatment.
2. The ambiguity of the Definition of Done (DoD)
Story #2: The problem of being subjective
After the meeting with my CEO (the PO) to define all requirements, I transferred and explained those ideas to the development team, meanwhile providing them all assets and tools to start the project. At that moment, I assumed that all team members got what they should have done to make the project done, which meant: “They Know What Done is!”
What confusion! Each had a different image of DONE.
The results were not what the PO wanted. I had to spend more time explaining and repeating why the tickets were shipped back to the improvement sections in the review meetings. A team member could not go any further but had to spend more time to improve the previous tasks. The truth was: Each member understood the job differently, and we were not working on the same page the whole time!
An unclear DoD confused our developers cruelly.
If I could make this definition of Done clear from the beginning and have documentation with all criteria of what the Done means earlier, they have not needed to improve their task so many times, which was a big waste of time.
After suffering from that project just because of the ambiguity of the DoD, I would prefer to spend more time talking about it right in the beginning. For the next project, to make the definition of done precisely, I would have a meeting section only for this topic to talk about “Done” and involve all development team and PO together to ensure that the team is not misunderstanding any point.
3. Unorganizing the tickets
Story #3: The messy board that scared me
Using the powerful Jira, we already had a substantial backlog of items that contained all tickets that developers had to solve. And here was the situation: the development team members added more items into the backlog.
As a theory, anyone can indeed add product backlog items. However, be prepared for this case: A Mess.
- Some ‘accidentally’ same tickets — Lack of communication among the development team
- Tickets with only name — No proper and necessary information about each ticket
- The PO had no clue about new tickets — Lack of communication among PO, me, and the development team.
Lack of effective communication was a huge problem among us. Anyone can add more items into the backlog, but only PO can decide its value and subsequent order. Back to the first story about Daily Scrum, if I had held the daily meeting, I would have known about newly added tickets from the team and communicated correctly with the PO.
I could have had a chance to organize the tickets, which definitely could avoid the duplicated tickets. I could also have helped the team add more needed information about the tasks.
- Writing task description that contains what the tickets were about
- Adding the related document page (related Confluence page) so the team knows where to get even more info.
- Adding other significant components and labels to help the team find those tickets more accessible through the quick filter tool.
- And so on!
For the project, we combined the powerful Jira and the Confluence. Confluence site is like a wiki page with all documentation the development team needs for the project.
All three mistakes I had above led to 1 problem: communication.
Without the daily scrum meeting, I somehow abandoned the development team, which did not help them enough to drive improvement and let them see the process toward the goal.
Without the clear conversation about “Done,” the development team had to work in an inevitable confusion through the tickets, and they suffered a lot from it.
And without the proper communication with the development team and Product owner, I did not effectively maintain the scrum board.
After the first project with Scrum, I realized that the ScrumMaster should never be the one who controls, tracks, and pushes the team to follow the plan.
It reminded me of a small story in my childhood. One day, my dad brought home an old orange bicycle for me to go to school. Since the bike was old, it made annoying noise every time I cycled. My classmates laughed at me. I told my dad: “Dad, I hate this bike. It’s loud and annoying!” My dad oiled the bike chain and showed me: “Here we go! No annoying noise anymore and smoothly as new”. He smiled, and I learned a new thing in my life.
But, ScrumMaster’s role is the same as oiling the oil chain: Making everything run well and smoothly in-between the development team and the PO.