This article is for people who have a lot of questions and have asked a couple of SCRUM trainers but have gotten the answer: “You do what you believe it’s ok for your own team.” Sure, anyone can give the same answer but few people have the balls in giving you advice or talking about issues that are commonly encountered in any team. I’m going to share what I believe are some difficulties in any team, newly formed or experienced.
There is a rule, if there aren’t any problems then that means there are problems but they don’t discuss them. So, what you need to have, is a good Scrum master to help the colleagues understand what Scrum is and start communicating everything.
The main issue within a team is that no one quite understands what scrum is. This is the responsibility of the Scrum master, to ensure each and everyone of his colleagues know the basics and understand the rules. Of course there are rules to which you have to abide, so if you make sure you understand them, all problems will be avoided.
How many times did the Scrum master goes to the team members and tells them “C’mon guys it’s time for the meeting”. This is another problem, people don’t respect the importance of the daily meetings, or the punctuality of the rest. It’s not hard to be present for maximum of ten minutes and to discuss what you did, what will you do and what are your impediments if any. You just open you mouth and blab about your work, if you had any work that is. Some people choose to skip the daily just because the day before they chose to do other things rather than working on their project. You could say this is a forceful constriction but people need to understand that they are all mature and should only care for what they work, in the end you’re not befriending them, you’re just a respectful colleague. Of course you can make a few friends but that’s all up to you. Best you keep it professionally and not involve yourself in their lives. Respecting the daily meeting is used for enhancing communication between team members, so if they have a problem with it, just raise a collective solution at a retrospective meeting. What hour and what place, as simple as that, if they keep on disrespecting the meeting, raise it up again until they all drag each other to do it.
Another common issue within the teams is people talk too much during the review or planning meetings. You set a time for each individual to speak but others keep on interrupting and changing the subject deviating into other issues. You watch as the time flies by and before you know it you have 4 hours gone after only 2 out of 7 colleagues have spoken. Again you have to have a good Scrum master to organize them, keep in mind the seven years from home are not included within the scrum framework. He can use any method of control, from a stick to be held which gives the power of speech to that person to raising their hands in speaking their mind.
The trickiest issue is the workflow. Yes Scrum is agile, you can manipulate it in any method you can to fulfill your team's requests but there is a catch, you must first learn how to walk before learning how to run. A team often wants to take steps and skip some meetings from lack of importance, such as the backlog refinement, where people discuss existing tasks and add some their own. Every meeting has it’s importance and they must be held at least at the beginning of each team. But this isn’t the only trick they do. No, they want to release an untested and unchecked version of component. Whatever the reasons they may be, people tend to not care about what they release, as long as it meets the requirements then all is well. Here is where the mvp turns into a bug filled application. You can have any steps you want as long as they are present, analysis of the requirements, research and development done according to the coding standards set by the whole team or even better, the whole company, unite testing are encouraged in any situations, code review by your teammates and one or more members of a team within the company and testing, which is the last line of defence.
As a team it’s very important for you to have a Definition of Ready and a Definition of Done. These documents are set by the whole team to help develop a near flawless product. This is another issue which most teams disregard its importance. Not having these documents can lead to questions being raised during or at the end of the sprint, like: What did I have to do? Or Why am I doing this?
To make things easier you just need to create the two templates of documents for all the developers to follow and complete the tasks in an orderly fashion.
Also another issue that keeps on appearing is no one knows the roles within their own team. They know what scrum is but they keep assuming the Scrum master to be the Team Leader or that he should take care of the backlog and sort things out. This is the failure of the scrum master which has the job of being a good coach, to teach each member what a Product owner should do and why he is important. All of their roles should be explained as many times as necessary.
What if six of seven team members understand scrum but one of them just doesn’t quite get it. Usually there a people who don’t want to oblige by some rules and consider them useless. It’s simple, during a retrospective meeting a scrum master give the freedom of speech to each member. The individual person who considers all of the scrum framework or parts of it useless should sustain his accusations with hard facts. The rest should answer in their version why do they see it as something useful, and after this happens usually the single individual has a problem that isn’t comfortable in saying or is unaware of it. No problem, all of the team members will jump to assist him in any way possible to move forward.
Scrum is like a boat filled with people going through a storm, each of them has their own roles. One steers the boat, a couple of them row, one gives the direction, if one of them doesn’t help and just sits around doing nothing, then the boat can’t move. I’ve said it in the beginning and I’m going to say it at the end as well, teamwork is the key to a successful implementation of scrum framework in any company.
I could write about issues endlessly, but I’m going to mention only one more. Commit to the number of SP you take during the planning meeting. Usually at the end of each sprint you see the reports being not quite the same as what your target should be. The team tends to add or take out some stories for different reasons. This affects the results and leads to a pile-up of stories in the backlog which the Product owner will have to deal with eventually. To solve this problem is to take it slow and measure, during a couple of months, the velocity of each sprint. After you know the limits of your team you can have a clean non-violated sprint. You have to commit to your target, if you cannot achieve it, stop the sprint and start over. After a couple of times you will be familiarized and you will see the results.
And finally the most important issue of all, no one rewards their teams anymore after a sprint. You should have a couple of moments to celebrate all the hard work and time you invested into delivering the products on time. Make your team feel good and encourage them by showing them their work is appreciated. Hopefully these thoughts will help your team avoid some issues, or even solve some.
Take care and have a successful sprint.