Content uploaded by Tim Mackinnon
Author content
All content in this area was uploaded by Tim Mackinnon on May 08, 2014
Content may be subject to copyright.
Innovation and Sustainability with Gold Cards
I am not a load factor - I am a free man
Julian Higman Tim Mackinnon Ivan Moore Duncan Pierce
Connextra Ltd.
Studio 312, Highgate Studios
53-79 Highgate Road
NW5 1TL, England.
+44 (0) 20 7692 9898
{Julian, Tim, Ivan, Duncan}@connextra.com
ABSTRACT
An XP team delivers what the customer asks for and is
collectively responsible for successful delivery. This can
lead to two problems. The first is technical: there can be a
lack of innovation because the customer does not
necessarily explore options that are technically possible but
not currently required. Consequently, cutting-edge
knowledge may be slowly lost from the team. The second is
personal: team members may not feel that they have
individual recognition, and managers may find it difficult to
assign credit for individual contributions because of
collective responsibility.
Perversely, both of these problems are more noticeable as
the team becomes more experienced at executing the XP
process. At Connextra, we have experienced this effect
over the last two years, and have successfully implemented
a new practice called “Gold Cards” that addresses these
issues. XP takes away the blame culture; Gold Cards
promote a praise culture. Gold Cards allow developers time
to explore technical possibilities in a controlled and focused
way that leads to innovative stories which give team
members a chance to be individually recognized. This has
resulted in a noticeable increase in innovation and
improved job satisfaction among developers.
Keywords
Extreme Programming, sustainability, cards, motivation,
learning, continuous learning
1 INTRODUCTION
Connextra is a 2.5 year old company with 35 employees,
working with Internet technologies. When the company
was started, the founders were interested in using XP to
create their first product. To this end, the company (right
down to the design of the office) was based on XP
principles.
The physical environment
One of the key XP principles is to program in pairs, and
from the second week of development, convex desks were
installed to facilitate side by side paired programming.
There are no individual desks or computers, and so for
access to e-mail there are some “web cafe” style machines
where any developer can login as required. There are also
several screened booths that are equipped with phones
where personal calls can be made, or individual work can
be performed. Furthermore, each developer has a locker
where they can keep personal items.
20 Iterations and counting
We have been working in this environment for 20 iterations
each lasting 3 weeks. Every morning we gather around a
planning board and hold a standup meeting where we
discuss the progress on yesterday’s tasks, select new
partners, and focus on completing the remaining tasks in
the iteration. We have found that we have become very
good at this mode of work and have rarely missed a
delivery target. In effect, we have really seen the benefits of
applying the XP process to customer requirements.
Story Processing Machines
As a team, we have a real sense of accomplishment and are
always striving to improve our velocity and deliver greater
value to our customers. To this end we are constantly
looking at our storyboard and trying to check off as many
stories as possible. We have become a software factory in
the true sense. Worryingly, we began to observe that we
were missing something.
Religious Guilt
In conversations with colleagues in other companies, we
noticed that we were missing the ability to sit alone at a
desk and try out ideas, untroubled by the work of the rest of
the team. These colleagues were able to “waste time” on
non-deliverables without suffering from the “religious
2
guilt” that such time was not contributing to the project
velocity. In our working environment there were only 2
places to be legitimately for any length of time: 1) pairing
at a development machine, or 2) at a “web cafe” machine,
checking and replying to email. If you weren’t in either
place you would feel that you were wasting time. There
was no place to be where you could think of new things
without feeling guilty. However, any development effort
needs to look continually for innovations in technology and
process, which often come from the lateral thinking of
individuals, rather than a collective focus on task
completion.
Spikes were a delay
Once the team had finished the iteration and were preparing
for the next planning game, we found that we weren't
always able to accurately estimate items being introduced
in new user stories. In those cases we would take several
days to spike potential solutions and play (to a limited
extent) with new technologies. While this helped us give
accurate estimates, unfortunately the users viewed it as an
activity that was getting in the way of starting the next
iteration. We also noticed that this time rarely allowed us to
experiment with “blue sky” possibilities because our mind-
set was constrained by the existing expectations of both
customers and developers. Customers didn’t know what
possibilities existed, while developers didn’t know whether
they were feasible (if requested).
Positive Recognition
As we have been working together, we have formed a real
sense of team. We pair with each other, share knowledge,
and have a collective responsibility to make sure that the
best job gets done. In a “no blame” culture there also needs
to be room for positive contributions that don't detract from
the sense of team. Many team members had some great
ideas but found that there was no way to explore them
without feeling that they were letting the rest of the team
down. It is a perfectly human impulse to want to impress
your peers with new ideas, but not at the expense of leaving
other team members to bear the burden of finishing the
committed work.
The dreaded review
As the company grew, more formal personnel procedures
were introduced, part of which included a regular review
process. This was viewed as a healthy addition to our
working practice. However, in a team-based process like
XP, it was difficult to point to specific achievements that
would allow individuals to be recognized and rewarded.
We tried agreeing on action points that would be reviewed
in the next period, however in our software machine there
was never a good way to make sure that these points were
addressed adequately. Again, the religious guilt was
kicking in.
Velocity was high, morale wasn't
At about the 15
th
iteration, we began to notice that while
everyone was making sure that they contributed to the
velocity, there was a certain sense of dissatisfaction with
our success. We are all aware that every day there are new
tools, new APIs, and new products that are all likely to
have an impact on our business, and we all want to stay
ahead of the curve. It's good for an individual’s skills to be
able to practice new techniques, and good for morale to sort
out aspects of the development environment that are
annoying. Some of us tried to work on this stuff after
working hours, however a full day of guilt-free paired
programming is extremely tiring. An XP practice is the 40-
hour week, and we were devoting this to task completion,
leaving no room for individual achievements.
Remembering the old days
When you pair-program with people every day, you often
reminisce about how it was in the “good old days”. Some
of us tried working alone on pet projects after hours and
reported back to the others that it was a useful reminder that
paired programming is actually a more efficient way of
working - you just need a reminder from time to time.
Sometimes however, it is nice to work alone for a short
duration and have the time to cover new material
unhindered by a partner's questions. Furthermore, some
days people just feel unsociable and want to work by
themselves for a change.
Everything goes gold?
To address these issues we introduced a new practice that
we call "Gold Cards". As we are used to planning and
working using index cards, we decided that a special kind
of card would be a suitable way to integrate a new approach
to innovation and sustainability.
2 THE GOLD CARD SYSTEM
A Gold Card is an index card with a gold star on the top left
hand corner, 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 1/10
th
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, then we use an honour
system where people pro-rata 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, by:
• Creating new business opportunities through
the exploitation of new technologies. These
could become customer stories.
• Reducing cost by improving the efficiency of
3
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 an
allowance of 2 Gold Card days a month. To introduce Gold
Cards, we needed to recalculate our velocity for the first
iteration that included them (the 17
th
iteration). We
calculated that 2 Gold Card days a month is approximately
10% of the working time available, if each month is taken
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 expiry 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 are able to make
suggestions. Doing this helps make the system self-
managing in that people will only take Gold Cards when it
will not adversely impact 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 we have found that
some team members have simply opted to use their card on
an alternate day. Whole days of work are preferred in order
to avoid fragmented working, but card allocation is reduced
pro-rata with holidays taken in the month, so half days can
occur.
Before starting work on a Gold Card, we encourage people
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 [3] for other developers to refer
to or to contribute related ideas. The card itself is kept for
the developer to produce at their next review.
Finally, at the next standup meeting a developer who has
worked on a Gold Card will briefly summarize 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 [5] 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 also 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 also
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” [2]. This
book gave rise to the idea of how to allow 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, and so it seemed natural
to use cards as a way of introducing this idea in an XP
way
1
. With a basic proposal in place, we approached the
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, and 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 on 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
1
Originally we were going to call the scheme Green Cards,
as this was a color of index card that had not yet been used
in the company. Unfortunately, the day before launching
the scheme, we discovered that our stationers had stopped
supplying green colored cards. Inspired by a recent trip to a
dentist who used gold stars on appointment cards, one
author suggested that our Office Manager simply stick gold
stars on white index cards so that we would have a ready
supply.
4
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 [5], delivers
contextually relevant information into a separate window
from the user's web browser. 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.
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 allowed a list of versioned classes to be
loaded from a file. The resulting tool has increased speed
and accuracy of the release process.
A Gold Card that reduced risk:
For historical reasons, our software has a dependency on
the Microsoft 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, allowing 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 that
they have been scheduled into our development iterations.
Although we can only refer to 3 iterations worth of
measured velocity data, our early indications are that we
have not observed any additional decrease in project
velocity. While 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.
While 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 would 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
While the scheme has generally been a success, we have
had a few teething problems.
There have been a few times when a Gold Card was not
converted into a real story soon enough. This is noticeable
when a single developer continues to work on the same
topic continuously and 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 only have 2 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. While 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, then it should be written as a proper story and
prioritized with other stories in a planning game. Once this
distinction had been made clear, and some of the results
from previous Gold Cards had been observed, then 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 due to too many of them being
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 10 developers, we need an
average of one Gold Card to be exercised per day for the
5
allocation to be spread evenly throughout a month.
Fortunately, as 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.
3 COMPARISON WITH OTHER APPROACHES
There are approaches similar to Gold Cards, which we
considered when devising the scheme.
The fact that a developer generally works alone on a Gold
Card naturally prompts comparison with a developer acting
as a Lone Ranger. The term Lone Ranger was coined to
describe the role of a developer who has no partner in an
odd numbered team. The Lone Ranger carries out tasks that
are usually administrative in nature, and which the team has
identified as needing doing but do not requiring a partner.
For example, tasks such as checking for development tool
and API updates or answering support questions. In
contrast, Gold Card work is chosen by a developer.
Study groups [3] are an excellent way of spreading
knowledge in a team. In study groups, developers
optionally meet to discuss important technical topics. The
use of Gold Cards and study groups are not mutually
exclusive, however study groups do not address the issues
of innovation and individual recognition that motivated the
introduction of Gold Cards. While study groups are ideal
for a team starting out with XP, we would introduce Gold
Cards as a practice when indications of religious guilt are
encountered.
Some teams do experimental and administrative tasks in the
morning, and pair program in the afternoon [Arie van
Deursen, personal communication, May 2001]. Gold Cards
do not allow as much time for such activities, but do allow
a developer to work for a whole day of their choice. This
means that on a day when a developer really wants to
explore something in detail, they have enough
uninterrupted time to tackle a significant task. In our
opinion Gold Cards are a much easier practice to sell to
management. Furthermore they do not impose a time slot
that could correspond to the most productive time of day.
We would also envisage that the half day approach would
need much more careful monitoring to prevent the adverse
affects of code ownership.
At a company that two of the authors worked for (OTI [4]),
developers were allowed to work on self-directed tasks on
Friday afternoons. Although this is a simple scheme, there
was no explicit mechanism for feedback from the results of
the work undertaken, which reduced its benefits. In
practice, Friday afternoons were not always available for
self directed tasks because of pressures to finish work
before the end of a week, or simply because inspiration for
an idea had been lost by the time Friday arrived. Feedback
from our team has indicated that the ability to pursue an
idea when it is hot is important and very satisfying.
4 CONCLUSIONS
Our experience has shown that Gold Cards have increased
innovation, improved efficiency and provided greater
recognition and motivation for developers.
By setting aside time for legitimate investigations, Gold
Cards have addressed the problem of developers feeling
constrained to only think about current tasks. They have
allowed for "Blue sky" experiments that have led to
genuine business opportunities and new ideas that have
inspired both developers and users alike. These
investigations have also enabled us to estimate new
development tasks more accurately.
Furthermore, tools created in Gold Card time have
improved the efficiency of the development process, and
addressed those issues that were most annoying to
developers.
Finally, developers have enjoyed the time they've spent
working on things that they have personally chosen,
without feeling as if they are cheating on the team or
detracting from the completion of customer's stories.
5 ACKNOWLEDGEMENTS
We gratefully acknowledge the contributions of John Nolan
and the Connextra development team. This paper also
benefited from feedback from the attendees of the XP2001
Experience Exchange workshop.
REFERENCES
1. Cunningham, W. Web Site. On-line at
http://c2.com/cgi/wiki?WikiWikiWeb
2. Heeks, Allen The Natural Advantage, Renewing
Yourself, London England: Nicholas Brealey
Publishing, 2000
3. Kerievsky, Joshua Continuous Learning, XP2001
Conference proceedings.
4. OTI. On-line at http://www.oti.com
5. Sidewize. On-line at http://www.sidewize.com
