Part II, Managing an Expert Group
Most projects are pretty easy to conceive, harder to sustain, and demand herculean efforts to wrap up. In fact, of the 300+ Java Specification Requests (JSRs) reviewed by the Executive Committee (EC) since 1998, about one-sixth of them have been “withdrawn” from the Java Community Process (JCP) program for failure to thrive. A “general absence of interest in the community” is often the reason cited for the withdrawal. In other words, the Spec Lead was unable to summon a working Expert Group (EG) or spark a productive discussion among the Experts.
What can be done to prevent the likelihood that a JSR will die before birth? Star Spec Leads Volker Bauche, Ed Burns, Danny Coward, and David Nuescheler have successfully launched, managed, and achieved closure on numerous JSRs. They accomplished this by keeping a firm hand when guiding discussions and dealing with passive participants and difficult personalities.
One might think that the size of an Expert Group is critically important to keeping it going, where small groups would be nimble and large groups cumbersome. However, Volker Bauche, a senior software technologist at BenQ Corporation, finds that a Spec Lead’s effort may increase as the Expert Group gets bigger, but his methods for handling small and large groups are “surprisingly similar.” Volker started by leading a simple JSR, but each subsequent JSR was increasingly “difficult and complicated.” He likens the experience to starting out on a quiet lane during the first driving school lesson, and navigating more challenging roads until ending up on something like the Autobahn.
Volker co-led, with Jari Länsiö from Nokia, JSR 195, Information Module Profile, and JSR 228, Information Module Profile – Next Generation. These JSRs focused on the important but special-interest area of wireless modules, so their smallish Expert Groups of eight and seven members appropriately reflected community interest. On the other hand, Volker is also co-leading JSR 281, IMS Services API, along with an engineer from BenQ and two others from Ericsson AB. Because of worldwide interest in this complex subject, the Expert Group for JSR 281 consisted of more than 30 Experts representing 27 companies, making it the second largest in the Java Micro Edition (Java ME) area.
There are several directions a Spec Lead can take in figuring out which tools are best suited for leading an Expert Group. Danny and Volker both chose to rely on the simplest tools.
Volker says, “I know from when I was a member in other EGs that many Spec Leads use their own tools, working spaces, and the like in order to drive their JSR. I never did; I always found the infrastructure provided by the Program Management Office (PMO) very useful and sufficient. I made good use of the official mailing lists -- for members and for observers -- for communication, and I used the private EG site for delivery of working drafts, code samples, feature lists and whatever was under discussion in the EG at the time. For teleconferences I used the service provided by my company.”
Danny Coward is the Java Standard Edition (Java SE) platform lead at Sun Microsystems, and he currently serves as Sun’s primary representative on the SE/EE (Enterprise Edition) EC. He agrees that the essential tools for driving an Expert Group were a mailing list and a website “that I could edit and post things to. Writing summaries and posting all the issues to a list were the two best management tools for me.” Danny was the Spec Lead for JSR 53, Java Servlet 2.3 and JavaServer Pages 1.2 Specifications; JSR 124, Java EE Client Provisioning Specification; and JSR 154, Java Servlet 2.4 Specification.
Ed Burns, a senior staff engineer at Sun Microsystems, is the co-Spec Lead for JSR 127, Java Server Faces, and JSR 252, Java Server Faces 1.2. He also appreciates the standard bundle of services, saying, “I find the mailing list archive provided by the JCP program to be incredibly valuable. To this day I occasionally refer to the JSR 127 EG emailing list archive to resolve a technical question. Having a high quality, professionally maintained, searchable archive is essential to this task.” Ed also found it “totally key” to use a web accessible issue tracker. He says, “Before we started using java.net, which provides such a tool, we set up our own instance of a web issue tracking tool for the EG to use.” Ed has recommended that the PMO provide each Expert Group with additional helpful tools, including a private issue tracker, wiki, and group chat room, and these are included in the upcoming jcp.org redesign.
Experience prompted David Nuescheler to reassess his use of tools. As chief technology officer at Day Software, he led JSR 170, Content Repository for Java Technology API, and its successor, JSR 283, Content Repository for Java Technology API Version 2.0. David says, “We learned a lot from our mistakes during JSR 170 when we had a slow centralized editing and issue-tracking process. For JSR 283, we now use the tools offered by java.net that seem more adequate for a distributed, collaborative -- more open source-like -- working style, which our Expert Group favors.”
Spec Leads own the task of igniting the technical conversation and fanning the sparks until a steady fire of ideas, features, and issues catches on. The first spark is the initial Java Specification Request, which is used to drum up support and recruit Experts and get approved by the EC. The second spark generally takes place at a kick-off meeting, which Volker feels strongly should be held in a face-to-face situation. He says, “The experts will have a much more vital ongoing discussion if they know each other personally, and even if you often have faces that are well-known in several related EGs, it is good to refresh the personal knowledge the experts have about each other.”
The third spark that raises the level of discussion to that of a healthy fire often occurs through email discussions that are typically initiated by the Spec Lead. After a given thread had elicited a great number of emails, Danny would summarize the arguments and list the options going forward, along with a summary of the pros and cons of each. For wider-ranging topics, Danny would arrange a face-to-face meeting to help people jump back into the discussions without having to read every single email.
Volker observes that Experts usually have a lot going on – other work projects, other Expert Groups they’re involved in and perhaps even leading. As a result, their discussion time is limited. He has found it best to email the Expert Group so that the period between a query and expected reply includes at least one weekend, “otherwise you probably won't receive much,” he says.
He has another way of adding fuel to the fire: “Sometimes I mix a provocative proposal into a list of discussion items, unless one of the EG members has already included one unintentionally.” This lets Volker know quickly if the Experts are actually reading the email. If they are on their toes, “the ‘provocative’ proposal will be immediately refused” and soon forgotten, but it will have served its purpose of waking people up and stoking a fire that consumes extraneous “Oh, and one more thing…” comments.
It’s also essential to build and maintain a good reputation among Experts by employing “impeccable email skills, the more concise the better,” says Ed Burns. “If people come to expect that they can read emails from you very quickly, you have more of a chance that people will read your proposals.” He uses a technique called the “omnibus email” to reduce the difficulty of tracking who said what over email and to what parts of a proposal their comments apply. He gathers all comments on the proposal and combines them into a single email, attributing each section to an author. This document is then stored in a version control system. For example:
The scoped namespace will be searchable via a widening scope mechanism.
Bob Johnson wrote:
BJ> I'm not sure we want to bake that into the spec. . . .
John Smallberries wrote:
JS> But Bob, did you consider what the user would do. . . .
Ed adds, “A logical extension of this idea would be to use a tool such as Google’s ‘Writely’ collaborative text editor for the task of developing discrete spec issues.”
Things seem to be getting easier as years go by and experienced participants get comfortable with group conversations over email. David’s current group email discussions “hardly need to be moderated or managed anymore. When consensus is reached on a topic through the mailing list or one of our face-to-face meetings, an author or editor adds a proposal to the specification and commits that to the centralized configuration management system, in our case, Concurrent Versioning System (CVS), as the basis for further refinement.”
Spec Leads weigh a number of factors, including travel budgets, in deciding how often face-to-face meetings with the Expert Group should occur. In addition to the face-to-face kick-off meeting, Volker believes a face-to-face meeting is beneficial for preparing the EDR proposal. He says, “You have to look into the eyes of your experts in order to get to know whether they are happy with the proposal or not.” Volker might have scheduled additional face-to-face meetings leading up to the Early Draft Review (EDR), depending on the number of Java classes a JSR encompasses and the level of controversy in the online discussions. In his view, another in-person meeting after the EDR might be necessary, depending on the results of the review itself.
Danny also considers the practical matter of whether everyone is available to meet together. Danny’s attempts to mix a face-to-face meeting with a teleconference didn’t work, “despite my best attempts to be inclusive.” He found that in-person meetings were “most productive in building issues lists rather than making decisions because it’s too easy in person for someone to disagree. They have to make more of an effort by email.”
David sets up two or three face-to-face meetings each year for two days each and has had adequate attendance. For JSR 283, about 25 actively contributing experts show up for each meeting, out of approximately 70 individuals who represent 38 member organizations. David says that before the meeting, “We establish a clear structured agenda and goals for the meetings and make sure that for every topic we want to discuss there is a draft proposal so we have something to base our discussions on. So far my experience has been very positive and we exceeded our expectations with the number of topics that we could get consensus on numerous times.”
The use of teleconference is up to the Spec Lead’s personal taste. Danny ultimately abandoned the teleconference option altogether, while some Spec Leads prefer regular teleconferences once or twice each month. David’s default is to have a weekly call for administration and status updates rather than technical discussions, which he feels should be recorded in writing. He cuts back to every other week if there is no obvious need for one, reasoning that it’s easier to drop the timeslot than to require a large group of people to squeeze an extra meeting into their schedules.
Volker uses teleconferences whenever an issue cannot be resolved through email. One day, Volker emailed two issues that he thought were similar in scope and expected to play out similarly. One issue was resolved the same day it was introduced: someone made a proposal, the others agreed, and that was the end of the matter. The other issue started a never-ending email thread. “As a Spec Lead, you have to observe those threads carefully, and if you find out that the discussion starts to move in circles, you should set up a call,” says Volker. He also uses a teleconference when he wants an informal decision about a certain issue. He calls for formal votes through email, however, because “people change their mind sometimes,” so it can be important to have written documentation on how participants voted.
Sometimes the conversational fire can leap into out-of-control flames, as opinions heat up and words become more personal than technical. Danny had to deal with some difficult personalities at various times. In those situations, he didn’t exercise the moderator’s right to shut down the email discussion; instead, he asked the “critical” person to write up a proposal. Sometimes he would persist with the professional mode of communication he had instituted, simply allowing the discussion to exhaust itself and then summarizing all the arguments. “In one case, I went to meet with one of my 'difficult' Experts in person. It got much easier after that,” Danny says.
To keep meetings running smoothly, Ed Burns wished he could hire a professional meeting coordinator, but there was no budget for that. Liz Kiener of the JCP PMO offered to mediate, and the group “used her to good effect,” he says.
Experts in David’s group know each other pretty well by now, having worked together on two specifications, so any personality issues have smoothed out over time. Still, David suggests that people who don't get along on the mailing list should talk to each other over the phone or even face-to-face if possible. He says, “I think the most challenging issues are political or strategic differences between two large stakeholders in the Expert Group, that are not motivated by technical arguments but by large company politics.”
Because Experts often have other obligations, they may drop out of the conversation from time to time. It?s helpful when an Expert announces he or she will continue to monitor the conversation but must pause their active participation for a time. But if they simply quit communicating, Danny says it?s a good idea to find out what?s going on with them. ?Lurkers sometimes pop up at the end right before a draft and want a large number of changes. You can't really say no at that point? because changes are still possible. Sometimes Danny smokes out the lurkers by calling for a poll, and requiring everyone to respond by taking a position.
David is more comfortable with ignoring lurkers who are passive. ?The concept of a lazy consensus where only objection-votes need to be cast in a specified time frame, has worked in our favor a number of times,? he says.
In JSRs such as Volker?s JSR 281, where the specification might interfere with other efforts, Volker invites the Spec Leads of those efforts to become Experts in his group. He is quite happy for them to lurk until they ?cry if we drift into their area.?
Most Spec Leads enjoy being in control. Although some may choose to delegate tasks to the Experts or share the limelight with one or more co-Spec Leads, others prefer the lone range approach. Danny says, ?I like to hold the pen? in order to structure the discussion in a way that is most fruitful for all concerned.
On the other hand, David is quite happy delegating to volunteers. His process seems to work well as an informal ?meritocracy or do-ocracy? in that whoever shares the load of producing the specification can count on their input being taken seriously; he or she will have earned the respect of the Experts.
Volker kept his own counsel when it came to the organizational aspects of tracking members and observers, maintaining protocols, setting up meetings, and so forth. For the JSR content, however, he happily distributed action items, delegated responsibilities, and worked with subgroups. He cautions that ?As a Spec Lead, you always have to keep in mind that you are responsible for the JSR as a whole, and you must always trigger, and ask questions, and be a pain in the neck, a kind pain though.?
JSRs go through predictable stages and face many typical obstacles. Every so often, something unexpectedly unique and potentially major may catch a Spec Lead off guard. When Siemens Mobile was acquired by BenQ shortly after Volker started JSR 281, there were an overwhelming number of complications, in that BenQ hadn?t signed a Java Specification Participation Agreement (JSPA). For example, the Reference Implementation (RI) and Technology Compatibility Kit (TCK) projects had to be handed off from one end of the globe to the other. Despite the fact that Ericsson was an extremely cooperative co-Spec Lead, the key for Volker was to keep his head and address each issue as it became known. Now that the German part of BenQ has been declared insolvent, the story continues to unfold as Volker does his best to keep the JSR running smoothly.
Throughout all of the stages, Volker has discovered, ?The PMO is the Spec Lead's best friend. Trust them and communicate with them, for they will always be helpful.?
Back to part 1...
Go to part 3...
|
