The Blue Peter Problem

How to overcome the perception that agile artifacts are unprofessional

2 July 2007

Nigel Baker
AgileBear Ltd

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

Prejudice

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?”

Preconditions

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.

Style

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.

kits

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?
Substance

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.

 


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Jay Conne, CSP,CSM, 7/2/2007 12:39:33 PM
Nigel - thank you for this article.

I have found little resistance to using unbranded materials in smaller companies. Perhaps it's because I focus the whole discussion in training and start-up around the value. Once people get it in their gut, the format is unimportant - as long as it's legible. The challenge I find is getting similar effectiveness with electronic representations for distributed teams and other stakeholders.

I have used spreadsheets that I, as ScrumMaster, transcribed from cards on the taskboard. I put considerable effort into making them cosmetically attractive including color for emphasis and categorization as well as for the purposes you described. An example is on my website: http://www.jconne.com/burndownandvelocityexample/.

I would enjoy talking to you about your BT experience.

Jay Conne
www.jconne.com
jay@jconne.com
617-776-0339

Mike Lowery, CSP,CSM,CSPO, 7/9/2007 3:53:45 AM
Nigel,
This is good stuff, I am currently working on issues exactly like this within my organisation. We have little problem with teams doing things or adopting practices. More issues with senior figures seeing as you say these processes as simplistic or disorganised. I think that without actually changing anything (apart from these brands) you can make things appear to be far more sofisticated. It's just like wearing a suit or jeans to work people assume you are the CEO or the Janitor just from one glance. I am going to see if we can't get some branded materials too.
Andy Murthar, CSM, 8/2/2007 4:30:39 AM
Nigel: i came up against the same problems early on in the introduction of scrum. Rather than try and 'push' the point as 'the way scrum is done' i treated it as an impediment. We have a CMS so i moved all the card based info into the cms. I downloaded the free version of scrumworks and placed all backlogs, sprint backlogs, impediments into it. links to the cms are placed in the sprinted items for user stories, test cases, scrum diary,incidental notes etc etc. I placed an overhead projector in the office for teams to view their burndown if required, and a pc in the scrum room if reference was required. the unprofessional issues were solved and all were happy that they were living in the digital age again. ok this may not fit everyone, but my point is to be 'adaptive' as a scrummaster and listen very carefully to the needs of those who are involved in the project to ensure 'focus' is on the task in hand.
Derrek Wood, CSM, 10/3/2007 1:31:41 PM
I've not run into issues with the artifacts being 'unprofessional' per se, but I do tend to agree that an online "information radiator" is much more useful than a drawing on the wall. At least, for everyone who is not part of that team, it is much more useful for them to not have to wander by the teams location to make calculations on schedule and budget etc. For us, an online program does help with that, as the Product's schedule (and therefore budget) can be determined by looking at the Product Burndown Chart which is posted online. The CxO level can just look at the chart and, once they understand it, make their decisions/give input. Client management is also much easier this way, as we really don't need certain types of clients knowing what tasks the team is working on.
Michael James, CST,CSP,CSM,REP, 10/16/2007 2:18:55 AM
Thanks for this very practical article Nigel.

One note I'll add: Team self-management artifacts are for the *team*, not the suits and tourists. I try to draw a distinction between things the team needs to use on a daily basis (such as their taskboard, and perhaps the Sprint burndown chart), and those more suitable for the rest of the organization (such as the Product Backlog, and release/product burndown chart). I'd go for minimum possible ceremony when a team member is moving a task from "not started" to "in progress" on the taskboard, and maybe a little more external visibility when Product Backlog Items are accepted during the Sprint Planning Meeting, or signed off as "done" in the Sprint Review Meeting.

--mj
Harry Long, CSP,CSM, 8/7/2008 2:09:57 PM
Has anyone heard of or used a sftware tracking tool called TargetProcess? It has benefits and challenges, but I find that going to the basics is still the best communication option.

You must Login or Signup to comment.