1. Home
2. Blog
3. Remember the ignorance

I recently had a very interesting conversation with Steve Porter from Scrum.org. We discussed a Scrum team where developers are not pulling their work themselves. Instead, it’s a senior developer who, during the Daily Scrum, selects which Product Backlog items will be worked on that day and who will work on them. This senior developer is a well-respected member of the Development Team. So the question was, should a Scrum Master do anything about it?

 

On the one hand, the Scrum guide does not explicitly require members of the Development Team to pull their work on their own. The Scrum Guide also states “no one (not even the Scrum Master) tells the Development Team how to turn a Product Backlog into Increments of potentially releasable functionality”. So it looks like the Development team is doing Scrum, and there is no need for a Scrum master to intervene. However, there could be many possible reasons why this situation may require an intervention from the Scrum Master. Here are two: the definition of the Development team and Scrum Values.

 

First of all, this situation may contradict the definition of the Development team in the Scrum guide. The Scrum guide does not describe a Development Group. Rather the Scrum team has a Development Team. I believe that the word “team” was used intentionally and one of the main reasons why Scrum is so effective is that it is based on “a team” rather than “a group”. By definition a team is “a group of people who share a common team purpose and a number of challenging goals; members of the team are mutually committed to the goals and to each other”. In a Scrum context, we can consider delivering potentially releasable Increments as the Development Team’s purpose, and the Sprint Backlog as a set of challenging goals.

 

But it’s hard to be committed to something that you did not take voluntarily. On the contrary, a situation when someone assigns a person work makes this person less committed to accomplishing this work. A commitment is one’s responsibility, but if one does not make a decision, he or she will not take responsibility for that decision. The best you can get in such a situation is an obligation, but not ownership. So by assigning Sprint Backlog items to Development Team members, a senior developer destroys a team’s ability to be a team. This situation might also violate the Development team equality principle: “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person”. But here it might be that “all developers are equal, but some developers are more equal than another”.

 

 

Secondly, this situation seems to contradict the Scrum values. We’ll start with a quote from the Scrum Guide: “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” I have already described above how this approach can destroy the team’s ability for commitment. People do not personally commit to achieving the goals of the Scrum Team. This situation may also be a sign of lack of respect. The Scrum guide defines respect such that “Scrum Team members respect each other to be capable, independent people.” But a situation when someone defines what piece of work one should do on a given day is far from treating that person as a capable and independent (not to speak about showing respect). This is rather a demonstration of a lack of trust in one’s capability. Such a situation is very toxic for team morale and performance.

 

Thinking all that I concluded that that team is not doing Scrum and the Scrum Master should intervene by raising the team’s awareness of what is going on and how this influences a team. Being pretty confident in my conclusion, I shared that with Steve, and his reply was: “be careful not to make judgments about how a Development Team decides to work. If you see behavior that you don’t understand or feel could be improved, approach the situation from a position of curiosity. Remember, the people closest to the work are in the best position to decide what’s right and wrong.” I thought to myself: “Man, you were the one speaking about beginner’s mind and importance of context, and you’ve run to the very mistake that you were teaching to avoid!” Working for a long time for big companies, I was literally paid to have the answers.

 

At some point in time, I realized that my success was due to asking questions, and helping my team find the best possible answer, rather than comming up with my own solutions. That was the reason why I started to learn about Agile, Scrum, self-organization, team, etc. In general, that is why I do not stop learning things. And that is what I am teaching others. “Remember the ignorance” — that was my advice for my students. And now I failed to live up to my own advice. That was really sobering!

 

When working with people, things are rarely the way they look at the surface. Every situation, every problem is very context-specific, so you can have different solutions for two (seemingly) similar questions of the same person — because these two questions sit in a different context. So just looking at the surface is not enough even if things look obvious, because there is a good chance that they are not. It is very rewarding to act “like a smart guy” and have a clear answer to any question. Being an expert. As Mike Maddoc writes in Forbes blogpost “As experts, we get paid more, trusted more and sometimes even honored more. Our parents are proud, our partners are proud and sometimes even our kids think we’re cool.” That leads to a very straightforward thinking. We know too much and forget Socrates lesson that we know nothing. And that leads to wrong decisions, sometimes with bad consequences, sometimes with catastrophic ones.

 

And I do not want to be that kind of person.

 

I want to avoid an expert trap. I choose to have less confidence in what’s best, choose to be curious, ask questions and be open to learning the answers, and by doing that to be able to co-create a better solution in collaboration with the people involved. I will ask myself “What else is there? What am I missing? What could lead me to an opposite conclusion?” So I wrote a mantra on a card that I have now in my wallet, and I re-read it several times a day:

 

Remember the ignorance.