Adapting Scrums

No Scrum Standards, Only Practices

I have seen teams are working very well on Scrum. Teams are using the right tools, communicating very well and have an excellent team spirits. There seems to be nothing wrong and nothing need to change. In fact, Scrum is not a standard, but just practices. It is believed that those practices could help the Scrum team to work more effectively and achieve better results. I have also read from more than one Scrum Master said: if you only take some of the Scrum practices but ignore others, it won't work.

Adapting Changes

There are always resistence to adapt changes. It is not about adapting Scrum but asking any human being to change in general is one of the most difficult tasks. You have worked or lived for a particular way and now asking you to change with a totally new "system" or "practices", resistent can be strong. Scrum Master has the responsibility to promote changes and it is not an easy task. However, it is not the responsibility of Scrum Master to make sure changes happen, it is the team members themselves. 

Applying Scrum

Scrum practices can be applied in many areas or many industries. Many are using within dev. team more like task allocation. In that case, you might find a PO is missing on the team or dev. leads are PO themselves. For me, Scrum is more to facilitate the communication between PO and dev. team to make sure the team is working on the product that works for the target market and that someone will be happy on using the resulting deliverable.

Team Size

The introduction of Scrum is "not to waste time". The Scrum Master can be like a meeting facilitator to make sure the team is discussing something relevant and make sure only relevant people to take part in meetings. Experienced Scrum Master shared that the idea Scrum team size is around 5 and not more than 10. If the team is big, consider breaking up the team or simply not to use Scrum.

Missing PO and/or Scrum Master

PO and Scrum Master has their role and responsibility in Scrum. While it is possible to have someone to act as multiple roles - someone who knows well about business, the product vision, someone who has experienced in Scrum and faciliate the process and someone who can code or lead the dev. team - all-in-one superman, it might be a better idea to share the workload to others, wherever possible. A PO can spend all their time working out good stories during the Sprint. A Scrum Master can spend all the their time looking for improvements. A dev. team member can spend all their time to implement stories ASAP to impress the project stakeholders.  

Sprint Duration

There is no standard in terms of sprint duration. Some use 1-week, some use 2-week or a month. I have seen recommendations of 1-week or 2-week. It is more like a personally perference. For me, and from the book I read which I agree, one-week works best. I just learned the Scrum has a refinement meeting in the middle of a 2-week Sprint (which might be for Kanban only?) and refinement meeting might not be necessary for 1-week sprint. 

Story Points

Some might use story points as estimation. While the story points implies the difficulties of tasks and somehow related to the time required to complete the stories, the story points are, in fact, should not be translated into man-hours or time. The introduction of story points are not for estimation. It is purely act as a reference for teams performance over time. 

Working on Multiple Projects

Working on multiple projects are common but this is one important thing I believe the Scrum team MUST avoid. The whole Scrum, again, is to avoid wasting time. If you put members on more than one project, it means it requires the member to take two or projects and involving them in two planning meetings, two daily meetings... which result in a lot more time spending on those. This puts the members in high pressure and high workload. Researches show that human beings are not good on multi-tasking. 

Scrum Meetings vs. Technical Discussions

Scrum meetings, here talking about Sprint Planning, Daily Scrum, Restrospective and Review, are to faciliate the communications between members in the whole Scrum team. For technical discussions which are only relevant between specific members or between dev. team, I would suggest to take them offline; otherwise, it will introduce waste of time which Scrum tries to avoid.

The Power of Scrum Master

While the PO has the power to decide the Sprint Goal and the general direction of the product development and dev. team members have the power to decide what stories to cover in each Sprint, I would say the Scrum Master, in contrast, has no power. If Scrum Master has no power, then who would take the advices from the Scrum Master? 

In order for Scrum Master to fulfill its roles and responsibility, the management level or company directions must see the value of Scrum and request corresponding teams to follow the guideline of Scrum and to be lead by Scrum Master. If Scrum Master is facing issues, he will be open and direct - as part of Scrum practices. If being open and direct is not effective, the issues need to esculate to the management to help resolving. 

A PO or Dev. Team Member is not Cooperative

One of responsibility of the Scrum Master is to promote a positive team spirit - a spirit that everyone must do their best to fulfill their roles and responsibility. For me, I will promote the spirit like "we are the best team" and "nothing is impossible". If a PO or dev. team member is not cooperative or not willing to take responsibility, Scrum won't work. If Scrum Master has no power, he might seek management to resolve it or replacement of member should be recommended.