Agile Scrum Software Engineering

Scrum Master – A strict teacher?

Agile Scrum is misunderstood by a large segment of practitioners. Scrum deliberately didn’t spell out most of the actions required and that creates the pandemonium. The unclarity of action spelled out creates the ‘theorists’. And they run around with stopwatch and believe high in ‘assumed’ rules.

In my views, scrum needs to be approached with common sense. A high discipline from the team is unquestionably a mandate. Having that said, the exception and irregularities are expected when you deal with a human.

Just to give an example of some of the disciplinary issues that every scrum master may encounter are

  1. Timewasters — Scrum advocates more collaboration than the documentation. The meeting schedule is expected to be very short. A good team should know a 15mins of team meeting cant be considered as 15mins meeting. It’s actually no. of team members * 15mins. Example, If it’s a 6ppl team then overall it’s 1.5hrs. Daily standup meeting is expected to finish it in 15–20mins considering the above reason. Any time spent beyond 15–20mins could have been overkill. Hence the team members are expected to be crisp and to the point. The team member should communicate only the information that the team should be knowing. The prime reason for DSM is to inform the team members on how are they progressing towards the sprint goal. What impediments need to be addressed as a team to achieve the goal. If it’s conveyed in the given meeting even in less than 15mins then the meeting should be over. The scrum master need not conducting the meeting with a stopwatch. The scrum master should mindful about meeting time to protect everyone’s time. If time dragging is quite an affair then should spend time on understanding ‘WHY’ the meetings are dragging than hard stopping it. At any reasonable circumstances extending a meeting for a few more minutes for a meaningful conclusion is absolutely accepted.
  2. The theorists conduct some of the ceremonies for namesake. Retrospection meeting can be a good example here. To visualize the theorists’ retrospection meeting, only a few stakeholders would attend the meeting. May chit-chat about all the good things happened and ignore happily the bad part or would make it light. Or else, full of a blame game on what went wrong and demoralizing the team. A good scrum master should know retrospection should not just limit to the sprint that just got over. It’s a retrospection of how are they doing as a team from the beginning towards the project goal. The lessons learned in the past, how are they fairing on those lessons in the following sprint, what else they need to do better. As far as the theorist concerned conducting just the retrospection meeting is just one of the mandatory activity. They expect the team to gather and produce retrospection document nothing more and nothing less.
  3. One more example could be focusing on task completion than adding value. The product team should know about one of the main reasons why the customers are using only a selective few features in the product. Any feature that won’t ‘simply’ solve the customer requirement won’t get customer’s blessings. A team that focuses on just completing the tasks may not have thinking time to add value. At the same time, the team should not get lost in ‘gold plating’ as well. The scrum master should gauge the situation and act here. The theorist is just so particular about announcing the on-time sprint completion.

Almost in every scrum ceremonies, there is a chance that the scrum master can close his eyes and follow the assumed rule book just by believing that’s the way to do it. This approach would definitely help you get your metrics right but the customers won’t spare you. Imbibe discipline to the team and you don’t need that tough face.

Author

KR Kaleraj