There’s a common model people seem to believe in implicitly, known as the Tuckman model, named for psychologist Bruce Tuckman, who published the idea in 1965. The idea is that all teams go through several distinct stages: Forming, Storming, Norming, and Performing. You can probably guess what those stages are like based on their names. The model has been a mainstay of agile coaches for many years.
But I’ve had doubts about the Tuckman model for a long time. My personal experience has been that once people get used to working in a collaborative way, they can move to new teams without any friction.
Continue reading Whither Tuckman?
The Code Freeze 2021 virtual conference culminated in a two-hour mob programming (a.k.a. ensemble work or samman) workshop. Seventy-four participants worked in 17 groups, each facilitated by an experienced mobber. Facilitators included such luminaries as Woody Zuill, Llewellyn Falco, and Jeff Langr, among lesser lights.
Continue reading Code Freeze 2021: Mob Programming Workshop
Contemporary software development methods emphasize collaborative work over solo work. I remember this idea gaining momentum from as far back as the 1990s, when Extreme Programming was becoming known, including one of its core practices, Pair Programming.
In retrospect, I can recall many instances when people collaborated in an ad hoc way to solve specific problems, going back to the beginning of my IT career in 1977. I’ve read articles and heard stories about the value of collaborative work in engineering going back at least to the 1950s. There was even a deliberate experiment in 1975, carried out by the US Army, on the value of “two-person teams” in software development (the article does not appear to be online anymore, but there is an excerpt in this old blog post: Does pair programming work?).
In all these cases, from formal studies to informal “war stories” told over coffee or beer, direct collaboration provided immediate and palpable benefits to the people involved. That has been my experience, as well. And yet, it seems as if solo work continues to be the norm.
Continue reading Collaboration
There’s been some online chatter recently about an old topic – the need for uninterrupted focused work time when doing software development. Some of the comments have surprised me, in part because I thought it was a settled topic. That was silly of me, because of course there are no settled topics.
But it surprised me, as well, because some of the comments suggested a fundamental misunderstanding of how creative work is done: Some people treat creative work the same as repetitive tasks, such as sweeping the floor or washing the dishes, in that they assume creative work can be interrupted over and over again without any cost.
Continue reading What’s the cost of interrupting developers?
The relative effectiveness of collaborative work over individual work for many (not all) activities has become well-enough established by now that hardly anyone questions it. No one establishes an “agile” work space in such a way as to maximize disconnected, individual work and to minimize direct communication. That would be absurd.
And yet, people are determined to defend their comfort zones. A popular way to avoid working collaboratively is to say, “I’m an introvert.” Often, this is stated flatly, with a tone of finality, as if the word “introvert” completely explains why it is impossible for the individual to collaborate with others. Obviously, an introvert has to work alone all the time. They are hard-wired that way. It’s innate. It’s an immutable trait. There are no variations or nuances. End of argument. Now I’m going to turn my back on you and put my headphones back on. Go away.
There are a couple of problems with the way people typically throw the word “introvert” around.
Continue reading Introversion and Agile
Why are your socks on the floor again?
I don’t know.
Don’t say “I don’t know!”
How many times have I told you to turn off the light when you leave a room?
I don’t know.
Don’t say “I don’t know!”
Continue reading I don’t know
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.
Continue reading Is collaboration really so difficult?
Recently, I watched a webinar that demonstrates a work flow for asynchronous code reviews using a tool from JetBrains called Upsource. The webinar started me thinking about the constraints that might cause a team to resort to asynchronous code reviews in the first place. While the product appears to be well made and easy to use, I wonder whether it offers a workaround to deeper problems that teams might wish to consider solving outright.
Continue reading Team practices, code reviews, and lead time
The question was posed in a discussion on LinkedIn. It received the following response:
Is the question "how does collaboration begin" or "how do specialists become generalists"? I assume the latter.
Um, well, that wasn’t the question. What’s the value in assuming a different question, because you’d prefer to answer the other question? After a number of comments extolling the virtues of the generalizing specialist, a person showed genuine interest in moving himself and his team in that direction. He want to get started. That’s a good thing.
Instead of helping him get started, however, people just reiterated the end state. Just do. Just be. Just blah blah blah. There’s a certain word in the question. It’s a little word; nothing ostentatious. But I think it’s kind of an important word. The word is begin. Continue reading How does collaboration begin?
The following passage from a generally good article by Jon Evans struck a chord with me:
Open-plan offices, in particular, seem an impressively terrible idea. "Open plan layouts create massive distraction, damaging productivity," according to a recent analysis by the U.K.’s Channel 4. See also the related Hacker News commentary, which includes gems like "Most modern office layouts seem to be designed to screw with people’s fight or flight instincts all day," and "I’m a quiet type, and I often need time alone to think and write code and documentation. The ‘rah rah’ social types railroaded us…I am becoming bitter and resentful."
Continue reading What does a collaborative team work space look like?