Few days ago I came across this article on Stack overflow.

It took me a few days to think about it and I want to share some thoughts on what the article called the scrum pitfalls.

Scrum pitfalls or no Scrum pitfalls?

The article mentioned ten nine scrum pitfalls that stuck out.

Let’s go one by one.

 

1- Stand-ups are for managers

The main argument here is about the dynamic that happens during standups and that the daily is only useful to the managers.

It is indeed a recurrent team feeling I came across during my career.
Mostly it happens in organization where values such as self-organization or autonomy are not promoted; when micromanagement is part of the company’s culture enforced by the leadership and / or the team manager.

Sometimes, I saw it happening whereas the organization was promoting the above values but the team looked like it was auto-censoring itself to look good to its manager or Scrum Master.
This last one is especially reinforced in a context where the team manager has almost a “paternal” figure with the team.

So what to do if you realise the stand-ups are not bringing value to the team?

Make it obvious

As a Scrum Master:

• Talk with the manager about the issue
• Use some techniques like ROTI (Return on Time Invested) to gather live feedback
• Use anonymous survey on this topic if you feel the team is not comfortable to speak up
• Change the questions of the daily meeting every now and then
• Ask team members if they want to facilitate the daily meetings with you. It will share the responsibility of the daily with the team

As a dev team member:

• Talk with your Scrum Master about the issue
• Be willing as a team member to ask yourself what you could do to improve the daily
• Ask the question to your teammates
• Ask the Scrum Master to facilitate the daily meeting and set up a rotation facilitation between all the team members
• Ask for the Scrum Master and management to not attend during 1 sprint to reinforce your self-organization as a team and assess

Remember the daily standup is for the team to synchronize activities and create a plan for the next 24h. If the daily standup is not useful for the team members then address the issue and experiment with it, until you found your own useful way. Like everything else, it is by experimenting that you will find something working for you.

 

2- Prioritising “done”

The point said here is by tracking progress with the velocity then it might mean the team will cut corners to put in “done” the items as fast as they can and potentially put in jeopardy the quality of their developments.

There are several points this sentence triggers in me and let’s start by the most important.

• Definition of Done. Definition of Done. Definition of Done.
  The number of teams not having a definition of Done or DoD is actually quite alarming.
  Scrum relies on transparency. This is one of its core pillars along with adaptation and inspection.By not having a Definition of Done, the team shot itself in the foot.
  The Definition of Done in practise is a checklist of all the activities that must be performed by the team to be able to say “this is done”.
  This Definition of Done needs to be clear for the whole Scrum team AND the stakeholders as it is used to assess when a work is complete.
• Metrics.
  If you measure only velocity for a team then you only get a partial information of what the team is really doing and it says nothing about whether the team is actually delivering something that is useful to its end-users or the company.
• Velocity per team members.
  Short answer: NO.
  This purely does not make sense. Team members are not here to compete against each other.
  We have a team so we can achieve together a common goal.
  Period.
  As a scrum master, a manager, a team member ask: could the team achieve its sprint goal?
  To assess the individual performance of a team member there are plenty of other ways.
• Sprint Goal.
  The sprint goal is also one of those regularly missing items of a Scrum team.
  By not having a sprint goal you just have a sprint containing a bunch of tickets with potentially no relation between them. Is there any sense of purpose to what we are doing? Again, what is the value the team is delivering to the company, to its end-users?

 

3- Very productive individuals that don’t work as a team.

Don’t blame Scrum if you have a team problem.
When very productive individuals don’t work as a team, this is not a Scrum problem, this a team problem.
As a team, you need to explore this problem.

Is there feedback regularly being shared between team members?
Are the team norms clear for everyone?

One way could be by gathering the team and put the elephant in the room on the table.
Eat it piece by piece until the team problem is solved.
Another way could be by regular feedback from team members.
Remember that if you have a team it it is to achieve a common.
What is this common goal? How do we work together? What are our interactions and relationship?
There is a lot to explore.

As the old adage says “if you want to go fast then go alone, if you want to walk far then walk together”
As a Scrum Master, manager, even team member, explore those questions above with your teammates.

 

4- Complicated tasks get deprioritized

In direct relation with point 2, priority needs to be agreed & understood by everyone.
If a big task needs to be done because it is a priority then it HAS TO be done.
High priority tasks should be started first in a sprint.
Scrum Master is responsible to remind this to everyone and makes sure the PO shares the priorities to the team and that the team understands it.

Defining a sprint goal surely helps there.

If you spot that complicated tasks get deprioritised then assess if the team has the correct priority in mind.
Is the PO working enough with the team to define priorities?
Is the team pressured too much by management?
Is the team seemed to be in a manufacturing mode?

 

5- Features over robust code

The belief in this paragraph is that scrum promotes only features being shipped but no robust code and that robust code defines what makes developers being great. If the PO is not a technical then s/he cannot evaluate the code as long as the feature.

First question to this is: Why would the dev team need another person then itself to check the code?

Again this could be resumed to:

Definition of Done

How about pull request, code review, etc, being part of the Definition of Done?
How about having the dev team creating its own quality rules for the code?

All above helps to write robust code and does not require the intervention of anyone except the team members.
Leadership, managers, Scrum Master, Product Owner, everyone exterior to the dev team needs to empower the dev team to take its own technical decisions.

This is actually strongly promoted by Scrum.

 

6- No time for cross-pollinating or exchange with peers

The argument here is that if only velocity counts then the team cannot consult, exchange with peers and experienced developers cannot cross-pollinate ideas.

I encountered this situation quite a few times and this is still not a Scrum problem.

The first part in the sentence is about velocity.
As I said in point 2, if you only measure velocity then you only get partial information of what the team is doing. Building high performing teams is not about high velocity. A high performing team is an entity far more complex that cannot be defined by only one measure.

If you need an activity on how to use the high-performing tree activity for your team to develop high-performing characteristic you can refer to this article. 

The second part is about great developers who are sought for advice and review.
This is true, and therefore it needs to be said out loud and acknowledged by the team and the organization.

beSome organisation have role expectations in this sense so seniors developers have their “coding capacity” reduced in the team and their individual goals don’t reside in “producing code” but rather in cross-pollinating ideas, exchanging with peers, looking at the software from a holistic perspective and making sure the architecture makes sense.

If you see in your organization there is that kind of situation, my advice would be to say it and look for the definition of the role expectations.

 

7- New bugs have to wait

Bugs are found after the end of a sprint and therefore they are counted as new work. The argument here is that developers might release flawed code because of this new work that cannot be included in the current sprint.

Quite a few ideas in this only sentence.

1. What about the code quality, quality testing, quality assurance / assistance being part of the definition of done so as to avoid finding bugs after a sprint?
2. Nonetheless, we know we might have bugs so what about the criticality of the bugs?
3. What about the negotiation with the Scrum Team?

The theory of Scrum is that a sprint should not have its scope changed but one of the values of Scrum is also about openness and agile mindset generally is about flexibility.

Huge prod bug? Nobody will wait for it to be fixed.

Put it in the sprint, just understand as a Scrum team the cost of:

1. switching context for team members
2. if the team committed to a determined scope for the sprint then this commitment is affected
3. something else that enters the sprint then it might mean something else has to go out of the sprint and that won’t be worked on.

The dev team committed to a sprint goal, to a determined number of items. Disrupting this has a cost that leadership, managers, stakeholders, product owner, dev team itself need to understand.
Here the Scrum Master has the responsibility to facilitate the conversation and negotiation and to make sure everyone is aware about the cost.

 

8- Ticket driven architecture

The suggestion with this point is that scrum creates messy architecture.

In my experience, this might be a more regular problem of inexperienced teams.
Again this is not a Scrum problem as Scrum says nothing on how to deal with the architecture.

Would it be rather a refinement problem, or an anticipation problem of the future work to come? Does the team understand the global and long term vision of the product they are building?

Scrum does not say to only look at items in your iteration window, scrum mentioned the need to look at the backlog regularly and what might come the way of the team.

Use regular spikes, architecture review tasks, workshop for cross-teams, brainstorming infrastructure sessions, etc. All of this makes sense in the context of Scrum or any other agile methodology used.

 

9- One process to rule them all

I am a big fan of the LOTR but contrary to the One ring, Scrum does not rule over engineering practices and agile principles & values.

Scrum is a framework.

The definition of a framework is to provide a frame and inside this frame to do whatever you want and whatever makes sense for the company, for the team, for its individuals.

Scrum is a set of tools and practices, if you count on a set of tools and practices to fix all of your problem, then you will be strongly disappointed.
Unless the organization, your team, you develop the mindset associated to the values and agile principles there will be no guarantee it will work for you.
The pitfalls mentioned above are not related to Scrum itself, those pitfalls were present and existing before Scrum. The only thing Scrum does is clearly showing them.

Scrum was made lightweight for a sole reason:
the Scrum team is to experiment and find what works the best for itself.

Organization adopting agile practices seek to improve their business and team’s performance. Scrum like any agile methodology is used as a mean to an end, not an end itself. :

Scrum found its success and widely adoption as it is easy to start with but as the authors of Scrum said: “Scrum is easy to understand but difficult to master”.
Mastering it comes with the management and team’s ability to reflect on themselves and to self-improve.

How do we work and why do we work this way?