Plans vs. Zombies
Posted by Stuart Carmichael on Wednesday, December 14, 2011
Under: Curiosity
I've seen enough smart phone zombies squashed and irritable birds chucked to last me awhile. I carry a less-than-smart phone with its week-long battery life and lightening fast text messaging. Sure, each received e-mail message appears on my handset like some kind of lesser miracle. Like tuning in the local radio station using duct tape and a cinderblock.
But curiosity finally got the better of me, especially because a similar family of questions kept coming up at the engineering meetings I was in. Questions like, "how long will this take" or "what size of team of are you going to need" or "how long will you ramp-off".
These questions all sound like themes on the broader problem of "how much effort could get burnt given that team sizes vary with time?" If your team effort profile is shaped like a brick -- a team that immediately assembles itself to full-size, stays at full-size for the duration of the work, then instantly disbands -- then the math is pretty simple. Total effort divided by team size divided by effort per team member per day. But brick-shaped team rarely happen.
If the team assembles over time, peaks and then starts disbanding, that's a more complicated formula. Still, if you divide a brick profile by 0.6 or 0.7 you get an approximation of the project duration associated with a mountainous team effort profile.
These questions arose in realtime at meetings and the hunches could quickly set into concrete decisions. People would err on the side of caution or take actions to go away and model the team effort profiles. The problem seemed ripe for a smart device, in my case, a brand new iPod. I bought it specifically for this purpose. I wrote the app at home and started quietly using it in meetings and at my desk to model different ways teams assemble, peak and disband. As I hoped, it let me get a very good estimate for project duration, one that would be confirmed by more detailed planning. But with the app the answer is available in seconds instead of in hours, or even days.
It strives for simplity and to perform math that could be done on a paper napkin in less than a minute. The less magic the better because you have to convince others that the numbers are compelling and can be trusted. Plus, the app is so portable that it can come out and get used where ever these discussions arise whether it is hallways or boardrooms.
And that is how we've gotten to this point. Because now the app, to really be meaningful in my organization, needs to get shared around. And for that, I need the app store.
But curiosity finally got the better of me, especially because a similar family of questions kept coming up at the engineering meetings I was in. Questions like, "how long will this take" or "what size of team of are you going to need" or "how long will you ramp-off".
These questions all sound like themes on the broader problem of "how much effort could get burnt given that team sizes vary with time?" If your team effort profile is shaped like a brick -- a team that immediately assembles itself to full-size, stays at full-size for the duration of the work, then instantly disbands -- then the math is pretty simple. Total effort divided by team size divided by effort per team member per day. But brick-shaped team rarely happen.
If the team assembles over time, peaks and then starts disbanding, that's a more complicated formula. Still, if you divide a brick profile by 0.6 or 0.7 you get an approximation of the project duration associated with a mountainous team effort profile.
These questions arose in realtime at meetings and the hunches could quickly set into concrete decisions. People would err on the side of caution or take actions to go away and model the team effort profiles. The problem seemed ripe for a smart device, in my case, a brand new iPod. I bought it specifically for this purpose. I wrote the app at home and started quietly using it in meetings and at my desk to model different ways teams assemble, peak and disband. As I hoped, it let me get a very good estimate for project duration, one that would be confirmed by more detailed planning. But with the app the answer is available in seconds instead of in hours, or even days.
It strives for simplity and to perform math that could be done on a paper napkin in less than a minute. The less magic the better because you have to convince others that the numbers are compelling and can be trusted. Plus, the app is so portable that it can come out and get used where ever these discussions arise whether it is hallways or boardrooms.
And that is how we've gotten to this point. Because now the app, to really be meaningful in my organization, needs to get shared around. And for that, I need the app store.
In : Curiosity