Going remote with Scrum
This article is for rather small distributed offshore development teams which aim to scale, improve their internal work culture and formalize relations with their customers. During last year we were actively expanding as an outsourcing company, we were making a lot of experiments with our delivery and management style, it led us to set of practices which help us to stay in the loop with each other and our customers. I hope that this article will be interesting for similar teams.
First of all. Our experience has been built around management of the remote-first team, which means that everyone works in a separate location and thus all communication occurs online. That said, I believe, that all advices and practices will be relevant for any sort of distributed team
In our team, we recognize Scrum as the best framework to work within, since it offers the most relevant set of artifacts, events, and values for us. Why?
- Daily meetings and iterations planning are required minimum for any distributed team to stay on the same page with each other
- Short iterations keep team disciplined, results can be observed more frequently, product and team could be adapted to new requirements easily
- Each team member is a capable and independent person (From my experience independence is the most recognized value of people who work remotely)
Roles and communication setup
We use default definitions from Scrum guide. Here is our most common setup:
- The Product Owner is your end customer and literally owns the business you work on. His main function is to show you right priorities
- The Scrum Master is your project manager, also he does some Product Owner job related to backlog and tasks specification.
- The Development team is represented by Designer, QA, Back-end and Front-end engineers (four participants)
Communication should be done through the default set of scrum events, we have added one small mixin to them. It is a sort of daily scrum, but it happens when a working day ends (i.e everyone answers the question what was done during the day), it is not common for the default Scrum, but helps the remote team to stay in a loop and compose a daily report for the Product Owner (if he is not able to attend daily meetings because of difference in time zones).
We came up with an idea that the most effective communication with Product Owners on remote basis should be done through qualitative report system, that suits both Product Owner and team. It should showcase the results of the each working day and help everyone measure the progress of the sprint. Looking ahead I will say that we practice more “rapid” pace of development and in most cases, we stick to 1-week sprints.
Practical accents of communication setup in distributed team
You need to ensure that nothing will prevent clear team communication during the project. This includes:
- Ability and readiness of each member to attend default meetings
- Predefined time of all events during the sprint
- The team should have work schedule and all deviations should be announced at the beginning of the day
To satisfy points above each team member should announce his working hours for the project duration. It should not be common to change them, especially during the active sprint. Everyone should stick to his predefined working hours.
Right tools are vital here. Your team should have an internal messaging and video conference apps. Each person should take care of the staff (webcam, microphone, internet connection) he or she uses. It is crucial because no one wants to attend meetings that resemble a cacophony. Emphasize it during team composition stage.
Time tracking in the right time is crucial, each day should be ended with a full work-log of each member
Activities and workflows
After sprint planning, project manager or Product Owner should compose a report for the all appropriate stakeholders (implicitly all tasks are in ToDo status). We encourage you to use daily reports with clear external statuses of features which were taken into sprint, Here is example of ours :
- In progress (Development phase has started)
- Internal testing (The feature is being tested by limited number of users)
- Ready to be tested live (Feature was deployed and ready for acceptance)
But at our end, issue life cycle is more complex. Example of our internal issue statuses:
- Specification required (Product backlog status. In most cases you will receive not specified feature requests from clients, clear acceptance criteria always should be included, ambiguous definitions should be avoided)
- Ready for implementation (stands for internal ToDo). It means that feature is fully specified and ready to be implemented
- Development (Implementation is in progress)
- QA (Feature was implemented and is ready to be checked)
- Ready for acceptance (Feature was fully tested internally and deployed, it waits for client / product owner sign off)
- Accepted (Done)
This life cycle could vary for bugs or design tasks, but the mindset behind is the same
Those performing the work and those accepting the work product must share a common definition of “Done”. Scrum guide
Dealing with complex issues
How to organize your team when complex issues arise and there is no easy solution available or you have a deal with some tough bug? When such occurs we make a short or long meeting until issue will be resolved. Rules are simple: only those who can affect the issue attend the meeting, talk only about specific issue. An idea behind it is to simulate a situation as if attendants are co-located and there is no distance between them, it really helps to quickly find a cause of a problem and resolve it. We always prefer such kind of communication when hard issue rises, from practice it is much quicker than to do the same through chat
You need to be aware that junior specialists could make a huge pain to your remote team when are boarded at the wrong time. Ideally, each contributor should know how to implement his task solely by himself based on task specification. Don’t integrate junior specialists into projects with aggressive deadlines or in situations when you have one lead developer on two small projects. It will never work out and in result will cost you much more than middle or senior hire.
Scrum Team members respect each other to be capable, independent people. Scrum guide
The reason why we use 1-week sprints is because when you work with a startup or small business the scope or priorities could change dramatically. We hold 2 Stand up meetings per day for the same reason, to be always ready for the change. Usually, we combine ended sprint review with next sprint planning session since the amount of delivered value in each sprint is smaller compared to standard 2–4 week sprints.
I hope it will be helpful for teams and specialists who consider switch to remote work. Will be glad to hear any thoughts on this article and discuss your experience in a remote-first team!