The One Day Ideas Splurge

by Chris Gathercole

We have recently experimented with some dev-first approaches for some distinctly different scenarios

• riffing on a specific theme; generating and exploring lots of ideas quickly
• starting a tech-architecture-heavy project

and were very happy with the outcomes.

tl;dr The essence of both approaches is

• get the core group sitting in the same room for a day (Co-location is great. Who knew?)
• dump all possibly relevant information into the mix at the start
• let the developers have a play
• see what happens

What follows in this post is a more detailed look at the approach we took for …

Riffing on a specific theme; generating and exploring lots of ideas quickly

The Advertising Team’s stakeholders had been discussing the same issue for months, over many meetings, making no discernible progress. Nothing emerged that was substantial enough to make it onto the team’s development backlog. The initiative had stalled for lack of good ideas. What to do?

We had

• a fairly well defined challenge: how to increase the time at least 50% of the ad creative is visible to readers, for up to 5 seconds or longer (oh and not aggravating those same readers). This is to increase “ad viewability” (a new industry metric upon which advertisers are judging success), and to enable a new ads revenue stream in billing by time.
• lots of people with info and experience, i.e. stakeholders, passers-by, ads sales folk, etc
• 4 developers
• PM and PO very keen to kick-start this initiative, and a willingness to try a new approach
• a whole day with everyone in the same room (or at least, available to be)

Simple brainstorming, where everyone is in the room with orders to ‘be creative’, is not very effective. In fact this format is particularly uncomfortable for more-than-likely-to-be-introverted developers.

We wanted to make the best use of the knowledge in people’s heads, and developers’ ability (and need) to focus, when uninterrupted. So, we started with some basic elements from the more structured approach known as Creative Problem Solving, and constructed a schedule for what turned out to be an intense and productive day.

START

END

DURATION

OVERRUN

PHASE

9:30

10:15

45m

15m
Set Scene: Share Info; everything we’ve got on the problem, potential solutions, stats, ideas from design/UX about the kind of things which do/don’t work
10:30

10:45

15m
Generate Ideas: classic brainstorm, everyone shouts out ideas, no such thing as a bad idea, everything captured, riffs on previous ideas
10:45

10:50

5m
Each team claims an idea, or constructs one from the mix, guesstimates what help/advice (if any) they might need
10:50

12:10

1h20m
Dev! Teams can request assistance in mid-flight
12:10

12:20

10m
Show & Tell: record (3mins per team), discuss (2 mins per team)
12:20

12:25

5m
Review process so far: inspect + adapt
12:25

13:25

1h

Lunch

13:25

13:35

10m
Generate new ideas: brainstorm, riffs on previous ideas
13:35

13:40

5m
Each team claims a new idea
13:40

15:00

1h20m

Dev

15:00

15:10

10m
Show and tell
15:10

15:15

5m
Review process so far
15:15

15:25

10m

5m
Generate new ideas
15:30

15:35

5m
Pick an idea
15:35

16:55

1h20m
Dev
16:55

17:05

10m
Show and tell
7h15m

total

The essence of the CPS process is straightforward: you loop around

• explore the challenge
• generate ideas
• idea exploration (aka prep for action)

As part of ‘explore the challenge’, there are numerous techniques for helping a group home in on what the challenge actually is, aka Objective Finding. In other projects, this has been surprisingly difficult. For us, the ads challenge was already well defined: “have ads visible in their entirety for 5 secs or longer”. The remaining part then is Fact Finding, and is as simple as having a 1 hour burst of everyone with any interest/involvement/knowledge of ads, stakeholders, passers-by, etc, plus the entire project team, all in the same room, throwing info and questions into the mix. This info was recorded as it emerged, questions were encouraged, tangential points welcomed.

Already we were ahead:

• the notes of this meeting have formed a very useful repository of all things ads
• it was the first time many of these people had met
• it was the first time much of this info had ever been shared
• the dev team was able to demonstrate an interest in and engagement with the topic that had not been realised/appreciated by the stakeholders
• the questioning helped drive out many possibilities into the open

and the main iterations begin

With everyone primed with relevant info, we started the first of the three main iterations of the day. Each iteration involved

• Idea Generation. a burst of divergent thinking. No filtering. Go for quantity not quality. There is no such thing as a bad idea. This is time-boxed to ensure we keep the energy levels high and it doesn’t fizzle out. Don’t worry if you don’t get your idea out now. There will be more iterations later.
• Idea selection. Now is the time to converge, filter, home in on an idea. Mash together ideas.
• Idea exploration/development. The developers let rip.
• Show and Tell. The developers share what they’ve found.

The whole group stayed in the room for the idea generation. It was a natural culmination of the Fact Finding. Some seriously off-beat suggestions emerged. Again we were ahead. Nothing like these ideas had emerged in the previous months.

The developers had by this time self-organised into two pairs. Each pair selected a hybrid of several ideas from the big list that tickled their fancy. And almost everyone (except the developers) now left the room. This was important. The developers were the key folk of the day; the focal point of this process. We had force-fed them with the context, answered their questions, given them a free choice of whatever they fancied a crack at, and now everyone got out of the way to let the developers get on with it for the next hour and a half.

Why an hour and a half? (increased from the initially scheduled hour) This was long enough to explore and think about an idea; to be able to cobble together a simple bit of javascript, but not long enough to even bother trying to build anything substantial. The idea and the thinking about the idea were the thing, not the implementation.

And the devs put in some seriously hard work. This was like an entire hackday rolled into 90 minutes. Having said that, there was no requirement to actually have a working thingy. Failure was most definitely an option. The exploration of the idea was sufficient, a powerpoint slide would be fine, and any flashy javascript was a bonus.

Time’s up. Pens down. Fingers up. The stakeholders troop back into the room. The show and tell began. Each idea gets 3 minutes: just enough to show a working thingy (or powerpoint slide) and describe how it might be achieved for real or not, plus any thoughts or lessons learned; to give a sense of whether it was worth pursuing this idea. Some questions and suggestions from the onlookers amounted to more ideas being thrown into the mix for the next iteration. All the demos and discussions are documented.

The iteration ends, with a mini retrospective, looking for any tweaks we could make to the process. Example tweaks included

• increase the dev time per iteration from 60mins to 90mins, even at the expense of a much shorter lunch (yes, this was preferred), then back to 80mins because one of the group had to leave before 5.30pm
• one of the teams split into two singles
• a request to revisit an earlier idea in the next iteration (which we resisted)
• … but, otherwise, the process was so simple and effective there wasn’t much need or urge to change things.

Another iteration begins. A few more ideas are pitched in, but there are already oodles in the pot from before. The developers (now self-re-organised into one pair and two singles) each craft their own new idea from the ones on offer, NB no continuing with their previous idea since we want breadth not depth. (Almost) Everyone leaves the room. Another 90 minutes of hard work. And make no mistake, this is hard work. There is a strong pressure to deliver something. No-one wants to fail, even though that would be a valuable learning. Javascript skillz under the microscope, but everyone helps each other.

Time’s up. Show and tell. And then one last iteration. Tired now

And this is it. Final show and tell to a full house. All the stakeholders have stuck with it, partly to support the efforts of the developers, but also partly because the ideas are good and the show and tells have been interesting and thought-provoking.

A total of 8 ideas explored, from 3 iterations by 4 developers. All of the ideas triggered follow-on thoughts, raising further possibilities. All the ideas have been explored sufficiently to have a good sense of what could/should be taken further and how much effort would be needed.

One of the ideas, “Sticky Top”, is currently being tested on the live site, generating some impressive results which will be proposed to go fully live next week.

However, one idea in particular emerged as possibly the most hideous thing we could imagine ever doing to our readers. It would surely contravene health and safety guidelines, and possibly the Geneva Convention. It encapsulated the essence of pretty much everything we knew to be evil and wrong on a webpage. Yes, vibrate the ads with increasing vigour until the reader is forced to mouse-over the ads to calm them momentarily. Not only do we get increased visibility, we also get increased interaction with the ads. Oh yes. There were groans of dismay from one corner of the room, gasps of awe and wonder from another, mixed with the sounds of retching, and then applause for a truly gruesome idea done well.

(using Jack Rugile’s rumble code)

And so, what were the outcomes?

• everyone meets everyone else, stakeholders, dev, etc
• everyone gets to hear everything, ideas, hopes, dreams, problems
• the dump of info is itself a good resource to analyse
• everyone riffs off everyone else in generating the initial set of ideas
• this set of ideas is also a good resource to analyse
• the sense of progress is palpable
• devs have a chance to shine
• the stakeholders get to see the devs (possibly for the first time) as committed, informed, passionate, and capable of independent and useful thought
• the quality of discussion around a working (or explored) idea is better than around an abstract idea
• a portfolio of worked ideas

And the lessons learned?

• it is quite intense for the developers. They wouldn’t want to do this every day.
• the idea is the thing, not the working implementation of it. Unlike with a regular hackathon, it is perfectly ok to try and fail in the hour. The 3 min show and tell can be full of couldas and shouldas and hand-waving.
• perfection is not the thing. The devs are likely to find it hard to let go of an idea that is not yet ‘finished’. They want to spend ‘just a bit more time on it’, not try a new one, but trying a new one is by far the best thing to do in this splurge. (by all means finish off an idea implementation another day)
• for dynamic UI ideas, especially involving Ads, it is better to capture the idea in a video rather than static screenshots
• If you (stakeholders|architects) dream up ideas first, then involve the dev team second, you are throwing away a significant opportunity to educate, motivate, and involve the entire team but, more importantly you are also missing out on better ways of generating good ideas and learnings.

This approach, the one day ideas splurge (possibly needs a better name), is repeatable. It is possible to identify very specific scenarios where it will be useful. It is more productive than naive brainstorming, and the classic hackathon (given the same number of developers, caveat, caveat, caveat). We have added it to our quiver of options.