Kevin P. Taylor

The Coin Flip Game

We enjoyed an opportunity to hang out with Jeff Patton in the Obtiva office for a few days recently. He was pairing with Dave on Mad Mimi most of that time. But, we all know that all work and no play makes <fill in name> a dull boy, so being geeks, we took a break to play a new game that Jeff suggested.

The Coin Flip Game (my name) demonstrates the efficiencies gained in a Lean/Agile production environment when compared to waterfall environments. The concepts this game demonstrates are explained by the Theory of Constraints and optimal work queue sizing. The idea is to deliver several coin flipping "projects." The first project is waterfall-style with Requirements, Design, Implementation, Verification, and  Maintenance phases. Running the waterfall project will give us a baseline process cycle time, or the time it takes to send a given batch of work through the process from start to finish.

To run the waterfall project, start by creating stations at a table for each of the 5 waterfall phases. Have one person man each station. Line up 10 coins at the Requirements station, all facing heads up. Start a timer. Each station must flip all 10 coins. Once all the coins are flipped, the coins are pushed to the next station. Each station flips and pushes. Once the last station has received and flipped all the coins, the timer stops. Record the time taken as the process cycle time.

For the Agile project, set up the coins and stations exactly as above. This time, though, each person flips and pushes the coins in units of 5 instead of 10. Again, time the result.

Run another Agile project, but with 2 coins being flipped and pushed at a time, and, finally, with only 1 coin at a time.

The theory is that reducing the size and increasing the frequency of the work unit batches being pushed through the stations should increase the overall efficiency of the entire process. Playing the game demonstrates that process cycle time is directly related to batch size but inversely related to batch frequency. If each station receives smaller and more predictable work batches into their queue, it should be easier to manage, and there should be less time spent on low value activities while waiting for another large batch of work to hit the queue.

We took 26.2 seconds to deliver our coins via waterfall. The last Agile project we delivered had 1 coin iterations and was delivered in only 13.1 seconds.

Adding Tasks to Google Apps

One piece of functionality that is painfully missing from Google Apps is task tracking and sharing. Fortunately, Remember the Milk provides straightforward task tracking and sharing and it has seamless integration with Google Calendar.

According to their site, they have both a free and a paid premium plan. I am trying out the free plan now to see how stable it is. My main concern will be that the service has minimal downtime during business hours and low latency.

One very nice feature is the email integration. Each user is given a custom email "inbox". You can create new tasks by sending an email to your inbox. Better, you can use codes at the beginning of the email body to set attributes on the task.

For instance, you could send an email to your task inbox with the following email subject line and codes in the email body:

Subject: Friday's Task
L: Obtiva
P: 2
E: 1 hour
D: Friday
---
This is a note for my Friday task.

This creates a task named "Friday's Task", adds it to the Obtiva task list, gives it a medium priority (2), an estimate of 1 hour, and a due date of Friday. Also, there is a note attached to the task, "This is a note for my Friday task."

Evolving the Simplest Tools that Will Work

Our company, Obtiva, is an Agile software development company. But, Agile principles permeate all aspects of Obtiva and go well beyond our software projects. We are an Agile Business. As such, one of the core Agile values that we strive for in our business operations is simplicity.

Simplicity manifests itself in many forms during our daily routines while running business operations. The use of lightweight tools is one obvious example. For instance, we leverage Google Apps extensively for email, collaborative documents, and a shared calendar. In most cases, a new business tool begins life as a Google spreadsheet.

Over time (days or months) those spreadsheets and shared documents become less and less effective. The spreadsheet may have only been conceived of as a business logic prototype. Or, a particularly useful spreadsheet may offer significant business value, and the promise of much greater value, if it only had x (feel free to name x).

At this point, we have a choice: invest time and money in an off-the-shelf tool that we can customize to some extent or build our own one-size-fits-one tool. Using Ruby on Rails and other lightweight technologies, we are surprisingly often able to spend only hours to convert a spreadsheet into a Web-based business application.

Even better, our one-size-fits-one applications start life with only the smallest kernel of high priority features, maximizing ROI. Over time, we can continue to add features, of course, as our business needs evolve. We are not locked into any particular vendor's feature set (not enough, too many, or the wrong mix) nor are we at their mercy for bug fixes or upgrades.

First, view you initial application needs through a minimalist's eyes (What is the simplest thing that will work?). Second, leverage the flexibility and productivity of tools like Google Apps, Ruby and Ruby on Rails to deliver just the right level of functionality vs cost.