Get certified - Transform your world of work today

The Blue Peter Problem

How to overcome the perception that agile artifacts are unprofessional

07/02/2007 by Nigel Baker

I work as an Agile Coach/Consultant for BT Exact, a British Telecommunications’ business. BT is a provider of communications solutions to customers in Europe, the Americas, and Asia Pacific. Its principal activities include networked IT services, local, national and international telecommunications services, and higher-value broadband and internet products and services.

BT Exact is BT’s information technology and operations business. The IT programmes of work are designed to drive products and services, and to create a zero-touch, self-service, real-time world for BT's customers. Our programmes run in ninety-day cycles and adhere to specific delivery targets and return on investment criteria. They encompass a number of agile working methods and best practice modeling techniques to sharpen customer service.

Agile methods are all about using simple tools and ideas well. However, while concepts such as Test Driven Development, Continuous Integration and iterative development generally are well received, agile’s physical artifacts (such as hand-drawn graphs, cards, and paper) can seem unprofessional both within and outside the teams, especially in large and political organizations such as BT. Team members, who are already making large moves outside of their comfort zone in trying agile practices, are often reluctant to begin working with paper, cards, and magic markers.

The Blue Peter Problem

I term this reluctance the “Blue Peter Problem” because when we initially start using markers, paper, and cards, people instantly refer back to their childhood. In the UK this is most commonly associated with Blue Peter, the famous UK children’s television show, and to its famous “Builds.” Builds are some form of object/present or general construction made with pen, paper and glue for children to copy and create at home. In the U.S., you might associate them with Mr. Rogers at his kitchen table, making crafts and singing songs about how special you are.

Blue Peter


Regardless of where you grew up, the fact is that most of us harbor an inherent prejudice about using paper and markers: we believe that tactile construction of artifacts is a childish activity performed by children. This prejudice can make these artifacts seem not “simple” (an agile principle) but “simplistic” (i.e. lacking depth or insufficient). Not a serious adult working practice, but a silly gimmick.

For the business professional in companies with a very traditional, professional environment, the use of hand-drawn charts and pieces of paper can be embarrassing, especially in the type of multifunctional, shared office space, large multinational companies tend to have. Team members ask, “How can we demonstrate professionalism to our Sales/Accountancy/Business colleagues with such artifacts around our working space? How do we relate to them?”


There are two key preconditions to any possible answer we have to this problem:

Precondition One – We do not want to deprecate these techniques. They help, they are easy to do, they help keep teams stay on the straight and narrow and they can be an integral part of the agile experience.

Precondition Two – While we can, to a certain extent, web enable some of these techniques, (online Product Backlog, e-burndown charts, etc) it is very easy to add additional unnecessary complexity to what are supposed to be simple tools. If we are not careful, we could end up transforming a thirty-second task into something that takes an entire morning of updating spreadsheets, wikis, capturing tools, etc. We do not want to lose that immediacy. A Spreadsheet saved on a wiki does not have the impact of an A3 Burndown, pinned a foot from your screen.


burndown chart

I’ll not pretend I have the solution to overcoming this prejudice, but I do have a suggestion: Perform a little sleight of hand. Build physical artifacts that have an essence of professionalism.

For example, we have branded Burndown chart paper (as shown).

It’s a laminated sheet with company branding, in free range scale, so it’s easily reusable. The charting can be done by hand in a planned color scheme.

You also can have official company user story cards, formatted in the card style suggested by Mike Cohn. We have created these at BT and already the mere existence of an official “user story card” has increased uptake and allowed teams to share these objects far easier then before.

story cards

I have noted other Agile Consultancy companies such as Thoughtworks and Exoftware have done something similar.

Another useful tool is the pre-built Agile team kit, containing the equipment needed to use these artifacts (stickers, cards, and markers in the right colors).

This keeps the work area productive and adds no overhead, yet it adds the flavor of “official-ness” and a degree of seriousness. There is no extra effort to match company color schemes, but the area created is both functionally useful and also exhibits the team ethos in a professional manner.


The Agile Coaching Community in BT has also suggested some as yet untried concepts, such as:

  • Retrospective Sheets – A preformatted flipchart, with added branding.
  • Product Backlog Area – Perhaps for pinning to a corkboard? Perhaps to help in identifying the Wallspace? Could this be magnetized? Branded?

After a short while, the team naturally will move away from the need for such stylistic fudges as they begin to understand the substance of what they are doing, using whatever materials are on hand, and whatever methods they feel are appropriate. However, in the short to medium term, a little “flash” does help assuage teams’ fears in large, professional companies: that they can continue to exude a “professional” and “serious” face to the rest of their business community.

These branded products are only a “sleight of hand.” (In less polite society, I would call it a “con!”) The team is reassured with these objects, though there is no difference, bar presentation of the objects. This makes the movement into a more agile state smoother for the team, and smoother for other teams making that move. We ease the pain of change, the pain of transition.

In the end, it all comes back to perceived value. If the artifacts look like they have value, then people will treat them as if they have value. Once they understand the principles behind the object, we can throw these things away.