Lloyd Taylor of LinkedIn once said: “You can’t directly change the culture. But you can change behavior and behavior becomes culture“. My experience of SCRUM transformation of development teams proves that. Changing the ritual is the least resistance path and typically helps the developers to adapt to the changes related to SCRUM transformation.
The essential component of this transformation is how the developers think. As with culture, it is tough to directly change the way they think, but we can always change the way developers speak and let the new communication rules to change the way they think.
Many developers, often older and highly qualified, aren’t the best examples of the team players. However, whether we like it or not, software development is a team play. If just one fails to do his or her part, the product cannot be delivered, and every single person in the whole time is affected.
So, there are top four phrases that must stop to be used by a team that has just started their journey into SCRUM.
1) Do not say: “I did my best, but…”
If we fail – we fail, no matter how much effort we made. If we sit in a restaurant and the server drops our food to the floor, we don’t care how much effort put everybody from the farmer to the chief. The food is not on our table, so we have no desire to pay for that. The same happens with our customers – if we cannot put the properly baked product on their table, they, for some reason, don’t demonstrate intent to pay.
Fails happen, but there is also a proper way to fix and avoid them. There is a core responsibility of every team member to minimize the negative consequences of a fail and to prevent it in the future.
What should be said: “I wasn’t able to reach my goal, but this is the part I completed in full, and this is how the customer can benefit from that. There is a list of impediments that prevented me from completing all the work. And there is my plan to improve the process.”
2) Do not say: “Just tell me what I should do.”
Only developers who solve customers’ problems do the real work. The others only produce waste or ask the team to create waste by hiring “babysitters” who will take care of the developers who don’t care themselves about the customer. It is the distinction between “a coder” and “a software developer.” A coder performs mechanical work, and a developer creates value for the users. Anyone, who doesn’t want or can’t develop the product, pretends to be a developer and cheats about his or her qualification.
What should be said: “If I can help the team to reach the goal, advise me on the best way to do it. In my opinion, it would be best if I help with this…”
3) Do not say: “I don’t understand; you/they didn’t explain it well enough.”
Joining the team, everybody accepts the rules and takes his or her part of team responsibility. When somebody does not understand a customer or a colleague, it does not mean that customers and colleagues failed to create a proper environment. It does mean that somebody does not pay respect to the team and the customer and doesn’t apply enough effort to understand.
What should be said: “Would you please confirm that I understand you correctly.”
4) Do not say: “I did my part.”
Like in phrase number one, if one fails – the whole team fails. It does not matter how well somebody did his/her part. If the entire product is not ready, then it is not ready. Everybody is responsible for the whole team result.
Let me tell you a story. A long time ago, when I just learned how to drive a car, my grandfather, a seasoned truck driver, taught me. “Boy, thou art the only one who is fully responsible for everything that happens on the road. Don’t consider anyone else an accountable or even a sane person. If something happens with thou, thou wilt be the only one who will deal with consequences“. I use this rule for every time when I have to do something not alone, and it helps me a lot.
What should be said: “Unfortunately, I failed to help the team reach the goal. However, I know the impediments, and there is a plan on how to remove them.”
I also should note that this is one of the most significant challenges for scrum masters and facilitators. When there are even just a few people who care about the whole team, way too often, there are also people who abuse the situation. These people stop doing their part of efforts letting those who care to do all the work. You should closely monitor the team and should not enable such behavior, as it dramatically demotivates the team members are most important for the team’s success.
And always remember, changes don’t come easy. The SCRUM transformation is not something that happens overnight. Often you’ll have an almost irresistible desire to “fix” SCRUM to adopt it faster. Never do that. Scrum is supposed to be and maybe augmented, but nothing in the core set in the SCRUM guide is wrong or excessive. Every element is critical for successful SCRUM and must be implemented in full.
Good luck on your way to SCRUMisation of your development processes!