Code Personal

The Rapid Concepting/Development Experiment

Monday was the start of Lab Week for the developers at CIM. The idea being that the developers could get a chance to work on stuff that wasn’t part of their everyday routine. Similar to the 20% time that Google has made famous, but in this case the time is collected and used as a team over the course of a week (Lab Week).
See how it all worked out.

Monday was the start of Lab Week for the developers at CIM.  The idea being that the developers could get a chance to work on stuff that wasn’t part of their everyday routine.  Similar to the 20% time that Google has made famous, but in this case the time is collected and used as a team over the course of a week (Lab Week).

Overall I think the concept behind Lab Week is great, we just need to smooth out the implementation.  Based on how things ran I learned that for Rapid Iterative Design (method modified from Todd Warfel‘s talk at Refresh Philly) to work there needs to be a moderator.  Ideally the moderator would be an unbiased non-participating person, and not the HiPPO in the room (Highest Paid Person’s Opinion – alla Google’s talk to CIM from a week earlier).  This moderation seems to be needed to keep the pace of the itteration process as well as keep people in the present and focused on the current goals.

Two other things that I feel would aid the overall goal of Lab Week are the removal of other external workload stresses and bottom up decision making.  Actually, I think these last two are essential components, without them it’s hard for members to focus on the lab project or feel the level of project ownership that motivates and inspires.

My comments above meant to guide us for the ideal Lab Week.  For our first run there was much to be proud about.  On Monday there was nothing, on Friday we had all the parts for our proof of concept.  A few more hours this week to bring everything together and we’re done…for now.  Even with some hours being done this week the time it it took us to go from nothing to complete will be shorter.  The integration between the teams will only help future projects run smoother.  And who knows maybe the concept we had has some legs and takes off.

For those interested below is a rough breakdown of my observations and the project on a day-by-day basis:

Day One:
Ten or so developers and myself gathered together in the War Room where we apply some of the concepts from Todd Warfel’s talk at the last Refresh Philly meeting about Rapid Iterative Design to concept a new product for one of the CIM’s online properties (,,, etc).  We made some modificatoins to Todd’s methods, some by choice, others less intentionally.

Here’s how it worked for us.  Each of us made some quick sketches of our ideas, presented them to our group.  Then as a group took the strongest idea and refined it.  We then presented our group’s ideas/sketches to the other team, again picking the strongest couple of concepts.  Rather then choosing only one concept at this point we took the four strongest and did some quick sketches on how it could work and some of the UI.  Reconviened as a group to share the round of concepts and also discussed the technical logistics of each of the choosen concepts.  From there we voted on the one we wanted to work on for the rest of the week.  We did all of this before lunch.

After lunch we delved deeper into the tech that would be needed in order to make the concept a reality in 5 days.  We also discussed all the features we wanted in the final product and which ones could be done for the proof-of-concept by Friday EOD.

I can’t say it all went as smoothly as we’d hoped.  Some of the members only realized they were going to be apart of the experiment only moments before we first gathered and many of us already had projects lined up for the week. Keeping the concepting rounds within the time limits set or keeping everyone focused and in the present was difficult even when we had a moderator, when we lost the moderator it was nearly impossible.  Once we had the project basics figured out the reality of the work load crashed down hard on a few of the team members.  This only magnified the need for a moderator as they “checked out” of the process to focus on their work load.  We also lost a few members of the team to pre-scheduled meetings and other time sensitive projects.

Day Two:
We met in the War Room at 10am, giving everyone a bit of time in the morning to deal with their other responsibilities not connected with Lab Week.  We were now down to five.  Getting all five back into the “rapid” method was a complete no go.  After some group planning we decided to use a more refined data source then our ideal/concept’s provider could offer us.  The alternate source seemed to offset the tight deadline and reduced number of available developers. I had to step out for a bit due to another meeting myself, when I returned I learned we were guided back to the original concept’s data provider and instead they had chopped out some of the better/more original features of our product in order to make our deadline.  With this the stress levels peaked with fright as it was now mid-Tuesday and not a line of code had been written.  We spent the afternoon co-working, each on our respective parts.  By the end of the day we were down to three.

Day Three:
Same three initially, ultimately the same five.  At any given time at least one of us were pulled away.  Again, co-working with each working on their own parts while connecting with each other to answer questions, share findings and some random conversations.  Signs of our progress were beginning to show and some roadblocks cleared.  Friday was starting to look possible.

Day Four:
I spent the day focused on the other project I had on my plate.

Day Five:
I rejoined the Lab team.  Things looked promising.  Each had made progress and were almost ready to bring it all together.  Though much of the day there were only one or two of us in the room at a time.  Five o’clock arrived without the merger of all our work.

2 replies on “The Rapid Concepting/Development Experiment”

Hey Rob,

Good to hear you trying out this method. The need for a moderator is paramount, as you can see. Sorry to hear you had some rough time with getting participation, but I assure you after you’ve done it a few times it gets much easier to moderate the group and keep them going.

I’d love to know how things turn out from this method. Sounds like you made some progress and hopefully you can work it into a regular part of your design process.

Let me know if you need any help, assistance, or guidance/mentoring with it.

Thanks for the talk that inspired us to give this method a try. It really helped to get the project rolling, a concept formed and group participation. I think the benefits of this process were clear and with one under our belt it can only get better/smoother. Also, it’s my understanding that we’re plan on using it again for the next Lab Week.

Leave a Reply