Suddenly you found yourself with a remote team, without really planning or preparing for it. Keep Cool. A study from the American Census published on Computerworld indicates that from 2005 to 2017 remote work increased by almost 160%. The new reality of work may be strange, but in addition to the fact that many companies have adopted remote work for a long time, we have already gained some experience to point out good practices for remote work, or home office.
Usually some concerns are highlighted: How will we manage to coordinate the work with the team distributed? How will we be able to work without the same social interaction that we had in the common workplace? And what about the impact for people?
Agility, especially Scrum, which recommends that teams work together, in the same place, can obviously be adapted so that that place can be “built” virtually. A few tools and agreements between the team are enough for everything to work well, even better than before, in terms of productivity.
Recently, in an edition of Agile Beer, we raised this debate and there was a lot of feedback from professionals from companies around the world. We try to organize everything and, together with other reports presented in articles that we access, we have prepared a compendium of suggestions to help you deal with this novelty easily. Not everything needs to be implemented. In fact, some solutions overlap. Select and adapt the ones that best help your teams.
Hold virtual meetings, but limit the amount
Many professionals complain about the increase in remote work meetings. Natural, because some meetings that were in person and the professional was not even close, now go straight to your desktop. It became more difficult to say that you will not be able to go, because now the meeting is coming. In addition, it was easier to schedule a meeting, as you do not need a room, an audiovisual resource or water and coffee. Each one turns around.
Too many meetings tire the team and negatively affect productivity. A good way is to combine with the team what demands a meeting, establish limits for the duration of the necessary ones, and even set a specific day / period for meetings that are not already foreseen in the adopted work process.
Establish a comfortable and common schedule
Remote work at home ends up changing both the individual’s routine and that of his home. Adaptations to schedules and family interactions turn out to be necessary. However, not all families are equal and have the same demands. You can’t always schedule meetings or try to work together whenever you like. It may be that this time does not please the rest of your team.
A good practice is to establish a daily schedule when everyone on the team must be available for work, a common schedule, which facilitates the exchange of information, but does not disturb people’s routine too much. After all, now the home is the company and the company is the home. Gather your team and wake up that time. Set a time for work, even if reduced, but where everyone can interact at will. Set kind intervals for meals so that you can serve different homes. This will decrease your team’s anxiety and allow everyone to better organize their lives.
Create common environments
Some companies make their employees all connect from the beginning to the end of the workday using a communication tool. Sometimes even using video. This can end up being a little over, and give a feeling of mistrust and a very bad attempt at control for everyone. If some feel uncomfortable in this way, and this sparks a controversy that can range from the design of the Panopticon to the Hawtorne effect, some alternatives can be tried.
Common working and decompression environments can help. Some companies have adopted some solutions in this regard, such as:
Creation of a common work room, without mandatory connection, simply providing a virtual space that people can use when they find it interesting;
Holding a daily meeting, like Scrum, in a virtual room common to all. This gives the opportunity for people to participate in a brief interaction, to arrange subsequent virtual meetings if necessary, and to coordinate their efforts, without making the meeting somewhat invasive, given its brevity;
Creation of a virtual cafe room, where team members connect when they want to have a coffee and relax a little. This tries to replace the “coffee”, so common in our work environment, where different subjects are discussed.
Provide the necessary equipment and tools
Not everyone on your team has the right resources to work from home. Some need a better chair, others need a camera, some even need a table or a better Internet connection. Check with your team what they lack for remote work and take the necessary steps. For many companies the cost of maintaining traditional workplaces has been greatly reduced, allowing for greater support for their teams. Additionally, individuals started to have costs that they eventually did not have. The company being able, should help. If you can’t, talk to the team and make arrangements.
In this new scenario, some tools can help a lot in coordination and organization. ScrumHalf, for example, has all the resources to support remote work, from Backlog, Virtual Kanban Board, facilities to conduct Review and Retrospective meetings, resources to plan delivery remotely, and even chat rooms restricted to projects – War Rooms – for team interaction and record conversations. Remote work ends up requiring greater documentation of decisions and resources like this can make your team’s life much easier. Additional communication software, especially videoconferencing, will certainly be needed.
Attention to Documentation
The team interaction will now be a little more chaotic, even though you have taken some precautions as described above. As seen, people are not always fully available during their working hours and the absence of some information can create an unnecessary impediment. The best thing about this new reality is to pay a little more attention to the documentation, always remembering that someone else on the team may need to work on what you are working on now. Always ask yourself what you would need to know if you were to work on that task without knowing the problem deeply. What information would you need? Were they registered somewhere already? If positive, indicate. If not, record them.
Prioritize Technical Stories
Of course, you are building a product or performing a service for your customer and you need to deliver tangible value to them. But we all know that any project ends up accumulating technical stories, that even though they are not directly perceived by the client, they are also producing value for him. If possible and will not compromise the deliverables to be made, try to put technical stories in front. At least until your team feels more comfortable with remote work and remote interaction with the customer. Technical stories demand less interaction and can even help the team to gain confidence in the new work model.
Be Present for Your Team
Make it clear to your team that you are always ready to help them. Regardless of the agreed times, agree that if there is an emergency or something that really hinders the progress of the work, and that you can help resolve it in some way, the agreement can be broken and you can be called.
If necessary, establish a color code in the agreement. In green time the call is free, in yellow only if there is a significant impact on the result and in red only if it is an emergency. Give an example of each case, to help your group understand how to behave. It is important for everyone to know that there is support and that the fact that they are physically isolated does not mean that they are loose and need to solve everything without help from anyone.
The reality we live in demands resilience and creativity. More than maintaining the productivity of our team, we must contribute to their well-being and satisfaction. It is in a time of difficulties that the real opportunities are revealed. Take this opportunity to improve the quality of life at work, even if it is remote. Your help and interest can make all the difference with your team.
And you who are already remote, what practice do you use to make this remote work pleasant and interesting? Tell us in the comments.
*Translated by Google
I recently came across an article that caught my attention. Here’s Why Many Developers Hate Scrum, or Why Many Devs Hate Scrum, makes an analysis of the work in Scrum, indicating, mainly, an increase in load for developers, due to the needs created by the use of the Scrum framework. As interesting as I found the article, and it really is interesting, I noticed several points of disagreement, or that deserved an explanation, which ended up leading me to also make a similar analysis. There is no intention to negatively criticize its author, nor his opinion, not least because it was thanks to it that I developed this, let’s say, complementary analysis. I believe that another look at the problem presented can help Devs who are experiencing this dilemma.
O Burndown Chart, ou gráfico de Burndown, é um dos recursos que o Scrum nos oferece para vermos o andamento dos trabalhos em uma Sprint. A principal função do Burndown deve ser apontar discrepâncias entre o combinado e o realizado, no sentido de permitir a devida intervenção. Quando falamos intervenção estamos querendo falar sobre a análise do time do cenário em que se encontra, para identificar possíveis problemas e efetuar correções, sempre que possível.
É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto,
We already understand what a story is in Scrum and how to work stories using INVEST. Let’s now take a look at how to classify these stories.
As we have seen, stories are the requirements of the project / product being worked on. Stories are kept in Product Backlog and sorted by work priority. So it is natural to have several stories to work on our Backlog.
Considering that products are created or developed in collaboration with the entire team, as well as external agents such as stakeholders, product managers, etc., everyone should be encouraged to make their contributions as stories. However, only the
When we design a new product, or when we think of a problem to be solved, we are faced with different levels of knowledge about the various aspects to be addressed. Certainly, some characteristics that we wish for the product we know well and we manage to detail. Other, we have only one idea, a high-level vision of what we want. Also, it does not make much sense to define a product with a huge amount of stories, or Backlog Items (PBI – Product Backlog Item). It gets confusing and hard to explain to anyone. So it is only natural that