(Or is agile just another way of hiding it away?)
Imagine the following scenario
Fred is a senior developer. The team is doing Scrum for about 10 sprints now, and the ceremonies are kind-of getting into a routine. The team is committing for work to do, and delivering more-or-less what they promised. And yet, Fred is not a happy chappy.
The team is coming to their third release, and there are talks that regression period must be on time, on track this time.
In his frustration, Fred talks to his Scrum Master, expressing his concern that developers must do regression testing yet again in the upcoming regression period. Clearly developers should do coding, and testers should do the testing.
Joe, the Scrum Master reminds Fred that regression is for the entire team, not just for testers, and that they are all in the same boat, and that by coding away during regression they are merely adding more technical debt to an already potentially unstable release.
Fred walks back to his desk, muttering "right; and my testing skills are so good, that all bugs will be uncovered. Such a good tester I am".
What just happened here?
What are Fred and Joe really talking about? What aren't they talking about?
Given the conversation of these two individuals, what can we say about the atmosphere in this team?
Teams, Organizations and Lions
There is a lion lurking here.
A normal person reaction to seeing a lion would be: increased alertness, increased heart rate and increased perspiration – the automatic physical reaction required for survival in the face of danger. This is vital for survival, yet not a pleasant experience.
Therefore, a normal person, having the knowledge that a lion is lurking would act to avoid being seen by the lion: Acting cautiously, refraining from conspicuous and sudden gestures.
Let's relate this back Fred and Joe. Fred might be trying to say: I'm a damn good programmer, and by doing testing, I will be exposing my weaknesses. This is something I am not prepared to do!
Joe, on the other hand, is hiding behind Scrum (teamwork, technical debt) in order to avoid Fred's issues. He is using Scrum as a defense mechanism against dealing with what Fred has to say.
The thought of confronting these covert issues provokes anxiety. As if Joe is telling himself: I am afraid that if I talk to Fred directly about his subjective experience of being a tester, it may feel as if a lion is about to attack me. I am not prepared to handle such an experience.
Of course, both Fred and Joe don't necessarily articulate these thoughts to themselves. This, in itself, is too frightening. So they both unconsciously use their survival mechanism not to wake the lion lurking in the grass:
Fred resolves to focus on developing new stuff; Joe is using Scrum to get Fred to do testing, as he thinks the entire team also should.
Dealing with Lions
Is Scrum to blame here? Is Scrum in particular, and Agile in general doomed to fail in such situations like all other organizational methodologies?
I think not.I am paraphrasing on an expression used in Diana Larsen's and Ester Derby's book: Agile retrospectives – making good teams great: Agile belongs to a group of management frameworks that inherently advocate the use of "the 'F' word" - Feelings.
Fred is trying to say: I am afraid that by being a tester in the regression sprint my weaknesses will be exposed. I feel compelled to avoid this in front of the entire team.
Joe, as a Scrum Master, should be equipped to identify these Feelings; to sense that we are talking about regression, but, in fact, in the sub-text Fred is trying to say without words that he feels his own lion is lurking in search of him.
Many kinds of lions are spotted in various organizations. For example: Support ("handling this P1 call is a matter of life and death!"); Over glorified business goals ("get this demo wrong, and we can all start looking for a new job"); Coercive management ("don't mess this up, or the boss will be on your tail from now to eternity"); and so many more.
One of the aspects I like about agility is that it advocates being equipped with the knowledge and experience to identify such emotional blind-spots. Training programs, coaching, mentoring, retrospectives – are just a few examples that invite the development of such skills.
In this post I will focus on just one: feedback.
Organizations tend to treat feedback as a periodic activity, taking place one to four times annually. In our example, Joe would be expected to fetch his "little black book", and record the "regression sprint incident", and "take it to the positive place" during employee review by telling Fred something like: "you should understand that testing during regression is a team activity. Let's set a personal goal for you to get more involved in regression testing, and we'll review it again in six months. What do you say?"
This is like telling Fred – you should confront your lion! You've got six months to either kill the lion or make it go away or become friends with it. Hmmm..., not something most sane individuals do willingly.
Conversely, effective feedback giving and receiving is about providing continuous, relevant, specific, actionable feedback.
The effective feedback approach would commence along the lines of:
"Fred, I sense that there is something else bothering you. Is this a good time to discuss this?"
And, if the invitation is accepted, continue to something like:
"It feels to me that participating in regression testing makes you angry. By not participating in this team activity, you will be creating a problem for the team and for me as well. For example, adding new code during this period will create more testing effort for the rest of us.
What can I do to help you join in, without compromising your professional standards?"
Such a conversation: a) addresses the feelings involved; b) makes it a joint issue; and c) invites a conversation on the specific issues, rather than a general "this is Scrum" lecture.
How to give and receive feedback
Luckily, giving and receiving feedback is an acquired skill. If you want to learn more, there are many resources on this subject. For example, a short Google search revealed this good webpage: http://managementhelp.org/communicationsskills/feedback.htm
Does this make sense? Do you think this is achievable? Have you tried such feedback techniques?
And can you think of your own lions lurking?
Learning do deal with such "lions" is easy, if you have the right tools. One such tool is an Advanced Scrum Master workshop, where you will have the opportunity to learn and to practice, and to chase away some "lions" in your team.