Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Tools

Green Threads


Green Threads: A Brief History

A few years ago, IBM's Software Group came across the idea of "red threads" in a company that it had acquired. Basically, a red thread is a trail of blood—a customer path through a product that is commonly traveled, and painfully broken, requiring many workarounds and support interventions. These red threads would be documented as a result of customer engagements, and fed into the development cycle to be considered for future improvements. On its own, this concept is not revolutionary. Most companies have some way of rolling customer pain-point information into development cycles. But it formed the basis of a much more ambitious project: We imagined new, refocused threads that would continue to document the real customer workflow across products, but which would elaborate on how things should work instead of documenting the problems with the current product set. Instead of being reactive and perpetually lagging behind the product cycle, they would become key drivers of new development and track the evolving demands of customers. In light of their rebirth and positive new message, they were given a makeover and a snappy new name—"green threads."

Green Threads: Anatomy of a Project

Green threads are tools for improving end-to-end product quality by using customer scenarios to clarify product priorities and drive new legitimate forums for cross-product discussion. At their core are real-world, end-to-end paths through multiple products and multiple brands, phrased in terms of the specific goal customers are trying to accomplish or situations they are trying to handle. It is essential that the green threads be driven by actual customer reality because the interproduct space is one with which few people in a development organization have experience. Likewise, it must follow the customer scenario from end to end because real-world workflows don't tend to match product boundaries. The temptation to duck the unpleasant complications at handover points in a scenario can be powerful. For example, how does an IBM WebSphere Business Modeler project get handed to the Rational Software Architect user? How do web services built in WebSphere Integration Developer get traced back to business objectives in Rational Portfolio Manager? These issues are often complex, poorly understood, and require a divergent set of skills. Unfortunately, they are also where customers report significant frustrations.

Green threads are not intended to be exhaustive. By design, the green threads team keeps the number of threads small; ideally, three or so should be the maximum. This restriction is important because it:

  • Keeps things manageable.
  • Brings a necessary focus on identifying and prioritizing the strategic paths that are the most critical, and consequently, others that you can pay less attention to, thereby allocating resources effectively.

Trying to emphasize everything is equivalent to emphasizing nothing, so the importance of the initial identification and prioritization really can't be overstated. As a result, this first phase of the process—which amounts to little more than listing the chosen threads and their brief descriptions on a single slide—is the hardest part of the green thread process and one that requires strong leadership. This leadership is best provided jointly by a senior engineering lead and a senior customer-facing product or portfolio manager. The collaboration of business and technology experts here is essential to ensure the right threads are chosen, to provide credibility and authority for the work that will be undertaken as a result, and to build up a virtual team around each thread that can develop its detail and drive the resulting improvements.

Once the list of threads has been identified, the next step (see Figure 1) is elaboration: the detailing and documenting of the green thread at a fine level of granularity. When complete, this step can produce documents several hundred pages in length that detail from beginning to end the steps taken, the tools used, and the information necessary at each step. To further this aim, the documents tend to make extensive use of screenshots and other supplemental information about the product's behavior. While the work product of this stage is vastly larger than in the initial identification stage, the work is easier for three reasons:

Figure 1: Detailing and documenting the green thread.

  • With the hard questions about which scenarios to focus on already decided, the content requirements for the document are clear and well defined.
  • The identification and prioritization process inevitably pinpoints the people and teams with the skills and know-how to supply the detailed information necessary.
  • And perhaps most importantly, this work lends itself very well to being broken up and distributed.

With the subject-matter experts identified, individual teams can compile the backing documentation for their portions of a green thread in parallel and within a relatively short amount of time; see Figure 2.

Identify & Prioritize Jan 2—Jan 25 Three green threads are identified; alignment of threads across products reviewed; priorities are agreed.
Detail & Document Jan 25—Feb 9 For each thread, key workflow steps are identified and elaborated. These structure the face to face walkthroughs and help identify key players.
Scenario Walkthrough

Products A, B, C: Feb 20—21
Products C, D, E:Feb 26—27
Products E, F: Mar 1
Product G: Mar 8

Face-to-face walkthroughs for each product are held with the key technical leads (plus support teams like usability, technical writing, and test). Focus is on optimizing proposed workflows and identifying gaps.
Finalize Documents Apr 27 Issues and discussion are captured; workflow details updated if necessary.
Code Rewrites & Milestone Assessments May—Dec Responsibility for green threads handed over to the product teams; they drive through the rest of the development cycle.
Figure 2: Sample green threads schedule for a 12-month product cycle.

The detailed document provides the structure and background for the walkthrough exercise and for the eventual recommendations, but it shouldn't be used as a script. The point of the walkthrough phase is to get the technical leads describing their portions of the green thread in turn, to drive discussion and uncover new problems; it can start with nothing more than a whiteboard and a blank piece of paper. From a scheduling perspective, the walkthroughs can become a painful endeavor because it is important that all the key technical leads are physically present, and they typically take two days to complete. The motivation for this preference, though, is that in addition to serving as a validation of the compiled document, the walkthrough creates a legitimate and concrete forum for discussion and cross talk between products. Having people physically present and able to dive quickly into certain issues and collaborate on real, implementable solutions adds immensely to the quality of the eventual recommendations, as well as significantly increasing buy-in among the technical leadership to follow issues through to resolution. This environment is often the first opportunity that technical leads have to see their products in the context of complex cross-product interactions, and with sufficient detail to allow discussion of possible solutions. It quickly becomes a fertile environment for positive change and is the first place that the tangible benefits of the process become clear.

The result of the first three stages is a mountain of documentation and feedback, and a better understanding on the part of technical leads about the extent of (and problems with) their product's interactions. Translating this information and goodwill into action is the meat and potatoes of the green threads effort. The first step, after the walkthroughs are complete, is to capture and distill the set of issues discovered in order to complement the green threads document. This should be made available to all participants in some kind of collaborative environment (Lotus Notes database, wiki, and the like), so that further discussion can occur around the recommendations for resolving each issue. Once compiled, there are three chief consumers of this information:

  • First, and most obviously, a set of recommendations should be developed for each product team that can create immediate, meaningful improvements. These recommendations should be managed and prioritized through existing bug and feature-tracking mechanisms; green threads are not an attempt to add another layer of process to existing infrastructure.
  • Second, for the products already existing in the field, the discussion around the green threads exercise often yields short-term workarounds for certain interactions, which can be given to your support teams and customers immediately rather than asking them to wait for the next set of product releases.
  • Third, the green threads team needs to communicate the larger, strategic recommendations to your organization executives to ensure that the long-term direction of your products moves towards seamless integration from end to end. Far from being a deliverable independent of the first two, this long-term vision helps to situate the tactical recommendations within an overall plan, so that incremental changes move in a consistent direction and technical leads continue to see the value of allocating resources to their implementation.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.