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.

Hi,

Today’s post is adapted from the original "Five Things a Product Owner Needs to Know", available on this link.

For many times the importance of the Product Owner (PO) may be overlooked in relation to other actions os Scrum project. If it happens, it is certain that the project will not have the expected success. So, this role is as important as the others and requires a professional able to perform it.

The text of this post is directed to the PO and brings five tips to contribute to the successful performance of its role in Scrum projects. Let’s get right to these tips!

1. Trust is key

The PO has the knowledge of business rules of backlog items. However, since the PO has no development experience, maybe here are backlog items with technical knowledge difficult to understand. The tip here is to have the support of development team to explain the technical details of such stories, so that the PO can prioritize them correctly.

Also, if development team (from here I will only call "team") suggest changes, probably they will bring benefits that can accelerate development, make the code more reliable, and increase product performance. In other words, listen to the feedback of your team, as it can be a valuable complement to the product.

2. PO’s job is to serve the team

The ultimate goal of development is to launch, in time, an excellent product. The PO should try to be available as soon as possible and answer question from team.

If the team is working with Sprint of 2 weeks (10 working days), imagine if there is an impediment to paralyze the work for 1 day, it means that 10% of available work time was thrown away.

3. User insights are essential

It is essential PO understand the people who will use the product. The better understanding of end user, better will be direction of the product, its features and business rules. Nothing is more important than spending time understanding the end user.

Although it seems difficult, the goal is to achieve the best balance between what you know the product needs and what is value to users.

4. The team often fails

Even the team is very productive in a Sprint, it does not necessarily mean that the next will also be a success. The ups and downs of the development process are normal, unpredictable and can occur due to various internal and external factors.

The truth is that success or failure of Sprint is not as important as the team capacity to deliver value. Thus, there is no reason to despair if one or two backlog items are not approved at end of Sprint.

Scrum teams are always trying to improve at every Sprint. The PO should trust the team and know that, eventually, failures may occur because team decided to test new techniques, or defined a very ambitious goal.

5. PO is not project manager

This tip is for PO not try to embrace the world with their arms. This is impossible!

The PO does not need and should not worry about team schedule, how they allocate their work, or how they plan Sprints. PO job is only to set priorities and provide valuable feedback to team.

Only developers fully understand details of their work. If the PO tries to control aspects of development past these levels, then the project may be fated to frustration and unhappiness.

To let the team be self-organizing and rely on their way to work will save time and make life and work easier for everyone.

Did you like the tips? Disagree? Got any more tip to add? You are invited to comment and share your thoughts and ideas with us.

Till next post!

The post What Product Owner needs to know appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Olá a todos! 

Hoje vamos falar sobre um tema muito controverso e, por vezes, muito criticado dentro do Scrum. Vamos falar sobre formas de utilizar o Scrum sem algumas das cerimônias que são preconizadas pelos criados do método. Essa forma de utilização já ganhou até apelido no mundo ágil, o ScrumBut. Neste Agile Brazil, estivemos com o palestrante Alexandre Magno, e ele falou sobre o assunto, então vamos lá.

Vamos começar com uma definição, segundo a revista Engenharia de Software Magazine 50:

“ScrumBut ocorre quando o Scrum expõe uma disfunção ou uma falha difícil de ser corrigida e que leva a empresa a modificar o Scrum com o intuito de tornar invisível o problema”

Normalmente as empresas saem dos métodos tradicionais de engenharia de software e passam a usar o Scrum acreditando nas melhorias e benefícios da agilidade, entrega contínua, adaptação e correção rápida, e todos os preceitos que conhecemos. Mas como podemos descobrir se alguma das cerimônias do Scrum pode estar atrapalhando o pleno funcionamento da organização?

Em primeiro lugar, não podemos retirar algo do Scrum só porque achamos ruim, ou chato, ou demorado. Tudo deve ser medido. Nada que não é medido não pode ser confirmado como problema. Isto é, se você não tem certeza que uma reunião ou outra atrapalha o andamento de um projeto, não ache que retirando essa reunião o andamento do projeto correrá bem. Tudo deve ser medido e devidamento documentado.

Uma ideia, que já foi aplicada aqui na empresa, foi levantar uma hipótese e testá-la. Em um dos projetos aqui, a hipótese levantada foi de que o planning 2 tradicional não tinha efeito prático no andamento das histórias. No caso do projeto em questão, a equipe estava trabalhando em histórias distintas, que é outro ponto que diferencia do Scrum tradicional, e as histórias não tinham uma especificação clara. Por isso, eles precisavam especificar as histórias ao decorrer da Sprint. Resumindo, eles estavam fazendo o planning 2, mas eles faziam durante a Sprint. Depois disso tudo, eles puderam verificar uma melhoria nas entregas.

Eles conseguiram identificar um problema, uma “falha” no Scrum, embora eu ache o termo falha muito forte. Com isso, podemos ver que o Scrum aceita mudanças. O Scrum é um framework e adaptação é seu lema. Então porque não podemos adaptar o framework? Mas é claro que isso deve ser feito com cautela.

A comunidade scrum.org descreve uma sintaxe particular para o ScrumBut, da forma:

(ScrumBut)(Razão)(Solução)

Vamos verificar como isso funcionaria no caso citado acima:

“(Nós usamos Scrum, mas)(não precisamos nos reunir no inicio da Sprint para fazer o Planning 2)(pois fazer ao decorrer da Sprint foi mais vantajoso e prático)”

Outros casos válidos, já testados aqui foram:

“(Nós usamos Scrum, mas)(histórias de design nem sempre são bem definidas)(então algumas histórias não precisam de definição de pronto)”

Mas é claro que, casos como esses devem ser evitados:

“(Nós usamos Scrum, mas)(não fazemos reunião diária)(porque é chato e parece ser perda de tempo)”

“(Nós usamos Scrum, mas)(retrospectiva são perda tempo)(então não fazemos)”

Claro que devemos estudar cada caso cuidadosamente. O que funciona aqui na empresa, pode não funcionar na sua empresa e assim por diante.

E você na sua empresa? Faz algo um pouco diferente do Scrum? Compartilhe com a gente como foi sua experiência.

The post Do you know ScrumBut? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

today I want to share with you a bit of my 2 years experience working in a partial time team.

The first question to come, perhaps from the most unfaithful one could be: does it work?

I answer. Yes! It works! The key for the success is how to make it works.

But let's start from the very beginning. First, here is some risks that are common to occur due to this condition.

• A) Only one team member has knowledge about a particular functionality, and that member is not present when the rest of the team is needing him;
• B) Moments in which no member of the team that worked on the previous day is present in the current day to attend the standup meeting and tell what happened the day before;
• C) One team member is alone and needs to make important decisions.

Well, to overcome these risks and to make the Scrum works, in this scenario, we need to be aware of some:

– Communication: It is necessary that exists communication among everyone involved in the project, but especially among the team members. It must be at an EXCELLENT level of communication. There can not exist that thought of "should I give my opinion?". Yes! You must give your opinion! Everyone wants to hear it. There can be no doubt, and everyone must have the same understanding about everything in the project to follow the same way, even if not everyone are present. You must remember there will be times when the way should be followed only by you, and you'll be alone. Thus, never leave a Planning Meeting or Standup Meeting with any questions in your mind.

– Transparency: It is connected to the previous point. There should be no secrets and everything should be shared among the team members.

– Combined / Rules: To make everything works, will probably be necessary to establish some rules. In my project for example, the team members agreed that, when a person goes home and did not finish the item he was working on, and will not work the next morning, this one must inform everyone of the team what he did, what is left to do and what was the difficulties found. We use the e-mail to or the description of the task itself in Scrumhalf. Thus, another team member may proceed on the next day.

– Commitment: This value is important to achieve the success in any Scrum team. In partial time teams I would say it is ESSENTIAL.

– Scrum Master available: What to do when you are alone, you have a lot of activities to do, and you will need some information? Ask your Scrum Master for some help! He/She will try to communicate with anyone (a member of staff that is absent or the PO), get that specification that was missing, etc..

– Taskboard always up to date: Keep the Taskboard updated is the best way to not get lost in the stories and know who is doing what.

– Confidence: You find yourself alone and need to release that version will be presented on the following day. Take a deep breath and keep calm, if everything I wrote up here is being done, you will be fine! Scrum is that. We create the necessary conditions for the success. The rest of the team trust on you.

– Faith: You gotta have faith. Faith in the process, in your work, in your team.

Of course the cases I listed are not the only obstacles. Just like in any project, even with full time team, a bunch of other problems can appear and we have to do the best to get through them.

Giving attention to the points I mentioned, you minimize the risks and create solutions to the problems that will come up. Your chances of success will greatly increase!

Leave your opinion, especially if you have worked in partial time teams. Share with us your experience.

Till next post.

The post Partial time team and Scrum: a matter of faith! appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

I had already spoken in other posts about the importance of the team as estimating the sprint as on the team’s velocity. But today we will focus on adapting the design to development sprint, since we are going through this here in the company.

We are completely renovating the design of an application, putting new features, completely changing the screens design, changing menus, substituting presentation ways, and for everything is properly implemented, we create a way of working, and I’ll share with you how this experience was.

First of all, since the application had already been running with an old design, my team was responsible for creating the new design and development team initially was not interrupted. We created all the concept art, and then started doing the html, css and javascript that were needed for the visualization and screens behavior.

After a few design sprints, the development of the old application was stopped and the development team began to implement the new screens. We continue the design sprints, but now half of our effort (or slightly less) was to solve the problems that the development team encountered during implementation.

The problem we had because of our two-week sprint. Because of this time box, we could (we should) provide the new changes at the end of two weeks, and because of that, many stories of development were interrupted. So, the solution was reducing the timebox for a week, and every week we gave corrections that the development team needed.

The migration is still occurring, but it worked very well with us, this was my experience, and you? do differently in your business? Share with us!!

The post Integration of design sprint and development sprint appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.