Friday, March 26, 2010
Why Lab Week is So...Awesome

At work, once a quarter, we have "lab week": folks are allowed to form groups and work on self-directed projects. We usually finish up at the end of the week with a "science fair" where folks set up posters and demos of what they've worked on for the week (we even had cookies and lemonade at today's science fair!). I am always amazed at the amount of innovation and progress that comes out of these weeks; in some ways it outshines what our organization manages to do over the rest of the quarter. In this post I'd like to reflect a bit on what makes lab week so awesome.

Merit-based Project Ideas

Where we work, you have to actually recruit for lab week. This means you typically have to pitch your idea if you have one to enough people to get them to join your team. We actually set up special lunchtime meetings just for "Pitch Day". Ultimately this means that the projects that get worked on are the most innovative--because those are the most exciting ones and the easiest to recruit for. This is wisdom of the crowds at its finest; rather than having a select and small group of management identify a roadmap, it's a free-for-all where anyone can submit an idea and the best ones attract teams and get worked on. [Ed: this is not to say that management isn't needed to guide the execution and selection of ideas, just that they need not be the only source for idea generation]

Self-Selecting Teams

Again, due to the recruiting nature of lab week, groups are self-forming. As I think about it, it's amazing how well the group dynamics and team composition work out. I just re-read the section of Malcolm Gladwell's Tipping Point where he talks about Dunbar's number of 150: in a group smaller than that, you know your relationship to everyone as well as everyone's relationship to each other. In practice, this means when you are recruiting for lab week, you are consciously and unconsciously choosing folks that will bring the needed skills and experience to your project in a way that's compatible with the rest of the group.

When I look at it this way, it's not surprising that lab week teams gel very quickly and immediately start working together well. When you have responsibility for deciding who you work with, you end up wanting to work with your team. The group dynamics just sort themselves out effortlessly. Apparently Gore (makers of Gore-Tex) organize their high-tech development in this fashion.

Ownership and Buy-in

With a self-selected team and a self-selected project, folks on a lab week team are implicitly engaged in what they do, because it is their work. They own it, front to back, and pour their effort into it. You can see the pride in the demos, in the cute homemade posters (it does bear a striking resemblence to a stereotypical grade school science fair!).

On the well-known Gallup Q12 survey for how engaged your employees are, lab week covers: knowing what's expected of you (set by you!), having the needed raw supplies (often because the work is chosen with an eye to the possible), having an opportunity to do what you do best (self-selected projects), having your opinions count (recruiting, self-organizing teams), having dedicated teammates (self-selecting teams with ownership), having opportunities to learn (the whole point of lab week). That's six of the twelve right there. No wonder people willingly put in overtime on their lab week projects.

Timeboxed Exploration

Lab week lasts exactly a week. You don't have time to fully productionize what you do, and you have to focus. Ultimately this forces you to separate out all the chaff and focus on the real core of your idea and just deliver that, because that's all the time you have. This is the XP notion of Design Spikes, but in reality it's the Pareto Principle in full effect: do the 20% of the work that has the 80% impact.

Looked at it in another way, because the work effort is limited to a week, it is a way for the company to do rapid exploration with minimal risk or expense. I'd wager the company gets way more value in terms of idea creation during lab week than they miss out on from not doing "normal" work. It's clear the executives agree, because after each lab week, they agree to have the next one!

Thinking Outside the Box

Anything goes during lab week; this is a chance for folks to play with new technologies (it seems there is never a shortage of new technologies or of engineers who want to tinker with them) or practices. Our group used CRC Design Cards and did full-on TDD for our project, a first for many of us, and while I think we built a pretty cool project, the main benefit (echoed by group members) was what we learned about development this week. We ran a Cobertura report at the end of lab week and discovered we had 91% branch coverage in our code and an average cyclomatic complexity of 3 (without measuring during the week or even shooting for particular measures here). On a lab week project, no less. Wild.

In many cases, I think the science fair shouldn't be "What we built during lab week" so much as a presentation of "What we learned during lab week", which I suspect is actually the majority of the value offered to the company and the participants.

Permission to Experiment

Finally, it is clear that lab week is a no-pressure situation. There are no contracts to fulfill, no launch deadlines to meet (other than the science fair, I guess!), and you don't have to get approval from any more people than it takes to form a team. Almost anything goes (I have heard that underwater basketweaving is off limits, but not much else). If it doesn't work out, no problem, you go back to your "day job" next week, until the next lab week rolls around. There is nothing like this kind of no-risk environment (even the name "lab week" is suggestive) to foster creativity.

In Summary

Someone remarked at how much positive energy permeated the science fair. It was fun, and there were a lot of really cool ideas. People get into lab week where I work, and it makes the experience...awesome.

Friday, March 19, 2010
Agile Architecture Kanban

We've recently spun up a new software architecture group at work, and at least some of what the architects are expected to do is provide "consulting" services: providing feedback on technical designs and approaches, doing technical research, providing technical opinions to product managers, etc. Since many of these are similarly sized, and "cycle time" for getting a response to our clients is an important metric, we opted to manage this work using a kanban system.

After a month-long iteration, we stopped to take a look at some of the data we had collected. We were able to produce a statistical process control chart, indicating our cycle time in business days (measuring the time between when a customer asked for something to be added to our consulting backlog and the time when we finished it), something like this one:

This shows our average cycle time was around 6 days, and that our process was under statistical control; all samples were less than the upper control limit (red line) at 11 days (3 standard deviations above the average). This means that we had a relatively predictable process. Now, at the same time, we were able to produce a cumulative flow diagram, like this one:

which showed the number of consulting "stories" in each state of the workflow. One of the things we were able to derive is the average arrival rate for the stories, by finding the slope of the line between the starting and ending points on the "ready" line. We were also able to find our average throughput by finding the similar slope between the starting and ending points of the "done" line. What we found (and which you can see on the graph), was that the request rate was higher than our throughput (by about 0.2 stories per day), which resulted in a slowly but persistently growing backlog. Now, we happened to measure our average cycle time about halfway through the month, and found that it was 4.5 instead of 6 back then. In the ten business days between measurements, our average cycle time went up by around the amount our backlog length grew, as predicted by the difference between our customers' request rate and our service rate.

It would appear even architects are subject to queuing theory.

Going forward, in order to remain responsive to our clients (many of our engineering teams run two week sprints, so we wanted to shoot for an average cycle time of 3 days), we realized we were going to have to limit the size of our backlog. In other words, we were going to have to essentially issue a 503 (Temporarily Unavailable) response to some of our clients and simply not take their request onto our backlog and ask them to come back later, so as to remain responsive to our other customers. Just like we'd do in a web application server that was overloaded. Perhaps we'll even develop a cute picture of a flying acquatic mammal to try to soften the "not yets" we'll have to start handing out.