• • Do you really use Scrum?
  • How adherent are you to the framework?
  • Do your teams have a hard time dealing with Scrum concepts?

The answers to these questions determine how much this new version of the guide can influence what you and your team do. On the day of the release the authors, other officials and several experts made some lives about the new version. We participated in some of them to gather different views and opinions on the subject. We will talk about the main changes and at the end discuss a little what happened.

The New Guide

The guide itself has shrunk. It went from more than 20 pages to 16. In addition, it was launched with the purpose of democratizing Scrum, that is, the main line of its launch was its reduction and some adjustments that were made to allow the guide to be used by others. activities other than software development. In other words, the main idea of ​​reducing the size, which also manifested itself in other aspects, is to make the guide less prescriptive, focusing more on its agile essence. A clear example of this is the case of the Daily Meeting. In its new version, the 3 basic questions of this meeting disappear – what I did yesterday, what I will do today and obstacles encountered – to focus on its essence as a meeting of micro-planning of activities.

Likewise, the authors believe that the changes now introduced make the guide more comprehensive, in the sense of contemplating areas other than IT, since Scrum is now widely used in activities other than software development.

The following changes made are noteworthy.

Team

We now have only one team: the Scrum Team. Previously the Team was defined by a PO, an SM and the Dev Team (or team of developers). In its new version, the Dev Team gives way to “Devs” (developers). Thus, a Scrum Team was formed by PO, SM and Devs. Time now exists only one. An attempt to lower internal barriers and increase group commitment.

Roles and Accountabilities

Following the same tune, the Roles that were already defined by Responsibilities  now boil down to Accountabilities. In Portuguese, both terms would be defined as responsibilities. However, according to the authors, the term Role was removed because it was being used incorrectly as a position in many organizations. In a way it seems to me that flexibility was sought again. By removing the Roles and defining accountabilities for team members, there was also the possibility of having other accountabilities associated with Team members, in addition to those defined in the guide. However, the Team continues to be formed by a PO, an SM and Devs.

Product Goal

In order to avoid that the Team is simply a manufacturer of features, running Sprints with the objective of performing as much work as possible, eventually losing the perspective of real value for the customer, the guide now introduces the concept of Product Goal. The Product Goal serves to keep the team oriented to what the customer really wants – Focus.

At the same time, this also allows the creation of good Definitions of Completed – DOD (Definition of Done) – used to evaluate the product increment, since they must always be created with a view to achieving the Product Goal.

The guide now makes it clear that for each of the following artifacts there is an associated orientation: Product Backlog oriented towards the Product Goal; Sprint Backlog oriented towards Sprint’s Goal; and Increment oriented to the Definition of Completed. If you use Scrumhalf, there is already room for everything: Product Goal in the project description, Sprint Goal in the Sprint description, and DOD in your project settings.

Still on the same path, that of providing transparency and generating focus, the guide starts to include in the planning of a Sprint, in addition to the usual questions of what to do and how to do it, the need to show why why to do it. This demonstrates Scrum’s commitment to promoting the alignment of the entire Team in one direction.

Self-management

In its earlier versions the guide stated that the team, or the Devs, were self-organizing. This time, the guide starts to define the team as self-managed, in a way establishing that the team itself can define who will perform each of the tasks. It may pass only as a rewrite, but it may have other consequences. Let’s see how this change will impact, if any.

Our Impression

It is certainly commendable to reduce the size of the guide, as well as the intention to make it less prescriptive. The changes in general are simple and effective, even if in a way they are just a new guise for existing practices, as in the case of the change from self-organized to self-managed.

The big disappointment, however, was due to the scope of the guide, especially with regard to the language used. During its launch, we had the opportunity to ask, for example, “why did the guide insist on Devs, if that is an exaggerated IT term”. The answer came well below what was expected. The panelists claim that several Teams from different areas were consulted and that the professionals considered themselves Devs, that is, developers, because they develop some type of product or service. Honestly, it didn’t convince me. Agilists who work with non-software development teams always find it difficult to use different terms than what is defined in Scrum, in order to better adapt the framework to the reality of their areas. A real change in this direction would be very welcome.

Finally, considering the current market and the organization of work in Scrum itself, the effect of removing roles, replacing them with accountabilities only, will have little practical effect, in our opinion. However, at the end, this will at least provide a topic for heated debates, as we already can see on social networks. Just to have an idea, take a look at this definitions.

I hope that user feedback will influence an upcoming version of the guide, making it really more suitable for other professional areas.

Have you read the new guide? What do you think?

The post What Changed in Scrum? Scrum Guide 2020 – 5 Noteworthy Points appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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

The post Remote Work – 7 Tips to Help Your Team * appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

I think that some Devs really have the vision aligned with what was expressed by Willem-Jan Ageling, the author, in his article, and, therefore, I decided to debate a little more the topics listed by him. I understand that some people can really find in these topics reasons to “hate” Scrum, but I believe that another view on such reasons can turn this hate into love.

The analysis by Willem-Jan , focuses on new responsibilities faced by dev’s when working using Scrum. Better then, take a look at these “new” responsibilities, dissecting the problem to understand it better.

• At the Sprint Planning — Determining a Sprint Goal, in cooperation with the Product Owner. The Development Team needs to assess if they can meet the Sprint Goal as this drives the Sprint

Are there traditional, or non-agile, teams where the manager does not ask about deadlines, or what can be done until a certain delivery date? Honestly, I never saw that happen. Quite the opposite. I have always witnessed this questioning being asked repeatedly, even generating heated discussions, and stealing time, and often tranquility, from the team. This issue can never be abandoned, as there is no way that an organization, which establishes goals and objectives, works with KPI and OKR, does not have any idea of ​​when it will arrive where. In fact, I think that Scrum helps the team a lot in this sense, defining a specific moment for such discussion, in a way limiting it, and preventing it from stealing more time from the team.

• At the Sprint Planning — Creating a Sprint Backlog. This entails selecting the Product Backlog Items that help meeting the Sprint Goal and to create a plan to deliver them.

In reality, I understand that the Dev Team only helps the PO, or clarifies its doubts, so that it selects the stories to be contemplated. It is the responsibility of the PO to define a goal with the team and define what can be done to achieve that goal. Although the assessment is up to them, he is the utmost interested and the one who provides the guidance. Regarding the necessary plan, I believe that there are two aspects. The first is that this practice of planning what will be done in the short term is extremely productive. In general, it avoids hacking. Or do we not know devs who, upon hearing the first news about a customer need, already want to sit down and go out programming? This small planning, significantly helps to avoid the mole effect and promotes collaboration and coordination between team members, under the risk of not doing so, generating rework and having a lot of coordination difficulties. In other words, in my view, such a responsibility has always existed. Only, some people, or teams, forget their need and end up paying a high price later.

• During the Sprint — Ensuring the Product Backlog Items meet the Definition of “Done” and acceptance criteria.

Could the team work differently? This seems to me to be inherent to dev’s work. Otherwise, the dev forgot to be working to satisfy the needs of some client, to be a dilletante.

• During the Sprint — Making sure the Sprint Backlog always shows the current state of the progress on the Product Backlog Items and the plan for the Sprint.

This responsibility does not seem like extra work, but only a matter of discipline, attention to the framework and use of an appropriate tool. The daily meeting, already built in Scrum and that should not be abandoned, has as part of its scope the presentation of  did/will do/problems. This, in itself, allows for an update of the work situation. If, in addition, the team uses a monitoring tool, as Scrumhalf, where the tasks worked are updated by the dev himself and automatically generate information, such as the Burndown chart, transparency and visibility are guaranteed, without any extra effort.

• At the Daily Scrum — Daily assessing the progress towards the Sprint Goal. This includes updating the plan as reflected in the Sprint Backlog.

Really, the Daily Scrum is something that takes time from the team. However, this time, which must be very short, around 15 minutes or less, would be much longer if the project had a formal manager and the team members had to make their progress reports for him. Additionally, it is essential to remember that the Daily Meeting is what enables the team’s self-organization, reducing traditional friction with management, and increasing job satisfaction.

• At the Sprint Review — Discussing the Sprint Goal and how they managed to reach it.

This is really not a common thing outside of Scrum. However, in addition to the fact that this discussion should not take too long, it should be remembered that, among other reasons, this discussion promotes transparency and ends up avoiding, or replacing, the constant discussions and debates of the Dev team with management, when using non-agile management.

• At the Sprint Review — Showing what they created and answering questions.

I’ve never seen this left out either. Dev Team can’t just code and forget. Unless there are other members to demonstrate the implemented features, note any bugs, etc. The advantage in Scrum is that since it is done in an organized way, faster, and with the participation of the entire team, it allows everyone to stay up to date, reducing interruptions of work in subsequent tasks.

• At the Sprint Review — Taking part in the discussion of what to do next.

Although I have always promoted this type of discussion in the projects I participated in, especially in the ones I managed, before agility, I recognize that the Dev Team is often left out of it. However, as a result, it is normal for the team to waste a lot of time later, complaining and discussing why something is being done. That is, the process of thinking about what should, or should not, be done is effectively carried out. The big difference here is that he will be able to express his thoughts and listen to that of the other companions. And, it must be remembered, responsibility, like mostly in Scrum, is collective, of the Dev Team, not individual.

• At the Sprint Retrospective — Inspecting how the Sprint went and create an improvement plan.

This one is really different. Kaizen, or continuous improvement, is something Scrum takes very seriously. It takes a little time from the team, but it brings enormous benefits, including allowing more and more the dev’s to focus on their main activity over time, since the “process” itself is working well. It is up to the Scrum Master to make this ceremony productive and enjoyable. Its results, which in a non-agile way should also be reached by good management, will always be implemented in the same way, regardless of the management model. I mean by that, if something needs to be changed, revised, it will have to be. And someone will have to do the job.

• Creating and maintaining the Definition of Done.

Truth. Now the team must worry about that. But let’s see. The definition of done, at least in the developer’s mind, already exists. Otherwise, how would he finish working on something? The difference here is that now the team must create a shared definition, which is understood by everyone. And, in fact, what initially may seem heavy, after agreement avoids a series of conflicts, is easy to maintain, and can, for example, be seem as a by-product, when necessary, of the Retrospective.

• Learning, exploring, and embodying the Scrum Values of Courage, Commitment, Focus, Openness, and Respect.

This only occurs, or at least in a striking way, when transitioning from a non-agile method to Scrum. It is, at that moment of the transition, an important cultural change. But after some time working this way, it starts to flow in the vein of the agilists and it becomes no burden. After all, isn’t life more beautiful like that?

To summarize, we set up the table below. In this table, we represent each of the responsibilities, in the same order as the text, and we try to indicate the need for their adoption in any project, regardless of the management model used. On its side, we try to demonstrate the impact if it is neglected. In Scrum, we try to show the main form of Scrum in dealing with the responsibility and, finally, we indicating if a tool can significantly facilitate the work of the team, if it adheres to Scrum. This table is empirical, without scientific rigor, being only the result of what we observed throughout the projects that we participated, directly or indirectly. The only purpose of this table is to compile the data, from our perspective, related to such an extensive list, synthesizing it, albeit superficially, to allow for a global view on the part of the reader.

Well, we tried above to complement the analysis made by our colleague Willem, to who we thank, aiming to give the Devs, or any element of a Scrum team, another perspective on their “new” responsibilities. The use of additional elements in the team, to take care of certain aspects show here, or the redistribution of some activities, can undoubtedly help, relieving some work, as pointed out by Willem. Evidently, discounting the communicational aspect made clear by Fred Brooks, in his seminal book The Mythical Man-Month, more people usually help to lighten the burden.

In conclusion, I think the main point is that Scrum actually fixes and organizes a number of things that in reality are already done in other ways in non-Scrum activities, and when it adds something extra, it is because it really is necessary and brings great benefits to the team. Can you think outside of the box and see these aspects in a positive way too?

*This is a Google Translation of the original article

The post 11 Reasons Your Team Shall Love Scrum appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto, esses problemas nunca devem passar despercebidos e o Burndown é um grande auxílio nesse aspecto, sinalizando que algo pode não estar indo como previsto. Ele serve como uma alerta, para que o time analise o quadro atual e o que será necessário fazer para entregar o combinado, ou até para adicionar novas atividades, entregando mais do que o combinado.

No entanto, infelizmente, muitas vezes esse gráfico tão simples e útil, é mal empregado e acaba trazendo prejuízos ao invés de benefícios para o time. Vamos dar uma olhada nos 3 principais vícios na utilização do gráfico de Burndown.

Controlar o Time

Não é vigiando o Burndown para avaliar o trabalho do time que as coisas vão mudar. Na verdade, esse tipo de atitude atrapalha muito o funcionamento da agilidade. Na agilidade todos trabalham com comprometimento absoluto. As pessoas são empoderadas para resolverem problemas e atuarem da melhor forma possível.  O controle indevido acaba se tornando um estopim para o início de uma crise na equipe. Acaba gerando contrariedade entre PO e time, com acusações mútuas que podem desencadear crises muito mais sérias. O gráfico de Burndown não deve ser utilizado com uma ferramenta para exercer o Comando e Controle.

Comparar Times

O Burndown também não é ferramenta para comparar times. Aliás, na Cultura Ágil, a preocupação deve ser muito maior em motivar do que comparar desempenho. O objetivo não é dar “pressão” no time, mas trabalhar junto com o time, buscando pontos de melhoria, para cada vez mais aumentar a eficácia e eficiência. O próprio sistema de pontuação de histórias, velocidade, e planning poker, utilizados na maioria dos times Scrum, não permite comparações entre equipes. É um sistema de pontuação sem uma referência única, onde cada time estabelece suas referências e seus valores de acordo com as suas percepções e capacidades, dentro de seus respectivos cenários. A utilização do Burndown para comparação de times além de inapropriada e sem nexo, é improdutiva.

Medir Performance

A performance do time de forma ampla é avaliada pelo cumprimento do combinado. Isso de uma forma geral acaba sendo feito conjuntamente durante a Retrospectiva, em função do resultado da Revisão. Acontece que, em alguns casos, membros do time, ou mesmo participantes externos, acham que podem utilizar o Burndown para avaliar o desempenho do time durante a Sprint. Ficar medindo performance através de indicadores como o Burndown, além de não ser adequado, cria um clima de desconfiança prejudicial, e acaba levando ao primeiro vício que citamos, o de tentar controlar o time, utilizando o modelo de Comando e Controle.

É importante que todos os envolvidos com o Scrum entendam que o Burndown é um mecanismos de transparência, de awareness, e não uma ferramenta de medição de desempenho para uso numa estrutura de Comando e Controle. O propósito do Burndown é dar visibilidade à evolução dos trabalhos, para permitir que o time faça a devida análise do mesmo, considerando o cenário e o momento que se encontram. Existem outras métricas bem interessantes que podem ajudar o time. Entretanto o Burndown deve, e precisa, ser usado de forma útil e frequente para ajudar o time a dar o seu melhor.

Como vocês estão usando o Burndown no seu time? O Burndown tem ajudado? Conta para a gente.

The post Burndown Chart – As 3 Principais Confusões appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post Classifying User Stories – User Stories Revisited III appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.