Developers without borders: Open community-based development brings greater transparency
Commentary - In a traditional business ecosystem, a company works with collaborators, while working for consumers and working against competitors. Collaborators are often partners, while consumers are the customers or clients, and competitors are just plain old rivals for finite market share. This zero-sum model of business interaction is somewhat dated. As Robert Wright observed in his book, Nonzero: The Logic of Human Destiny, “winning in business is not a zero-sum game. In sports, when one team wins, the other loses. In business, when a company wins, there are usually collateral winners, too.”
In a business community built on collaboration, competitors can also be collaborators, engaging in co-opetition in which they simultaneously partner with a company on one front while competing against it on another. Likewise, consumers become collaborators, working closely with a company to help it develop better solutions more rapidly. Companies that are willing to engage in this kind of collaboration can produce the right products faster and with less cost. Software development teams, whether they have internal consumers or external consumers, can benefit from tightening the feedback loop by engaging more closely their consumers.
Rhythm
The first key step to engaging any audience is to establish a rhythm of regularity. People are naturally drawn to the predictability of regular cycles. When a church congregation reads liturgy everyone immediately falls into the same rhythm of reading. This is known as entrainment. Just as jazz musicians improvise within the structure of a repeating, iterative form, carried along by a tempo, pulse, and infectious grooves, software developers can align efforts within a team by employing an iterative schedule, a tempo set by the business, a pulse set by project leaders and interlocking grooves set by team leaders.
The rhythm in a project schedule comes from the iterative methods of agile software development. A project is divided into iterations or sprints that usually last from one to four weeks. Iterations allow developers to deliver a new feature or fix a defect before the end of a specific iteration by planning activities such as design, coding, testing, reviewing, and so forth. The most important part of an iterative approach is that a team must produce demonstrable software at the conclusion of each iteration. These early releases of software must be consumable and made available widely. The most agile projects provide not only stable builds monthly or every few weeks, but less stable weekly and even nightly builds.
Observation
Colonel John Boyd, a maverick U.S. Air Force fighter pilot, was one of the first instructors at the Fighter Weapons School where he wrote the curriculum on dogfight tactics. Boyd understood agility in mission-critical domains decades before businesses pursued the concept. Today, his ideas are lauded by leading management thinkers such as Tom Peters.
In Boyd’s Observe-Orient-Decision-Act (OODA) cycle of execution, the initial and most important step is observing the actions of others in order to acquire all data relevant to decision making. While observing is the visual action in many disciplines, musicians are focused on listening while software developers rely primarily on tools to acquire the data they need. These tools must provide developers with awareness of what their team doing and how it is progressing towards its goals.
This is especially important for teams that are not geographically co-located. To avoid costly conflicts and collisions tools must help developers contribute simultaneously and integrate their collective contributions. Finally, the tools must help developers receive feedback from consumers in a timely manner and interact with them directly. Tools such as IBM’s Rational Team Concert provide these kinds of facilities with dashboards and reports to monitor progress, work items and plans to track work, and source control management and builds to manage and integrate code contributions.
Transparency
Developers and teams executing in OODA loops can observe intently but such observation is limited by the degree to which those being observed are transparent with their actions. Transparency can tighten the feedback loop by reducing the time required for others to observe, understand and interpret actions. Improving the speed with which feedback is identified, understood, and fed back into a system helps developers identify problems earlier which reduces overall cycle times and costs. Furthermore, transparency has the potential to grow communities by attracting new people. People appreciate honesty, openness, and authenticity. They are naturally curious to know what goes on behind the scenes and transparency can give people comfort by alleviating any fears or concerns they might have about the unknown.
Software development teams can gain more transparency with tools like IBM’s jazz.net site. The approach is inspired by practices of open source development but uses commercial licensing. All the software development is done on a public Website where anyone can see the team’s plans, the work committed to each release and how the team is progressing. They can engage in discussions with the team through mailing lists and forums, report bugs and submit requests for feature enhancements, and read minutes of the team’s meetings. Most significantly, they can download regular builds of software. Customers can see everything as it happens, giving them the opportunity to provide input at the most appropriate times and the confidence to base their plans on a known set of features to be delivered on a known date. If the team is doing well, they may receive positive feedback. On the other hand, if they are doing badly, they may receive negative feedback that everyone else can see and comment on. This might seem like a bad thing, but by taking careful note of such negative feedback, teams can improve their processes and products in a timely and continuous manner while providing greater value to their customers.
biography
Adrian Cho is a jazz musician and bandleader, software development leader at IBM, and the author of The Jazz Process. He speaks and writes about collaboration, innovation and agility at jazzprocess.com.