I’ve got good news, and bad –
Bad news: we didn’t capture the audio when we recorded this recap.
Good news: you get to hear my (almost) spot-on impression of Aaron.
Today’s recap is all about where we derived our requirements for this version of OnCompare. Like any good lean startup, we’ve derived our requirements straight from our hypotheses. We have ideas on how we can:
- Incorporate marketing into the product
- Create a defensible business
- Provide useful recommendations
but we won’t know until we test them. That’s what these three weeks are all about.
Aaron also described how we approached assigning work across the team and how that quickly evolved. We started by assigning core components of the project to each engineer but quickly realized that wasn’t going to work:
- The core components were vague and writing up huge specs to define them isn’t a good use of our time.
- The core components were vastly different in size & scope, meaning we could easily create an imbalance in workloads.
- Vague tasks invite scope creep – public enemy #1 of this project.
Instead we focused on “stories”, identifying bite-sized chunks of user-oriented functionality that devs would self-assign. This model:
- More efficently distributes the workload
- Promotes communication, collaboration & integration (since you’ll often be working on two different components in the same day)
- Encourages cross-pollination of knowledge
- Builds in “backup” devs for all components. If someone hops off the project, there’s little chance his work will have been silo’d – someone will have enough knowledge to carry the torch in his stead.
There you have it – that’s recap #2!
Whatcha think? What problems are we going to run into with this model? What would you, or have you done in similar circumstances?
It’s not too late for us to change!