My team consists of Frontenders, Backenders, a Tech Writer and a QA. I am their scrum master. They are working as a team for a while already. It’s a team in the sense that they work on the same sprint backlog, but they are not the team as you would see described in the Agile books: They are not cross functional.
I have been struggling for a long time trying to bridge the islands created by their specialisms. It’s true: a Front End developer does different things than a java Back Ender and a QA engineer. But I get the impression that everybody is doing their utmost best to ignore the possible areas of overlap and to avoid the type of cooperation that needs diving into each others’ work.
Gone fishing…
It happened this sprint as a total surprise that Julian, the Tech Writer, was not present at the standup. “Does anyone know where Julian is?”, I ask. (Silence…) “Isn’t he on a holiday?” The QA responds in surprise: “On a holiday? And what about his tickets? Did he finish his tickets?”
Expecting the Tech Writer to have done some handover, I ask: “Did he talk to any of you before he left?” Silence and eyes going towards the ceiling and the floor… So that’s a NO. “Well, let’s look at the board and we will see what the status is.”
Today is Thursday and tomorrow the sprint ends. We go over the board and see everybody has got a lot on their plates to finish by tomorrow afternoon. To conclude the standup, I ask: “Done? … So how do you guys plan on fixing the Doc tickets?”.
This is one of these awful painful Scrum Master questions that teams hate you for: They don’t want to hear that question because they know they don’t like the answer.
“Well, since Julian is not here, we will postpone them to the next sprint so he can finish them when he gets back.”, the lead Backend dev, who considers software to be the only valuable deliverable, replies baldly.
“Ah ok,”, I reply, “So what about your definition of done? Or does the DOD not count when people are on a holiday?”
Silence…..
“But we don’t know how to do documentation at all!” she acclaims.
“Oh, is that so?, I reply. “Are you sure? I remember that most of you were present in the technical writing workshop Julian gave three weeks ago. I think ‘not knowing how to do it’ is not the real problem.”
“But he did not tell us anything he was leaving! It’s his own fault that his work won’t be done.”, The QA tries.
“You know what I will do?” I say, “I will make a note to address this during retro or in a one on one when he gets back. So Julian knows he made a mistake there. But still, that will not solve delivering work according to your DOD…. Actually guys, this is fun! This is exactly what the standup is for: Make a plan of the day to get the work done! So what’s the plan?”
Silence….
“Well…. we will first continue to finish our work, if that’s not finished it makes no sense to start documenting things.” says the lead Backend and she looks at me from the corner of her eye with a small teasing smile to see if I will settle for this.
I say: “Good. That sounds like a plan. Thats it! Good luck!”
And off they go.
As I return to my desk, I am anticipating what other excuses I am going to hear from them. I decide to talk to one of the other tech writers to ask him for an account to the documentation system and availability for support if they have any questions. Thirty minutes later it’s arranged. I put account details and names of available Tech Writers in a mail and send it to the team. I ensure that the language is neutral and does not contain any hint to me expecting or telling them what to do. It provides them the stuff they can an use to get the work done.
Friday morning. Standup. I choose my position outside of the circle, as usual, just behind the team. Some tickets are being discussed. The regular stuff. Looks like they made good progress and will be able to finish everything. The doc tickets are untouched and are screaming to me from the jira board. I have difficulties not to intervene. Are they simply ignoring them?
As the QA, who was facilitating the standup, wants to conclude the session, the Front End developer interrupts and says: “But, hold on…. What about the doc tickets? We need to close them too, right? I mean, if we want to really be done.”
The lead Backend rolls her eyes and sighs, shoulders pulled up: “But we don’t know even what the status of this documentation is!”
Silence.
“Maybe the tech writers can see the status in Paligo (the doc tool). I mean, I don’t know, but we could ask if they can?” the Front Ender says.
“You know what?” the other Back Ender says, “I will contact Miranda and we will have a look at it.”
“Wow!”, I say. “This is really awesome. This was a real good standup making a plan for the day. And you really acted as a team. My compliments! I am really proud.”
I see puzzled faces showing what is, I presume, the surprise of getting caught in learning something valuable.
What can we learn from this?
Make sure you teach your team to understand the concept of cross-functionality and in what way it can be beneficial for them as a team. However, accept that they do not believe that ‘this theory of yours’ is true and accept that in many cases, specialists will not be inclined to try it out at all. People are happy in their comfort zones and will stay there, unless there is a disturbance that forces them to move out of it. Patiently wait for that disturbance, that one occasion, to offer cross-functionality as a real solution for a real problem the team is facing.
Leave a Reply