 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Agility: Definitions, Principles, and Practices for Today
By Susan Mitchell
Agility is a word we hear a lot these days, but there are a variety of methods to implement it within the Java Community Process (JCP) program. Most people grasp the basic idea of being quick, but there is much more involved than sheer speed of development or time to market. There are additional meanings, such as the quality of being mentally alert, skill at changing direction, and the ability to maintain control even during times of stress. Part of the problem with grasping the concept of agility is that its application may depend on personalities and circumstances. In other words, one Spec Lead may find that the practice of delegation streamlines the development process, while another may discover that depending on individuals makes the process more brittle. We turned to some of the JCP Spec Leads who are performing in a noticeably agile fashion. Kudos to them! Other Spec Leads would do well to learn from their solutions and mistakes, as detailed in the following case studies:
It takes nerve to approach a problem backwards from the way others are doing it. Ronald Toegl has demonstrated such nerve in his capacity as Spec Lead for JSR 321, Trusted Computing API for Java, while employed by IAIK of Graz University of Technology. Most Spec Leads follow the "classical specify-first, implement-later approach," but he is leading his Expert Group to implement first and specify later, all for the sake of operating with as much as agility as possible. "To us, agility provides an efficient use of resources, short feedback cycles, and a chance to consider different approaches while still moving forward. It also allows us to take small, easy-to-reach steps," Ronald says. Follow Sequence That Works He encourages all Spec Leads to adopt this counter-cultural approach, saying, "Do not start with writing text, but work with Java code from the beginning. It's the perfect medium to develop an application programming interface (API). With tools like Eclipse you can easily refactor drafts into high quality APIs, and with JavaDoc you can automatically derive specification documents from it." One benefit this approach has for the team is that it builds more joy into the process. "For most of us in the Java community, it's more fun to write code than specification documents. So if you derive the specs from the code, the overall process becomes more creative, agile and enjoyable!" says Ronald. It stands to reason that programmers are going to work harder and faster when they do what they love. Start With Minimal Prototype The process Ronald is using is not any more complicated than the typical way of going about things. After agreeing on the basic flavor of the API, the JSR 321 Expert Group developed a minimal prototype to learn more about the approach and its implementability. Ronald says, "When we were satisfied with the behavior of the prototype, it was easy to extract Java interface definitions from it. After slight modifications we were able to release this as an Early Draft." Add Implementations and Test Cases The Expert Group is currently involved in the next iterative round, in which the interfaces are implemented. In this phase, they also create test cases as they implement the API, or sometimes create actual tests before making the implementation. Through these steps, the group often discovers improvements that are then inserted into the API definition. According to Ronald, operating in this fashion allows the group to make headway with the API design, implementation, and test kit all at the same time. Rely on Public Repository Since the group operates a completely public repository, Ronald has found it somewhat challenging to keep the quality of contributions high. He knows that people have elevated expectations for material published through the JCP program, so he feels it is important to not commit code that is of mediocre quality to the repository. His solution has been to use local branches and commit to the public repository only cleanly coded and well-considered milestones that satisfy the Expert Group. Despite the challenge with the public repository, Ronald considers it an essential tool for any agile design process. He says, "If we had not had one at java.net,see https://jsr321.dev.java.net/we would have created one on our own, but we did not want to waste resources on system administration." Ignite and Maintain Momentum Agility relates to speed-to-market, but it also has to do with maintaining a steady work momentum or restarting an effort that has slowed down. Ronald has noticed that people are more easily drawn into discussions that are already lively. To jump-start such a discussion, he finds it helpful to begin one-on-one and then invite the group to join in. Moreover, once decisions are made, the Expert Group incorporates feedback into the API as quickly and completely as possible. Identify Essential Tool Set There are a lot of great tools out there, but sometimes they can steal focus in terms of acquisition, learning curve, use, and maintenance. Therefore, Ronald's group restricts their media to a fairly small set: Mailing List, Skype/Phone, Wiki, Subversion Repository, and personal Meetings. Ronald is also grateful for the services of Doodle. Like most Expert Groups, the participants in JSR 321 are scattered all over the globe and represent a variety of time zones. Identifying a time and date for conference calls would be a much more frustrating process if Ronald didn't use the polling mechanism at doodle.ch to identify appropriate time slots. In representing the university, Ronald does not face direct market pressure to finish the specification. Having an agile process remains important, nevertheless, because the targeted hardware platform specification -- the Trusted Platform Module -- could change if development takes too long.
Jack be nimble This Mother Goose nursery rhyme may seem silly and cute, but sometimes it seems that Spec Leads are called to do exactly that -- accomplish a difficult, risky task with speed, balance, and poise. Agility is not overtly taught as a technical skill, but having that quality can improve the entire process of proposing, developing, and implementing a Java Specification Request (JSR) as a timely, robust standard that suits the community. Ed Burns, a featured Star Spec Lead for 2009, is a senior staff engineer at Sun Microsystems. His primary task at Sun is to serve as a Spec Lead. He is co-Spec Lead of the three successive versions of Java ServerFaces (JSF) developed through JSRs 127, 252, and 314. Over the years, Ed has drawn several conclusions about how agility can play out in the context of the JCP program. Agility is Motivation Even with dedicated leadership to follow and a stimulating technology challenge to sink their teeth into, contributors within the JCP program tend to come and go. That problem is not specific to the JCP community, but it's the nature of virtually all volunteer-based projects. Ed has noticed that those who have contributed on his JSRs were less likely to vanish when they were paid to be there. It helps when the problem to be solved is interesting and attractive to those for whom the joy of technology development is its own reward. However, Ed feels it's a good idea to seed an Expert Group with a percentage of JCP members who are corporate stake-holders with an actual profit motive for being involved. "The more of those types you have on your JSR, the less likely you'll have people flake out. Corporate plans are often less capricious than individual plans," says Ed. A Spec Lead can also consider this notion of reward and dependability when deciding on whom to delegate key project components. Ed makes sure contributors are rewarded by helping them realize how they can fit their contributions around the next thing they need to advance in their career growth plans. On the academic side of things, a student whose research project is tied to the JSR will also have a vested interest in persisting and making significant contributions. Agility is Action Ed considers iterative development to be an Expert Group's most "totally vital" agile practice. He believes that "you have to build prototypes as you go along to test out the concepts." In fact, Ed's group got to the point where the prototype was the proposal. "By having the prototypes grow up with the spec, we achieved an important level of agility," he says. While many people take a Hellenistic approach of studying the details before taking a step (Read the manual first!), Ed follows the Hebraic method of learning by doing (Turn the gizmo on and start playing first!). He advises Spec Leads not to spend much time on up-front design. "It's much more useful to discuss it a little bit first, but to get some code running as soon as possible," he says. Ed favors having everyone involved in the rapid building process early on, but prefers a collaborative multi-team approach once things begin to coalesce. He says, "It's helpful to have the Reference Implementation (RI) start out being owned by the spec team. When it matures, collaborate on the implementation with the implementation team, but retain the ability for the spec team to enhance and modify the implementation as fluidly as they want." Agility is Delegation Spec Leads find ways to speed up when they can. Delegation is one such practice that agile Spec Leads like Ed hold dear. Until staffing constraints were imposed by Sun, program managers were available to help the company's Spec Leads handle all the non-technical handling of the JSR, organizing the workload in order to be able to post Final Release materials promptly after Final Approval Ballot, for instance. Ed deeply appreciated the program manager's help, and he says, "I would delegate as much of that sort of thing as possible." Another example of essential delegation came in the form of a contest Ed ran. Entrants to the contest had to write an XSLT style sheet that would format the XML exported issues from the java.net bug database so they could be printed. The formatting made each issue look like an XP story card, and at one point Ed laid out all 200 or so issues on his living room floor just so he could see them all in one view. The winner of the contest received a free copy of Ed's book, Secrets of the Rock Star Programmers. This kind of delegation both exemplifies and enables agility. Agility is Mentoring Agile Spec Leads don't mind slowing down when they see a benefit in doing so. It may seem counter-intuitive in terms of agility, but Ed believes very strongly that he needs to bring others along his path. This entails taking the time to explain and critique as well as offer opportunities to grow and shine. Such a philosophy is formalized in Sun's SEED program, in which Ed is a mentor. Instead of accepting all of the speaking and interviewing invitations that come his way, he tries to pass the opportunity to others on his team. Such mentoring can add complexity and slow things down. Agility is not always about speed, however. What Ed is building through his interactions is a kind of robust resilience that's not always cultivated by a perceptibly strong leader. However, interacting in these ways can help ensure a continuation of the message and the work if the Spec Lead needs to bow out unexpectedly. Agility is Exposure Ed's employee status with Sun Microsystems gives him a level of freedom and permission to write, travel, and speak that not all Spec Leads enjoy. However, if other Spec Leads understood the benefits of accepting at least occasional invitations, they might find the wherewithal to make the bonus effort. There is simply no adequate substitute for direct communication when it comes to addressing market demands, hearing the community's wishes for features, and keeping everyone aware of the JSR's schedule and availability. For example, Ed blogs often about new features in the specification, and he actively pursues comments. He also attends conferences and user group meetings, where he speaks about new features and collects feedback. After taking some time to make sure that community-driven features have actually been addressed or implemented in the product, Ed demonstrates the link between the final product and the community feedback for all to see the effects of their suggestions, encouraging them to make more suggestions in the future. Agility is Coping with Pressure Agility can be affected by external pressures. Ed feels pressure in two directions. He says, "The open source community wants things faster, while the Java Licensee community wants things to move as slowly as they always do." In general, though, he feels fairly satisfied that "the JSR lifecycle moves nicely along with the product lifecycles of the major Licensees." Considering the important milestones and checkpoints along the way of JSR development, it's practically a given that all's well that's moving along well.
A sure-footed mountain goat, nimble gazelle, resilient nine-lived cat, flexible ferret, preying hawk -- these are some of the images that might come to mind when we think of agility. This latest industry buzzword has caught on because of its elegance in expressing a concept that is loaded with meaning. The animal metaphor is a fine visual comparison, but agility goes far beyond intuitive practices. For example, Spec Leads may find themselves in situations where, instead of acting, telling, and speeding, an interest in agility requires that they stop, listen, and slow down. Stop There are times when the work stops, if only for a moment, and there are times when you have to stop the work. The question is what should be happening during those down times. Ed Burns is a firm believer in the need for Spec Leads like himself to pause occasionally in order to engage the community. He practices what he preaches, particularly by getting involved in conferences. Although such events take time away from the project, they are important times of refreshment and reflection for both the Spec Lead and the community. It was at JavaOne 2005 that he first met Jason Carreira when they participated in the first-ever Web Framework Smackdown session. That meeting proved an important spark for JSR 303 when, a year later, Jason emailed Ed and two other Spec Leads out of the blue to outline an idea. He said, "I've been thinking about the possibility of submitting a JSR for validation. In talking with Hani [Suleiman] about it, he suggested that you three might be good people to discuss it with first, as you run JSRs which would touch on any work to standardize validation." With their encouragement, Jason soon proposed JSR 303, Bean Validation, and by July 2006, the JSR review ballot was unanimously approved by the Executive Committee for the Java Platform, Standard Edition/Enterprise Edition (SE/EE). By stopping to listen to an idea from the community, Ed contributed to the agility of the JCP program. Listen One of the most challenging things that can happen to a JSR effort is to revive it after it has gone dormant, that is, after it has stopped for too long. Work on JSR 303 came to a halt when Jason was unable to continue as Spec Lead. Eventually Emmanuel Bernard stepped in to get the project rolling again. After accepting ownership of the project, Emmanuel's first step was a quiet, private one: he went into listening mode as he read and analyzed the feedback already provided by the Expert Group. Out of those raw materials, he created the core of the specification. After making that basic piece available to the Expert Group, everyone had a common foundation to discuss and build upon. To keep the project energy high, the group addressed new features one by one, starting with the most important feature first, in terms of both the specification and the implementation. This sense of priority gives the most critical pieces more time to be vetted and polished. Moreover, it ensures they will be included in the final draft. Emmanuel notes, "If a problem arises at an early stage, we can go back to the drawing board. In the later stages, only minor enhancements are on the table, and we have made sure the spec can support them in future releases." Thus, the specification was built up slowly and with focused attention on each new area in turn, with an early concern for end strategies and future compatibility. Once the specification was in "a decent shape," Emmanuel invited the community at large to look at it and comment on it. Communicate Often As a diligent Spec Lead trying to keep up momentum, Emmanuel finds that one of his hardest problems to solve is how to monitor and handle contributors who stop delivering what they've promised, or who simply vanish. He says with empathy, "People are not unresponsive for the sake of it. They tend to be busy with many things besides the specification. And it's the same for most Spec Leads." To mitigate the problem, Emmanuel simply continues to communicate on progress and ask for feedback regardless of an individual's availability. He adds that focusing on specific features or topics during a given period of time helps eliminate the mental and email scramble, or "overhead," of context switching. Moreover, he doesn't just zero in on the individual, but also requests feedback from the community at large. And when a problem arises, for specific help he goes back to the Expert Group and whoever else has a stake in the particular issue at hand. Communicate Openly Emmanuel finds that a JSR effort can be pursued in a more agile manner when the operation is conducted in the open. With that aim in mind, he did at least four things to keep the project flexible in terms of schedule, market demands, community wishes for features, and so on. First, all significant changes for JSR 303 were made in the open through a mailing list. He says, "Halfway through the project, I opened up communication to the community as a whole, both to increase the number of eyeballs and also to circumvent a decrease of involvement in the Expert Group." Second, feedback was gathered through an active user-focused forum. On the website, numerous participants ask and answer questions (How to integrate JSR 303 with PresentationModel pattern? How to do a validation with a condition? Should we have more built-in annotations?), and they comment on topics (Chaining Constants, BeanValidation Configure, Problems Trying RI). The forum has over one hundred threads, so far. Third, Emmanuel blogged regularly on the progress of the specification at the In Relation To website, which was open to public view. In his blog, he described the project, made announcements, offered sneak peaks, solicited feedback, and pointed to downloadable documents. Fourth, the Reference Implementation (RI) and the Technology Compatibility Kit (TCK) were developed as open source under the Hibernate community umbrella. Taken altogether, Emmanuel is confident that this strategy "keeps everyone in the know and allows for early problem detection and feedback." Slow The industry likes to see things move from proposal to marketplace with lightning speed, and a Spec Lead can feel the pressure to move things along. Having approached the JSR when work had already halted, Emmanuel's attitude became, "It's done when it's done." That's not to say that he had no concerns about the schedule, but he weighed some factors more heavily than others' wishes. In fact, Emmanuel decided to slow down the process in order to align with the Java EE timetable. This would ensure proper synchronization with JSRs such as Java Persistence 2.0 and JavaServer Faces 2.0 and prevent incompatibility. Because rushing can be a recipe for future disaster, slow going can actually be a sign of agility. In general, Emmanuel has a simple view of how to operate a JSR in an agile manner, which boils down to this: "Work in the open. Release early and often, outside of JCP boundaries if necessary."
Values like agility have a way of shaping behaviors and outcomes even when they are not consciously acknowledged. In fact, probably most Spec Leads do not focus on agility as a conscious, deliberate working mode. However, Spec Leads like Erkki Rysa and Kay Glahn can end up with agile processes when they operate with forethought and make choices that allow them to be resilient and responsive. Until late in 2009, Erkki and Kay were both co-Maintenance Leads of JSR 248, Mobile Service Architecture (MSA), and co-Spec Leads of JSR 249, MSA 2. Erkki continues as Maintenance Lead and Spec Lead while serving as a technology manager for Nokia Corporation. Kay previously represented Vodafone Group R&D in co-leading JSRs 248 and 249, but he has since moved on from that role. When Kay was still a Spec Lead, he and Erkki were asked about their agility practices. In the interview, Kay said, “Although we have never explicitly set agility to be a guiding principle in our work, we have always been striving to work in a flexible manner and respond to new input and changes in the business environment effectively.” Employ Helpful Tools JSRs often lose momentum in the middle stages of development, but JSR 249 floundered in the early stages because there were fundamental differences of opinion regarding the JSR?s scope and content. After Kay and Erkki took steps to refocus the JSR, the work moved along more smoothly, and the use of an issue tracking database helped, too. The database is used to store submissions, related discussions, and Expert Group decisions. Erkki feels that having this kind of database is crucial as it allows people to work on individual issues in parallel and to store the results in a safe place. Moreover, it significantly reduces the need to communicate by email. The issue tracking database is important, but to really keep up the momentum Kay and Erkki relied on regular weekly conference calls, with face-to-face meetings every two or three months. During the conferences, the Expert Group would go through the issues in the database and make decisions based on contributions made by the group members since the previous conference call. Technology is in constant flux, and agile Spec Leads keep an eye out for what can benefit their work, even if it requires in investment of some sort to start using it. For example, after they started the JSR 249 effort, Kay and Erkki added some mechanisms that improved communication with all of the engaged parties and the community. Communicate with a Plan Clear, smooth, frequent communication both inside and outside of the Expert Group is one of the hallmarks of JSRs that are produced with agility. Kay and Erkki welcomed input during all phases of the JSR development, and they valued their avenues of communication. ?It is never the wrong time or too late to provide input, which we always take into consideration. If something important does not make it into our final release, we plan to include the late additions in maintenance releases,? said Kay. Spec Leads aren?t in control of all aspects of communication, of course, and sometimes they have to figure out what to do when communication gets stopped up. In a changing business environment it is not uncommon for companies or individuals to change their focus and then stop delivering on their earlier promises. Erkki noted, ?We always try to have a backup plan in case something is not delivered, and we regularly check the progress of our contributors and try to find other alternatives when necessary.? Schedule Some Wiggle Room Ambitious Spec Leads may want to work as hard and fast as possible, but Kay and Erkki kept a looser hold on their schedule. Their view was that the JSR would succeed only if it were widely accepted and deployed. ?It is important to get the specification out in a timely manner, but we have been willing to change the schedule to make the specification a better fit with changing market and key stakeholder demands,? said Kay. Spec Leads always face a certain amount of pressure from those who want the final spec yesterday. Erkki understands their urgency, but he knows that unless it is an excellent standard, it won?t be used at all. He put it this way: ?For sure the industry has an interest in getting the specification done quickly and deployed on devices as soon as possible, but on the other hand there is also a strong interest from most industry players to create a standard that fulfills the requirements of most players in the industry, including developers.? Agility sometimes requires slowing down in order to ensure that the product truly satisfies. “In the end, having better acceptance in the industry is worth that extra time that has been spent on aligning everybody’s requirements as well as possible,” said Erkki. “What matters is entering the market at the right time with a specification that gets as much support in the industry as possible.”
|
