The Gold Card System


A Gold Card is an index card with a gold star on the top left-hand corner, and a developer's name and the month of validity written on it. Each developer is allocated two Gold Cards at the beginning of each calendar month, which makes managing and issuing the cards very easy. This allocation amounts to about one-tenth of a developer's time and is treated as a fixed overhead. Gold Cards can be used at any time during a month but cannot be carried over into the next month. If a developer has any holidays booked in the allotted time period for the card, we use an honor system, where people prorate their Gold Card allowance, rounding to the nearest half day.

Each card grants the developer who has it one day of work on a topic of their choice. An explicit aim of the scheme is for developers to try to convert their Gold Card work into stories. Ideally, topics should have some potential for business value, such as the following:

  • Creating new business opportunities by exploiting new technologies. These could become customer stories.

  • Reducing cost by improving the efficiency of the team for example, by developing new tools.

  • Reducing risk by exploring new and alternative technologies.

Unlike development code that requires a pair, Gold Cards can be worked on alone or in a pair, the latter requiring both developers to use a Gold Card.

Recalculating the Velocity

Having proposed the scheme to management, we agreed on an allowance of two Gold Card days a month. To introduce Gold Cards, we needed to recalculate our velocity for the first iteration that included them (the seventeenth iteration). We calculated that two Gold Card days a month is approximately 10% of the working time available, if each month is considered as having approximately 20 working days. Thus, our new velocity was calculated as 90% of our previous velocity (meaning that our load factor has risen to take account of this extra overhead). We used this figure for the velocity in the next iteration, and it worked out fine. In subsequent iterations, we have simply used our velocity from previous iterations (that include Gold Cards) without any further adjustments.

Although there is no relationship with iteration length and Gold Card expiration times, we have found that the stability of our velocity has not been adversely affected, and the simplicity of monthly allocations means that there is little overhead in running the scheme.

How to Take a Card

At the morning stand-up meeting, a developer can express their intention to take a Gold Card that day. It is usual to explain what they are going to investigate so that other people know what they will be doing and can make suggestions. Doing this helps make the system self-managing in that people take Gold Cards only when it will not adversely affect the iteration. In practice, most Gold Cards are taken without difficulties. On the rare occasion that a large number of people have been inspired to step forward to use a Gold Card, some team members have simply opted to use their card on an alternate day. Whole days of work are preferred to avoid fragmented working, but card allocation is reduced pro rata with holidays taken in the month, so half days can occur.

Before people start work on a Gold Card, we encourage them to write on the card what they intend to achieve. At the end of a Gold Card day, the developer summarizes the results of their work on the company intranet (we use a Wiki based on Ward Cunningham's original Perl script),[1] and this forms a learning repository for other developers to refer to or to contribute related ideas [Kerievsky2001]. The developer keeps the card to produce at their next review.

[1] See http://c2.com/cgi/wiki?WikiWikiWeb.

Finally, at the next stand-up meeting, a developer who has worked on a Gold Card briefly summarizes what they did and what future work or possibilities that Gold Card has created. Sometimes this summary may be a warning that the idea is one that should not be considered any further.

Although a developer chooses the topic for a Gold Card, they do not necessarily have to think of a topic themselves a number of topics proposed by other developers, or even customers, are available. These are organized on sticky notes on poster boards to stimulate discussion and establish relationships among various ideas. We have four poster boards, each covering a different topic area: New Technology, Tools, Cool Sidewize Services, and XP Process. Each poster has an owner, who encourages work in that area, maintains an overview of progress to date, ensures that work is not repeated, and offers advice on any of the topics. The poster owner also offers a point of contact with the rest of the business to ensure that potential business value is not missed.

Developers who are unsure of how to spend a Gold Card can look at these posters for inspiration and can discuss ideas at the stand-up meeting. We have noticed that many people begin to consider and discuss the work they will do a few days in advance. We also try to encourage each other to try out varied topics.

A Little History

The Gold Card system was partly inspired by the book The Natural Advantage: Renewing Yourself [Heeks2000]. This book gave rise to the idea of how to enable developers to renew themselves but still give business benefit. In discussions between the authors, we imagined a scheme akin to undergraduate professors posting ideas on their office doors to encourage students to choose interesting thesis topics. In our office the use of cards is pervasive, even in other parts of the business, so it seemed natural to use cards as a way of introducing this idea in an XP way.

With a basic proposal in place, we approached the chief technical officer (CTO) and described the aims and benefits of the scheme. These discussions were particularly helpful because we hadn't clearly defined the potential business benefits of the cards, so it initially proved difficult to get his support. Once we adjusted the proposal to clearly state the rules for providing business value, we obtained his backing, and the idea was then easy to sell to our users. We also conferred with the other developers on our team to make sure that the idea was addressing the issues that we had observed. We launched the scheme with much fanfare, gold star badges, and a presentation of the posters.

Observed Results

Having run the scheme for a few iterations, we have observed many examples of Gold Cards that have satisfied the aims of the scheme.

A Gold Card That Created New Business Opportunities

One of our current products, Sidewize, delivers contextually relevant information in a separate window from the user's Web browser.[2] A Gold Card was undertaken that investigated a new style of user interface for content delivery, where relevant information is shown directly in the browsed Web page instead of a separate window. This work spanned two days of Gold Card time, and the end product of the investigation was a working prototype of a new interface. This demonstrated that the technique was viable, formed a useful basis for demonstrations, and gave us enough knowledge to estimate subsequent stories.

[2] See http://www.sidewize.com.

A Gold Card That Increased Efficiency

Our development environment is VisualAge for Java, with a single code base for all developers. After completing some code, a pair releases it on the release machine. One time-consuming aspect of this was the need to load in all the classes that have changed in an open edition of a package, one by one before integrating and releasing them. VisualAge offers no built-in mechanism to support this integration activity; however, it does provide a tool API through which operations can be automated. A Gold Card was completed that enabled a list of versioned classes to be loaded from a file. The resulting tool has increased the speed and accuracy of the release process.

A Gold Card That Reduced Risk

For historical reasons, our software has a dependency on the Microsoft Java Virtual Machine (JVM). Microsoft doesn't support Java after version 1.1, but Java development has moved on considerably since then. This represents a significant business risk. To reduce this risk, a Gold Card demonstrated the feasibility of replacing the Microsoft-specific Java code with native code, enabling us to use any JVM. This work has generated several new stories, which have been incorporated into our normal development effort.

We have been pleased that the results from many of the Gold Cards undertaken have inspired our users to propose stories that are related to Gold Card ideas. Furthermore, some of these stories have been given high priorities, so they have been scheduled into our development iterations.

Although we can only refer to three iterations' worth of measured velocity data, our early indications are that we have not observed any additional decrease in project velocity. Although we feel that the Gold Cards have been beneficial, we have not measured an increase in velocity. This is because the results of the Gold Cards have enabled us to estimate stories that were too risky to consider before, accept stories that previously we were unable to consider, or more optimistically estimate stories related to Gold Card topics. Unfortunately, these improvements are not reflected in our project velocity.

Although we have not yet had any employee reviews that have been able to use Gold Cards as a discussion point, our feeling is that we have observed individual contributions that warrant recognition.

Finally, we have also noticed that the more junior programmers on our team have benefited from the scheme in a slightly unexpected way. The time alone gives them an opportunity to make mistakes, and learn from those mistakes, while alone without feeling embarrassed or restricted. These valuable lessons are then used when they return to work with a partner the following day. This effect has been a pleasant surprise to us.

Warnings

Although the scheme has generally been a success, we have had a few "teething" problems.

A few times a Gold Card was not converted into a real story soon enough. This is noticeable when a single developer works on the same topic continually, and it results in a form of code ownership that is undesirable on an XP team. Fortunately, this type of problem is quite easy to spot and deal with because developers have only two cards a month that they can use. In these cases we have made sure that everyone is aware of the danger of using a Gold Card in this way and have ensured that if the idea merits further work, a proper story card is written up, and the knowledge is spread through the team.

We have also had to make sure that our users are clear on the meaning of Gold Cards. In a few circumstances, users have tried to request features by suggesting them as Gold Cards. Although we are not averse to users contributing additional ideas, we have had to make sure that they understand that Gold Cards may never necessarily be completed. If something is so important that it must be done, it should be written as a proper story and prioritized with other stories in a planning game. Once this distinction has been made clear, and some of the results from previous Gold Cards have been observed, this has not been a problem.

We have also found it important to monitor the use of Gold Cards to ensure that they are exercised evenly throughout the month by the team as a whole. We have had some situations where people have been unable to take their full allowance of Gold Cards because too many of them were left until the end of the month. Circumstances have sometimes meant that the team couldn't afford to have everyone exercise their unused Gold Cards in the space of a few days. With a team of ten developers, we need an average of one Gold Card to be exercised per day to spread the allocation evenly throughout a month. Fortunately, because the Gold Cards are pinned to the planning board along with user stories, it is easy to notice that they aren't being checked off at the correct rate.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net