Tag Archives: scrum

Scrum hoax #2: the Scrum master handles all conflicts

Any activity done in group may create conflicts between individuals.Scrum, by proposing self-organized teams synchronized by ceremonies and pair-reviews, may bring to the surface conflicts within the team and outside the team. A common thinking is that it relies on the Scrum master to solve these conflicts.  In this article we will review where the … Continue reading Scrum hoax #2: the Scrum master handles all conflicts

The role of Scrum master regarding team conflicts

Any activity done in group may create conflicts between individuals.

Scrum, by proposing self-organized teams synchronized by ceremonies and pair-reviews, may bring to the surface conflicts within the team and outside the team. A common thinking is that it relies on the Scrum master to solve these conflicts.  In this article we will review where the role of Scrum master lies regarding conflict resolution.

Last week, there was a conflict between two members in a team that I coach. Apparently the organization, including the team members, were expecting the Scrum master to take care of that conflict. He was not so sure about his role into it.

So we discussed about that question: is it the responsability of the Scrum master to solve conflicts in Scrum?

It is common for organizations to miss the soft skills required by the job of the Scrum master. Conflict is an opportunity to review this part of the role.

Conflicts within the team regarding the work to do

This first situation occurs when several people in the team cannot agree at all on a subject that relates to the work to be done.

It can occur on a very large set of topics, from trivial like code formating, to more in depth subject like architectural style, aesthetics, columns definition of the sprint board or branching strategies.

See our article on branching strategies in Scrum if you are in this case.

Under these circumstances, the conflict can block the team to progress. It is then an impediment. It is the role of the Scrum master to help fluidify collaboration and solve the conflict.

Many tools, not specific to Scrum by the way, can be used for this, depending on the situation.

Here are a few techniques, more or less sophisticated:

  • - rediscussing roles and expectations. No, a senior developer should not assign work. Yes, a PO should write understandable, coherent and scoped stories...
  • - getting back to the actual need. Many architecture discussions can be solved by reviewing non functional requirements or product vision with the PO
  • - the technique of the three amigos to add a new perspective to the topic
  • - one-to-one coaching session can be helpful
  • - rationalize the conflict is as well a top priority. Easier said than done, but still required
  • - the help of an expert can be interesting in some cases

In that area, the role of Scrum master as facilitator, oriented towards maximizing team collaboration, will play a key role.

To establish mutual respect and active listening within the team may require sharp soft skills and emotional intelligence on the Scrum master side. It is crucial to get a happy and high performing team.

Scrum ceremonies speed up conflict emergence (and resolution)

As we mentionned, Scrum strongly relies on interpersonal communication to build a product. Many ceremonies are made to enable autoregulation within the team, with peer-to-peer discussions on a very regular basis. It is efficient but if not properly handled, it can lead to bad situations.

Take the example of a newcomer that is not motivated because he feels completly lost in the product. He is not working very efficiently so he does not progress much on what he is working on.

On a regular V-model project, he may have the opportunity to hide a bit the lack of progress. He may keep the problem to himself as he does not feel comfortable in sharing its difficulties. Result is that he will leave the team or that few weeks or months later, someone will realize that planning is at stake.

In Scrum, he will have to stand in front of the team and answer the question of what he did the day before. That again and again every day up to the end of the sprint, ie between 10 and 20 times! This will for sure catch his mates' attention as that situation endangers the team's objectives. And that is great if the setup is good: the team can quickly move to the resolution of the problem and improve the situation of that newcomer: let's work in pair on your story!

In that case, the conflict can be resolved by the team itself thanks to the framework.

When conflicts between team members become toxic

Helping to resolve conflicts that arise during the crafting of the product is one thing. But when toxicity steps in that is a totally different story.

Team members can have strong incompatibilities, far beyond a temporary divergence on the best solution.

This kind of conflict is not only a timebounded impediment of the team, it is a fundamental long term issue in the team and beyond.

In such a situation, the role of the Scrum master is typically to:

  1. 1. Identify the situation as a conflict
  2. 2. Try to solve with various conflict management techniques (see this good article for example)
  3. 3. Diagnose that the problem goes beyond temporary impediments
  4. 4. Hand-over the problem to a role in the organization that is typically fit for people management (People Manager, HR, ...)
  5. 5. Follow-up the situation and mitigate the impact on the team

Hopefully by applying this simple method the Scrum master will manage to minimize the damages such a conflict may create in the team. Preserving team coherence under these circumstances is a real challenge.

Wrap-up: the Scrum master role facing conflicts

To summarize, we can say that no, the Scrum master does not have to handle all conflicts within the team.

As a facilitator, he has to take care of the potential difficulties team members have to collaborate in the day-to-day life of the team. For that, he has to demonstrate extensive soft skills and should continuously work to setup a good atmosphere.

When things goes beyond the resolution of temporary conflicts, the Scrum master should raise alarms within the organization that a recurring and potentially toxic situation is in progress and should be taken care of.

You can get help to implement Scrum !

 Visit our website for more information on our offers

Scrum hoax #1: The black box syndrome

Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a … Continue reading Scrum hoax #1: The black box syndrome

Fighting lack of transparency in your Scum implementation

Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a perfect opportunity to open this series of articles around the Scrum hoaxes. In today’s article we will discuss the black box syndrome some organizations encounter while implementing Scrum, and cover the possible causes and solutions.

Some times ago, I had a discussion with a senior product analyst about how Scrum impacted its organization. Like some people complaining here and there, he was not happy at all with the methodology. Bottom line, the issue was that since the implementation of Scrum, the teams around him were completely black boxes. A common issue indeed, that may come at very different stages of Scrum adoption. It is very sad because it is usually due to a bad way to Scrum. This situation, like all the others of this series of article, is not due to Scrum but to how it is implemented.

So how a team, after implementing Scrum, can be perceived as less transparent than what it was before?

Obviously, it comes from the fact that some aspects of Scrum are missed, but it is not so trivial to see what is wrong.

I will share below the most common category of mistakes I have encountered.

Case 1: No (or ghost) Product Owner

Yes, I have met teams where the role of PO was simply not filled. The Product Owner being in charge of the product backlog, the issue is obvious and immediate.

A very similar flavor is the Product Owner is appointed but too busy to take care of the backlog, or not trained to or convinced by Scrum. At best there are a bunch of badly written stories, at worst nothing at all and the Product Owner sends an email to the Scrum master here and there to ask for things.

Without a proper and up-to-date backlog, no visibility on the product, either inside or outside of the team.

To get out of this situation, the organization needs just to take the subject seriously: the role of PO is critical to a working Scrum team. He should be knowledgeable, accountable, available and invested in the product. You could be interested in reading about the technical skills of the PO.

I would love to say that this is the least frequent case, but sadly it is much more common than you think.

Case 2: No (public) demo

The sprint review meeting is the opportunity for the Scrum team to demo the proposed product increment to itself and potentially key stakeholders. It is as well the opportunity for the PO to decide to release this increment or not.

The first possibility is for this meeting not to be held or to be badly run. Relating to the previous case, if the Procut Owner does not attend this meeting it will be extremely hard to discuss with stakeholders what has arrived and what should come next.

In the situation where the PO is there, but if no stakeholders attend to this demo meeting and if there is no other way for them to see the increment and provide feedback, it naturally results in poor transparency on the Scrum team output.

Our advice here would be to invite key stakeholders to the review meetings to provide them the best visibility.

In addition, especially if the point above is not doable in your particular setup, you should put in place the means for the feedback loop to be available. It depends heavily on what comes next to “Product Increment is shippable”, i.e. the path to users after the sprint.

A solution can be a webinar (for very large audience), a platform to demo your new version, a recorded demo sent to stakeholders or even some canary testing on your production environment. We will cover more on these possibilities with articles on release management but in any case you need to put in place a feedback loop.

Case 3: Private backlog

If with the situation of secret project put aside (military or equivalent), this is astonishingly frequent: the team has a backlog that no one can see outside of the team.

You cannot expect the stakeholders to participate if they cannot see what the product owner has in mind and how their feedback is taken into account.

The solution is obviously to make sure the backlog is available to your stakeholders. The clearer the backlog is the best, so the tool selected should have a good navigability and it should be obvious how to find your backlog.

Case 4: No roadmap

With case 1, 2 and 3 covered, you have a reasonably well written backlog and a two-way communication is established between the stakeholders and the team about newly built product increments. The next source of issue is trickier: what comes beyond the current sprint.

Most organizations and actors in the field of software edition (and engineering in general) are expecting a form of roadmap. Yes, it is usually not reliable and not adaptable. It is not meant to be a commitment on the few next months, but it is valuable to give some visibility on what you hope to accomplish.  

Looking at a way to get Scrum roadmap easily? Check out Stenusys Scrumboard that provides an automatic planning on your product backlog.

Case 5: No readability on what the stakeholders want

A backlog gets denser and denser as long as you are getting closer to the next sprint items, as you will detail more and more the content of the stories. From an external point of view, it may be very hard to find out how a suggestion or request has turned into a list of stories.

A good way to do it is to differentiate the stakeholders’ requests from the stories themselves. You can use epics, but it can get complicated for different requests fulfilled by the same stories.

The best option is to distinguish the requests from the stories of the backlog and make sure each request is updated based on the status of the stories implementing it.

Find out how this works in request management of Stenusys Scrumboard.

Case 6: Private Sprint Board

When some critical stories are under implementation, stakeholders may be interested to see if everything goes ok. It is not that they can do a lot about it in most cases but that sure means they may not appreciate to wait until the sprint demo to get news from you.

To make sure the information is available at any time, without a need to compute manually reports, it is a good idea to have a sprint board fully open and easily accessible. The best option is to have your backlog browsable in your Scrum tool.


Closing up, transparency is one the key value in a business relationship. It is required to setup the viable working environment you need to work efficiently, based on trust between the team and its stakeholders. 

If well applied, Scrum is a great enabler of transparency. By following the suggestions proposed in this article you should get one brick to put in place a healthy product engineering team. More to come...

You can get help to implement Scrum !

 Visit our website for more information on our offers

Should a Scrum Product Owner have technical skills?

In agile transformation projects, the position and scope of the Product Owner role is often source of confusion. Most agilists get that it is about translating user wishes into stories. Functionally it seems OK (thus it is not always easy to do). But a software product is more than a bunch of features. If you … Continue reading Should a Scrum Product Owner have technical skills?

The difficulties of dealing with technical requirements in Scrum

In agile transformation projects, the position and scope of the Product Owner role is often source of confusion. Most agilists get that it is about translating user wishes into stories. Functionally it seems OK (thus it is not always easy to do). But a software product is more than a bunch of features.

If you have seen conflicts between the Product Owner and the development team about a technical change (refactoring, framework updates are common ones), you are at the right place. In this article we will propose a review of what the role of PO consists in with a focus on technical aspects. We discuss then how it impacts the staffing for this position. 

The obvious

All Scrum practitioners know that the PO is in charge of maintaining the product backlog. It includes defining the functional solutions to answer the customer needs. The Product Backlog Items (PBI), often called stories, are designed vertically so that each of them brings value. They are arranged by priorities in the product backlog.

When we describe the PO role, the first answer is that the PO has to understand the customer needs and drag from it the actual functionalities that the product team should develop. The PO incarnates here the customer and transform its needs into small chunks that brings each a piece of value.

This is absolutely correct yet incomplete. The tendency to see only this part of the role is the root of the issue faced with technical developments.

What is a product?

Scrum methodology makes an extensive use of the word “product”. It does not give any detail on what the word encompasses. In fact it will vastly depend on the context in which Scrum is used.

For the sake of defining the boundaries of the Product Owner role, it may however be of some help reviewing what a product can be.

Limiting ourselves to software, we can already have a wild variety of product size and complexity. Let’s present few examples:

  • - A mobile application executing basic functions like a hangman game
  • - A mobile application executing basic functions, and connected to several backends to ensure communication and data persistence like a messaging system
  • - A library executing a rather simple set of functions like a logger or a connector
  • - A library executing complex functions like facial recognition or a video game graphical engine
  • - A service of low functional complexity like a basic e-commerce site
  • - The same service but scaled to the extreme and running on thousands of nodes with failover
  • - A complex framework handling complex use cases like an application server
  • - A distributed system offering sophisticated services like a Global Distribution System

Obviously, if all these type of software systems answer functional needs, the technical complexity of each is hugely varying. The importance of technical knowledge at Product Owner level varies with it.

All in all, a product is not only a set of functionalities but a software artifact with many characteristics like performance, security, portability, extensibility, etc. This may or may not be a major concern for the PO depending on the very nature of the product itself, but it sure requires to be assessed.

Back to responsibilities in Scrum

The development team is responsible for proposing a product increment fulfilling predefined done criteria. It covers any aspects of the software, both functional and non-functional.

The PO has to express the needs, including non-functional aspects, and accepting the increments, i.e. to understand how the team addressed these points.

The technical aspects can come in two flavors: as acceptance criteria of stories or as standalone stories.

Non-functional acceptance criteria

A software artefact is more than a bunch functionality. Depending on the business environment you are in, the constraints will be different. But if a feature increases by 200% the memory consumption of Google search Engine, I doubt it will reach Google production servers.

The Product Owner is in charge of writing product backlog items. It includes writing technical acceptance criteria (response time, memory footprint, deployability..., the list is long). As with any criteria, this is a subject that can be discussed with all stakeholders, included the development team itself. But all in all the PO is accountable for it.

Back to the different type of products, it can clearly see that the frequency to which the PO has to work on these acceptance criteria will vary a lot.

Technical stories

This is the most common case of issues: the development team wants to rewrite a part of the product, independently of any functional stories. And the PO does not accept it. In some cases a story is written but never prioritize in a way to allow an implementation.

First, let's evacuate a common misunderstanding: a story is not necessarily functional. The backlog contains Product Backlog Items that can very well be technical. However, a PBI must have a business value, including the technical ones.

And there is the difficult but necessary part: assessing the business value of a technical story. It means that the request of this story (usually the development team) must explain the proposed technical change by its justification (the WHY) and not by its content (the WHAT). By experience it is very difficult and may lead to challenge the fundamentals of developers's ways, yet it has to be done.

You propose to migrate from JBoss 7 to Wildfly 10? Why?

You propose to refactor the payment module? Why?

You propose to deploy via Docker containers? Why?

They are good reasons to do these three things. We could imagine discussions around continued support from the community, speed of integration of new payment providers or ease of deployment. But they have to be valued against features asked by the users. 

Again collaboration is probable and wishable, but if the PO is fully hermetic to any form of technical discussions, it will be virtually impossible to get anything done.

Skills: who could become Product Owner

We see around many agile transformation with very different results. A usual source of issues is the appointment of the Product Owner in the newly formed organization.

As you might have guessed, there is no unique way to select a PO. It does depend a lot on the product but as well on the company context, the support the PO could get from its organization and how impacting it could be if he needs to answer team’ questions with a delay…

As far as the technical subjects are concerned, it is important that the technical skills of the PO are aligned with the technicality, complexity and ambition of the product. These three axes will define how much technical stories and non-functional acceptance criteria will show up.

In any case it can be difficult to get rid of the habits acquired in one position when taking a Product Owner role. And this is one of the reason to avoid “Scrum, but”: if a PO goes beyond or below the expected scope of its position, it can damage the organization a great deal.

The role of the Product Owner in Scrum is absolutely critical. If a member of the development team can be challenged rather quickly by its peers during ceremonies, the effects of a poorly chosen PO are not immediately visible and often extremely harmful.

And no, in most cases a good relationship with customers and management is not enough to be a good PO. 

You can get help to implement Scrum !

 Visit our website for more information on our offers