The 4th State of Agile (and seeing Eric Ries in Sydney)

by Giff on March 29, 2010

ericries-sydney

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.

sectionbreaker

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.

Share and Enjoy:
  • Twitter
  • Facebook
  • HackerNews
  • FriendFeed
  • Google Bookmarks
  • LinkedIn
  • Suggest to Techmeme via Twitter
  • del.icio.us
  • StumbleUpon
  • Digg

Tagged as: , , ,

  • http://twitter.com/poinky Poinky Malaprop

    As Eric mentioned, the three states of a story are actually planned, in progress, and done. “code, test, integrate” all happens inside the in-progress state (and not necessarily in that order).
    What Eric seemed to be suggesting is to make the development team responsible for evaluating the business value of a story (or feature), rather than just implementing it. He suggests this involved additional work, like A/B testing.
    This seems risky to me, since it lets the developer decide the method of validation, “I showed it to my friends, and they liked it!” I think the product owner should instead work with the development team to define a better story that actually gives them what they want. If you want to find out whether a feature is useful, then make the evaluation a story, and work with the team to come up with the best way to perform the evaluation. Maybe it's implementing and releasing it, maybe its doing a paper-based prototype, or maybe it's some other mechanism. The important thing is to be explicit about what the dev team should be work on to deliver the most value.

  • http://twitter.com/jeffreyfohl Jeff Fohl

    Interesting idea. Thanks for sharing Giff. We are starting to implement Agile where I work, and are still working out the kinks. We are a really small team – just 4 developers, of which I am one. The only problem I see with this is (assuming I understand this correctly) is that in order to get validation, the engineer has to wait for the customer to give feedback, essentially making the customer a part of the Agile process. The only problem is, it is tough to get customers to buy in to the Agile contract. Customers are not likely to feel the pressure to give feedback in a timely manner, thus forcing the engineer to sit on her hands waiting for validation.

    At the moment, I have a feature that I rolled out to a customer about 2 months ago, and I am still waiting for them to give the thumbs up on it. Obviously, I had to move on to other features, but if they come back to me later with modifications, I will have to interrupt my current story and get back to them.

    Of course, my situation is perhaps a bit unusual, since where I work we are a blend of professional services and a software product company.

    All that being said, I very much support the idea of getting everyone in the company on board with overall goals, and getting people at all levels tuned into what the customer's needs are.

  • http://giffconstable.com giffc

    Thanks Poinky (and nice to hear from you) – I'll make that correction in the text. I don't see quite the risks you do, because just as the feature is planned with both business and technical minds collaborating, so should validation. While I'm a huge proponent of talking to customers, paper-testing, etc, I also believe that you never quite know until people *use* something. I think that putting weight into what happens *after* release, is great, and I like the fact that the dev team isn't allowed to go charging onwards with more features until validation is done. It constrains a huge mistake tons of startups make.

  • http://giffconstable.com giffc

    I haven't thought it through from an enterprise software perspective, because my brain is in the consumer world these days. With consumer software, you can immediately begin measuring things. However, if you decide that there is sense in the notion that more features != better, then if it takes 2 months for someone to notice a feature, then unless it's custom software or something that literally only gets triggered, say, once a quarter, then you might ask why you have the feature at all. Some people are actually removing features / turning them off to see if people scream, and if no one does, then it's arguably a superfluous feature.

  • http://twitter.com/poinky Poinky Malaprop

    If everyone is clear what validation means, then that is great. Then you can just make that an additional story and manage it with the rest of the backlog to make sure it happens.

  • http://giffconstable.com giffc

    fair enough. I just like the psychology of freezing the stories in play, rather than having additional stories related to validation, because it makes it obvious to everyone (including the feature-obsessed salesperson/marketer) what is really going on. And in startups, the psychology of the team is a huge thing.

  • http://www.pollenizer.com/ Mick Liubinskas

    Nice post Giff. Glad you could make it on the night.

    I agree re: the Sydney community and capital – but hopefully there is some good news coming soon.

  • http://giffconstable.com giffc

    Nice to hear from you Mick, and I hope your startup is going well!

  • http://twitter.com/liscrawford Liz Crawford

    A/B testing can take time. The dev team may have to wait a few days to collect the desired amount of data. So regardless of whether the story is freezed or a new story is added to the backlog, the dev team would have to get used to the discipline of returning to the feature in a timely manner, deciding if it should be worked on further, pushed to all users, or canceled.

  • http://giffconstable.com giffc

    right. we'd have to think through process issues. Would this apply to just user facing features? every story? how to keep from being too inefficient? how to prevent it from stalling out team? But I like the concept in terms of added discipline to process both at the top of the dev funnel and during.