In episode 79 of Dave Saboe’s excellent podcast series, “Mastering Business Analysis,” Dave interviews Paula Bell about effective collaboration. Here’s the link: http://masteringbusinessanalysis.com/mba079-effective-collaboration/
One point in particular stood out for me in this episode: “It can be challenging to collaborate under the pressure of deadlines. It’s worth taking the time to get to know one another and to some team building.”
It reminded me of situations that were common in the 1980s in corporate IT work: The “sweatshop” environment, in which working life comprised an unending series of death marches punctuated by physical/mental/emotional crashes.
Younger colleagues tend to roll their eyes at this, but the plain truth is that this mode of work was the norm in IT in the 1980s. It was considered part of the career choice. People who could’t endure it ended up changing careers (or worse).
Paula has significant experience—nearly twenty years— but her experience began in 1997, after the era when the death march was regarded as normal and expected.
When Paula talked about delivery pressure, she seemed to be relating to a situation that is more common today than it was in the 1980s; it’s what I would call routine delivery demand—nothing exceptional at all; not pressure above and beyond the normal demands of the work.
The idea of taking the time to learn Active Listening and other collaboration skills, and getting to know team mates and building relationships, makes good sense in most software development environments today. Paula talks about stopping by other people’s desks to share a quick cup of coffee. She also assumes there are breaks in the work day; morning and afternoon, as well as regular lunch breaks and a more-or-less normal daily work schedule.
In the sweatshop, there’s no “few minutes before a meeting,” there’s no opportunistic “quick cup of coffee.” There’s no lunch. There are no normal work hours. There’s only the cycle of sweating and crashing, over and over again.
And yet, collaboration was and is perfectly possible without any opportunity of opportunistically getting to know each other. We used to do it all the time. Here’s how.
When the time came for the next death march, we moved the cubicle walls around to form a “war room” area. We forwarded our desk phones to the war room. We buckled down and did the death march.
The degree of collaboration was extremely high. The challenges to collaboration that Paula (and others) mention were absent. No one “refused” to collaborate. There was no way for anyone to go home—ever—unless they did so. It was the only way to get the thing done.
There was no training, no behavioral modeling by management, no sense of community apart from shared suffering, no ping-pong table, no nothin’. And yet, people collaborated seamlessly. There was no doubt about the common goal in a death march, and everyone was in the same war room area day and night, so if anyone lost track of the goal they could easily get back on track.
My purpose here is not to dispute Paula’s observations and experience, nor to deny the reality that many practitioners have experienced with respect to collaboration. My purpose is to suggest that the elements that are necessary and sufficient for collaboration may not include all the “fancy” things that people assume today…psychological games, relationship-building, team heritage, etc. There may be correlation but not causation.
I say this because so many of us did this in the 1980s under conditions when we were on temporary teams, did not know one another outside of work, and had no idea what skills our team mates had until we were all in the shit together. These experiences, too, may provide information relevant to the subject of effective collaboration.
Collaboration still worked, and worked well, despite our total unawareness of psychological and sociological niceties and a complete absence of any sort of training. Technical professionals in those days tended to be snarky and sarcastic all the time; particularly those who had what it took to survive and thrive in the sweatshop. Maybe that was a survival mechanism, come to think of it. This didn’t cause people to curl up in a corner, weeping about how “mean” everyone was. Teams just forged ahead. We didn’t really need to “know each other well.” We just focused on getting the job done. It was collaboration, in the true and full sense of the word.
Today, I observe many teams that spend a great deal of time building relationships and discovering their MBTI types and all that jazz, and yet don’t actually deliver very much completed software. Ever.
The amount of work many Scrum teams agree to take on is sometimes surprisingly small. At one large client, a colleague who was to coach a team met with the team members for the first time and they explained the work they were planning to do. He said it sounded appropriate for a two-week Sprint. He asked them what else they were planning to do in the upcoming SAFe PI, besides just that small amount of work. They looked at him wide-eyed and gaped. That is the amoaunt of work we’re planning for the PI!
This was a team that spent a lot of time trying to build collaboration skills explicitly. The result was they were only able to deliver a quantity of working software in the space of a 14-week PI as they should have been able to deliver in the space of a 2-week Sprint.
So, if there’s any point to this post at all, it’s this: Be careful about getting tangled up with all the sweet little psycho-things that consultants want you to “model” and get “trained” on and all that stuff. Our job is to deliver working software. That has to come first. A professional will see that it does. Sometimes that calls for collaboration and sometimes it calls for effective individual contribution. Whatever is called for at the moment, just do it.