In mid-February I and the family flew down to Sydney to see my in-laws, and I was happy to overlap with Eric Ries at the Sydney Lean Startup Circle. Eric delivered a great talk, but I gave him a hard time afterward because he spent a chunk of time on continuous deployment. I consider that to be low priority compared to make-or-break tasks like testing hypotheses and finding product-market fit. I understand that Eric wanted to have something in his talk that was specifically aimed at the engineers in the room, but for that purpose I actually got more excited when, a few weeks later, he went on a tangent during his DC lean startup talk with Dave McClure.
Adding a 4th State to Agile
Eric’s concept was to add a 4th state to agile programming (his original 3 states being backlog, in progress and done). For every story, you might write code, implement unit tests, and then integrate it into the main code base. Eric suggested that the process needed a 4th requirement: validation. The essential kicker is this: the engineering team cannot start a new story until that validation was done. Non-coder I may be, but I love this concept.
* I think it will pull engineers closer to the business / customer.
* I think it will force an entire company to focus on metrics and measurement, rather than just talk about it.
* I also think it will get the “business” team off of the usual drumbeat of “more features, more features” as the holy savior for the company’s problems.
Edit: Eric goes into more detail in his interview with Robert Scoble. Check out the very end of video 1 and beginning of video 2 here. (DC video where he discusses this is here, around minute 46:30)
At Aprizi, we’re not going to implement this just yet since we’re *so* early stage, but I look forward to working this into our processes soon and giving it a shot. Note: I think you have to have the CEO’s complete buy-in to have any chance of pulling it off.
Addition: Poinky Malaprop commented below that you can treat the validation step as another story, but I thought it worth highlighting in the post itself that it is specifically the *freeze* that impresses me so much in this idea. If validation is just another story in the backlog, it will be easy to shunt aside or deprioritize, especially in the minds of folks outside of the dev team. By having a freeze until validation is done, it makes everyone think twice before even *adding* a feature to the roadmap, and it makes sure that validation actually happens. There may be exceptions and compromises needed, but I can’t wait to try this out.
P.S. on the Sydney Startup Scene
I met some bright entrepreneurs at the event and asked about the local scene. My completely unscientific takeaways were that Sydney is not unlike many US cities trying to become tech hubs. It has a small but decent community; it is weak on seed capital; it suffers from mixed cultural attitudes towards startups and failure. Its strengths are great engineering talent and being a city lots of people want to live in. Its huge weakness is being so far away from large markets and partners. There is a lot of activity in mobile, and strong interest in local/SMB. You see the same dynamic in Sydney that you get in a lot of US cities where a startup gets going, builds some decent traction, and then moves to Silicon Valley to try to raise money and go big.