A Scrum Master Sharing by Jeanice
2020 is the year of change to the way we work. I still remembered a few months ago, when it was announced in the company that business might not remain sustainable and we would need to look for new ways to survive. Together with the newly introduced policy of remote working, I knew then, that we cannot continue practicing Scrum the way we had.
Over the last few months, my teams have been experimenting together on delivering features quickly and on-time, more so than usual. We named this ‘the war period’ where failures are not an option. Through experimenting with different ways of working, we have learned and improved on our methods.
The Context
Here’s a bit on the current context: I have 2 development teams working on a product. Normally, new features would be discussed during the Product Backlog Refinement (PBR) meeting to understand, breakdown, and estimate the effort of the items. Then, the Product Owner would prioritize the items and the team would decide what to accomplish for the upcoming sprint.
Our Experiment
However, my teams have not yet matured enough to handle it by themselves. So what we do instead, is break our teams into smaller groups based on the features that need to be developed. A coordinator is assigned within each group to manage the feature delivery. This role keeps in mind the entire context of the feature, is in-charge of creating tasks for team members, and reports to the stakeholders.
Some might think that this is not the “correct way” because it is against common Scrum practices, but during this period of crisis, we felt that it was worth trying out.
It is a simple and small change, but it was surprisingly effective in helping us to complete our projects, though some problems did arose at a later point in time.
Advantages
Team members are more focused with less context switching
In my experience, as a former developer, switching context between features is troublesome and lowers productivity. It takes time for the developer to regain momentum to continue with development. Research shows that it takes 25 minutes on average to return to a task after interruption, so imagine the time wasted if context switching takes place often.
By breaking the team into smaller groups, they can focus solely on the assigned feature from the start to end, and do not need to worry about other features.
Reduced communication cost while working from home
Even before it was mandatory to work from home due to the situation with COVID-19, my company had already conducted a “working from home trial” to evaluate the business impact when everyone is working from home. The main problem we found was with communication.
It involves many people to work on a feature – from planning, developing, and releasing to production – which increases the cost of communication, and at the same time increases propensity for errors due to miscommunication.
Having a coordinator in the smaller group responsible for planning, managing, and communicating with stakeholders helps to reduce cost, and prevents miscommunications.
Developers gain in-depth knowledge of features
Without constant context or people switching on a particular feature, developers build up their expertise on features quickly.
Disadvantages
Silo teams were formed
Each small group focuses only on their assigned feature, which leads to everyone losing the big picture of the product. It reduces the quality of discussion about the overall product.
Besides that, developers in one group are not familiar with features developed by other groups. The workaround would be to arrange knowledge sharing sessions when the feature is ready to release, so that everyone is updated in advance.
Difficulty with product support
We believe that every developer should be responsible for developing as well as maintaining the feature, as long as it is being used.
Working in small groups, it creates a problem where only specific people understand particular features and they are the only ones able to maintain it. Thus, there is an increased risk of knowledge loss. Currently, our workaround is to have the group be the main support when the particular feature is released, and open it to others to do support after the feature is stable in production. However, we are not entirely satisfied with this solution and are thinking about other tweaks.
Developer feels like a “doer” not an “innovator”
After some time working with this method, I received feedback from developers that they started to get bored with their work. One of the reasons is because developers who are not assigned to be a coordinator felt more like a “doer” than an “innovator”.
As a scrum master, I started encouraging the small groups to take turns and share the responsibilities of the coordinator amongst themselves, so everyone can be a part of the process.
This is what we have learnt from embracing a new way of working.
What experiments have you tried out during this period?
T.8ytes by Titansoft 