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.
The word appears in the following context:
I think I still have my original question: given a new team of specialists, how does the collaboration begin?
What he was asking for was help in locating the start of the path to collaboration, hidden beneath the underbrush of old assumptions and habits; and then, maybe, a supporting arm to hold onto for the first few steps, until he found his footing on the unfamiliar ground.
But that isn’t what he got. He still had his original question. That’s because no one had answered it, up to that point in the discussion. All they had said up to that point was collaboration blah blah generalist blah blah blah.
Maybe what’s needed here is another metaphor, to go along with all the other metaphors we use to describe our work. Couldn’t hurt, right?
Recently my family and I took a class together. It was an NRA-certified basic pistol class. Most of the emphasis was on handling firearms safely. One of the things you might do with your firearm is to hand it to someone else. As you might imagine from many years of watching movies and television, there are many different ways to hand a firearm to someone else. You could, for example, drop it on the floor and kick it across the room, loaded and cocked. This is analogous to the way software development specialists hand off work between functional silos; you know, the old "throw it over the wall" thing.
Now, it might surprise you to learn that the NRA doesn’t particularly recommend this method of handing off firearms, in most cases. It turns out that a number of things could potentially go awry. Several of those things can result in unhappy endings. Strangely enough, handing off software development artifacts in this manner also invites unhappy endings. Hence the value of collaboration.
We’re certainly not experts after one training class and an hour at the gun range, but here’s what we were taught about handing off a firearm: First, you clear it, then you hand it off. "Clear" means you check the magazine, action, and chamber to make sure there’s no ammunition in the gun. Then you ask someone else to look in the magazine, action, and chamber to confirm there’s no ammunition in the gun. You’re still holding the gun at that point. Making sure the gun is pointed in a safe direction at all times, you can then hand it to someone else. The procedure for that is to look at the person while he/she looks at the firearm. You present it to him/her, pointing it in a safe direction at all times, stock first. You don’t let go of it until he/she verbally confirms that he/she has a firm grip on it. You look at the firearm to see for yourself that it appears as if he/she does, indeed, have a firm grip on it. Then you can let go.
It’s just slightly different from dropping the gun on the floor and kicking across the room. In particular, there’s a fair amount of looking, listening, double-checking, confirming, and generally paying attention.
So, what’s the connection? On a software development team of specialists, a typical work flow is for an analyst to hand off an artifact to a programmer, who later hands off an artifact to a tester. These various interim artifacts eventually become a piece of working software. Traditionally, the hand-off procedure is to "throw it over the wall" to the next functional silo in line. It’s exactly the same as dropping a loaded gun on the floor and kicking it across the room, spinning in all sorts of unsafe directions and colliding unsafely with all sorts of unsafe obstacles.
If your current state is that your team comprises a group of siloed specialists, and you’d like to know how to begin a collaborative style of work, then learning how to do a safe hand-off might be a good first step. You’re certainly not going to leap directly and immediately to being a team of generalists who can seamlessly do any work the project calls for.
To begin to collaborate, try to hand off interim development artifacts in the same way as you would hand off a firearm. Say you’re a programmer and you think you’ve gotten a piece of work close enough to "done" that a tester can work with it. Instead of logging into some project management tool and marking the task as "ready for testing," invite a tester to sit down with you. Show and explain what you’ve done. If you’re the tester in that scenario, ask questions. Be as certain as you can that the two of you have a consistent understanding of what’s going on. Stay together while the tester begins to do his/her work. Be sure things are proceeding smoothly before you withdraw and pick up the next programming task.
Use the same sort of care with all the hand-offs in your workflow. You’ll find that people begin to get a pretty good sense of one another’s work…what others are looking for, how they approach things, how they conceive of the development process, etc. You’ll be well along the path toward the generalizing specialist model before you even realize it.
That’s how collaboration begins.
How do you avoid poor handoffs from analysts developers? At least in my environment, the analysts spend ~ 100% of their time travelling to customer sites, gathering requirements, and going back to their hotel rooms to compose requirements documents. The developers stay back at the lab and try to convert these documents into software (guessware). Extremely poor communications bandwidth and latency.
There’s no travel budget for developers to shadow the analysts;even if there were, they cannot develop software efficiently from hotel rooms (one small laptop screen plus glacially slow VPN access, instead of multiple workstation screens connected directly to high speed LAN). Plus, it would just shift the unsafe handoff to developers testers (who really can’t come along, they need physical access to the test servers in the lab).
Once you have the goal in mind to have smoother handoffs, you’ll start to look for ways to mitigate the challenges inherent in your environment. The first thing that comes to mind for me is to try and mitigate the issues caused by geographical separation and latency. Some things to consider:
Schedule collaboration time between analysts and programmers and use remote collaboration tools that minimize the issues to the extent possible. Audio + vidio + keyboard sharing would be best. Audio + video would be next best…etc. Your company may have a license for commercial facilities. Otherwise, there are some free facilities that work fairly well most of the time, like Google Hangout and Skype.
Short of that, you can have analysts and programmers collaborate using an instant messaging facility, possibly augmented by a phone call.
Anything you can do to work around the issues caused by physical separation would be helpful. Don’t expect perfection, just do the best you can.
I’d be interested to learn how your team addresses the problem. Others can probably benefit from the solutions you discover.
Malapine, something else occurred to me on further reflection. Rather than just improving the mechanics of communication between analysts and programmers, it might be advisable to include testers in the collaboration session with the remote analysts.
Analysts tend to try and express requirements in concise human language. They strive to express a set of requirements in one or two paragraphs in language that is crafted such that it can be interpreted broadly enough to cover all necessary cases, if one wishes to spend the time to ponder what cases might be hiding in the prose.
It’s always been a challenge for programmers to parse this sort of material into actionable pieces. Testers learn the skill of expressing system behaviors in terms of concrete examples. Such examples are far easier for programmers to consume than broadly-worded prose. Putting the three mindsets and skillsets together can result in specs that everyone understands in the same way.
This sort of three-way collaboration has been called “the three amigos.” Here are some references:
http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=17232
http://www.scrumalliance.org/community/articles/2013/2013-april/introducing-the-three-amigos
Based on your comment, you have a couple of additional challenges that require attention. The obvious one is the geographical separation of the three parties. You’ll have to find ways to mitigate that issue, although it will continue to create challenges even in the best case.
Another is that when the relevant parties cannot easily talk to each other on the spur of the moment, any misunderstanding of the written requirements is likely to lead to larger and larger problems as time passes, and as people proceed on the basis of assumptions or on their own interpretation of the material.
To minimize the impact of this, it’s often helpful to express requirements in some standardized, clear-cut way. The Given-When-Then format has proven to be useful as a vehicle for discussion among stakeholders, as a way to express desired behavior (requirements), and as a way to verify desired behavior (checking or “testing”). A common syntax for this format, known as Gherkin, can be parsed and executed by tools such as Cucumber. Another option is FitNesse, which operates on examples expressed in a tabular format. These formats and tools can provide more reliable ways to communicate requirements than conventional, non-executable and non-standard human language statements.
Maybe a combination of these approaches would be useful in your situation.
I like the metaphor 🙂 and I like the “safe hand-off” as a first step. This will indeed encourage a collaborative spirit.
I don’t buy the idea though that all members of an agile team (or any software development team) need to be generalists. They don’t. We want specialists—we want people highly skilled in particular areas to work together with people highly skilled in other areas. There are many ways of supporting a team member that go beyond doing the work that the other is better skilled at. Testing is always one of those ways, removing impediments is another, as is working with the analyst/PO to look ahead at the next set of work, ensuring requests are well-formed. There is so much more to writing software than coding. And if we don’t know what to do, we ask.
Team members need to learn to step up to do what has to be done, however mundane it may seem. Much of this requires the laying aside of ego—or getting beyond fear (which perhaps is the same thing). I reckon that’s the hardest part.
Hi Tobias,
Thanks for the feedback. I agree that everyone on a team doesn’t need to be a generalist. I would say most people don’t even want to be generalists. They chose their specialty because they enjoy it, and that’s how they wish to spend most of their working time. When it comes to generalizing specialists and stepping up to do what is needed at the moment, I often think of the Pareto Principle, a.k.a the “80/20 rule” or the “rule of the vital few.” Most of the activities in a given area will not demand the deep skills of a specialist; they can be handled by someone with a broad general skill set and a willingness to learn. For the 20% of activities that really does demand the skills of a specialist, it’s good to have them on board.
[…] How does collaboration begin? Written by: Dave Nicolette […]