Are You Skipping These Scrum Practices? Here Is Why You Need To Stop Now (and How To Do It)
Tech Talk | by Thushan Gunawardana
If you work in a distributed development setup, you have to make sure both teams are able to communicate effectively and collaborate seamlessly. Scrum is made for these purposes.
Scrum practices are the result of years of experience and research, so there is a good reason why each of them exists. If carried out correctly, you will have yourself two (or more) teams at two (or more) locations working as one. Skip some steps, and soon you might be wondering what went wrong.
Here are the scrum practices that tend to get overlooked and how you can bring them back in the game:
Scrum master: Have you chosen him/her wisely?
Anyone who (theoretically) knows scrum, knows that it requires a flat organisation; every member regardless of seniority holds equal responsibility and say in the process.
This means that choosing the scrum master must be strategic. If you give the scrum master role to a team member who is already in a leadership position (ex. tech lead), other members might slowly abandon their individual responsibilities and slip back into a hierarchical mode of interaction.
• Team leaders should not be scrum masters
[THE PROBLEM] Many teams tend to assign the scrum master role to a team leader by default. This, however, is the exact opposite of what scrum is about. The scrum master role should be assigned to a member others view as their equal (hence ‘flat organisation’).
Placing a team lead in the role of scrum master breaks the main purpose of the scrum framework as the team will gradually convert into a hierarchical/non-scrum team.
[WHY IT HAPPENS] Team leads’ tendency to assume the scrum master role by default is a product of the hierarchical mindset. People who are used to being in leadership positions are subconsciously conditioned to cling to leadership positions in any type of interaction with their team.
Their team members, on the other hand, who are used to working in hierarchical setups tend to transfer the same relationship pattern to scrum whereby they place responsibility and contribution in the team lead’s hands.
[THE SOLUTION] Give the scrum master role to a non-senior team member — as simple as that. Also, try rotating your scrum masters occasionally. This will allow several (if not all) team members to try on a new role, as well as show you who is best at it.
Estimating user stories: Is everyone involved?
Speaking of equal responsibility and input, it is important that everyone participates in estimating user stories.
• ‘One for all’ approach does not work: everyone must pitch in
[THE PROBLEM] Sometimes scrum teams select one member’s estimate for a user story instead of consulting everyone which leads to unrealistic predictions.
Or, in the worst case scenario, the lead would decide how much time a task will take cutting down the actual estimate to please the client.
[WHY IT HAPPENS] There can be many reasons for this: some teams don’t want to spend time on estimating user stories, some leads are used to micromanaging which prevents their team from pitching in and some leads are more concerned with pleasing the client than managing their expectations.
[THE SOLUTION] Overcoming challenges requires being open-minded and ready to embrace change. This is true for team members who struggle to take responsibility, as well as managers who struggle to give up control.
If you are a team member, understand that without your input, the user story will be unrealistic. Such user stories create unrealistic expectations from your lead and your client which could ultimately create problems for the entire team (you included).
If you are a team lead, understand that doing your team’s job is only incentivising them to participate less. And, understand that giving shorter estimates might please your client today, but it will infuriate both the client and your team tomorrow.
Morning standup meetings: Are you doing them right?
Do you actually carry these meetings out standing up? How long do they take?
• Stand up and cut-cut
[THE PROBLEM] Morning standup meetings sometimes turn into morning sitdown discussions. Instead of adhering to the strict agenda (what you did yesterday, what were the obstacles and what is the plan for today) that ensures a 15min session, teams elaborate on points and tasks, delve deep into technical issues and bring up topics that do not belong in a scrum meeting.
As a result, scrum meetings take too long and often get skipped due to their inefficiency.
[WHY IT HAPPENS] I think the main problem is that participants don’t carry these meetings out actually standing up. Conversing while standing up gives a sense of urgency and forces people to be concise.
As for agenda, team members usually come in unprepared, so it is easy to slip into irrelevant topics.
[THE SOLUTION] Hold these meetings standing up. Be clear about your talking points. Book separate meetings to discuss technical issues or ideas at length.
On a sidenote, if the rest of the team should be aware of any conclusion made in such technical meetings, think about setting up a mechanism for knowledge sharing.
…
Originally published on www.CreativeSoftware.com/Blog
