WatTF? - Jim Murphy

Thanks to the Waterloo Agile/Lean Peer2Peer group for inviting me to speak in December.  This presentation was intended to introduce the group to the concepts of LeanStartups and how it can put agile in context for start ups.

You often hear people focusing on the internal parts of agile.  Often these are the things the scrum master is supposed to facilitate during a sprint like daily stand-up etiquette, burn down charts, planning poker, retrospective games etc.  These are all useful tools but ignore the elephant in the room if you happen to be a startup: how to you build the backlog?

Even more, how do you build a backlog that will define and evolve a sustaining product in a profitable market before you run out of cash?!  That, my friends is the primary challenge of a startup and so many of the rituals of agile development alone wont hep you with.   I don’t intend to diminish the value of something I’ve spent the last decade learning and practicing, but in the last few years I’ve learned where it belongs relative to other important factors that can’t be ignored. If you’ve ever been the Product Owner I’m sure you’ll agree that it take a hell of a lot of effort to build and maintain a backlog including the efforts of many people.

There has been little in the way of process to address this fundamental challenge in a way that was as compatible with the style of agile development - at least until lately.  This is why LeanStartups and Customer Development resonated so strongly for me.

You read this all the time online - people complaining that their team is doing some weird variant of agile and even that it failed because they didn’t find the mythical “true agile” way.  Add to that the fact that being developers we tend to see things, how shall I say, a little more black and white than most.

Don’t worry about “not doing it right” and instead focus on how you are improving.  Where were you int he past and where are you now? What’s next?  Focus on that.  Too many times people assume that because their agile adoption is imperfect they are missing some critical part or have generally failed.  You may be right!  But, it doesn’t really matter.  In my experience you shouldn’t wait around for the perfect process/team/org adoption to arrive.  Just keep moving and keep improving.  Plan on team cohesion around a workable process taking a year or so.  Most of that year will seem pretty wonky but go with it and don’t fret.  Don’t sweat the fact that after 6 month your velocity is still erratic, or your stories are too open ended, or your product owner doesn’t have a vision (introduce them to Customer Development!), or that you can’t keep your standups focused, or that you don’t pair enough, or that storypoints don’t map to reality, or that you have too many bugs that they trow off your planning, or that you can’t really ship every iteration, or that you can’t test enough, or that you test too much, or…

Take a breath and keep going.

Just another day at the office. Out for lunch, walking to Mai-Thai if memory serves and what would you guess we see coming down King street in Waterloo?  The Google Steetview Car.  I’m sure plenty of folks were wondering what the heck this contraption was but not the dev team at PostRank, no sirree.  We new our moment of geek glory was upon us.  Even the Canadian paper of record shared in our gloriousity.

Is your dev team immortalized on streetview?  I think not!

The funniest thing about agile is how common the problems people have doing it.  Case and point:

He who seeks truth shall find beauty.
He who seeks beauty shall find vanity.
He who seeks order shall find gratification.
He who seeks gratification shall be disappointed.
He who considers himself the servant of his fellow beings shall find the joy of self expression.
He who seeks self expression shall fall into the pit of arrogance.
Arrogance is incompatible with nature.
Through nature, the nature of the universe and the nature of man, we shall seek truth.
If we seek truth we shall find beauty.

-Moshe Safdi

This poem is at the end of the Moshe Safdi’s TED talk video on his approach to architecture over his career.  It stuck in my head ever since.

Rick Segal mentioned his approach to the ailing Canadian venture industry and to the lack of local experienced operators: The Farm Team.  This was in response to some controversial (if mostly damn true) conversations that are all too well known at this point.

I think Rick’s fundamentals are right but the mechanism is wrong.  Scrape together a few bucks to squander on training is a cynics take.   To me what I noticed immediately after moving back to Canada is simply the lack of game.  We don’t need special consideration we need more action. Problem is to get more action you need more VCs playing and more LPs willing to invest.    For cultural, population and scale reasons Canada can’t rely completely on domestic investment - and shouldn’t want to either.  It especially shouldn’t wait around for a few tens of millions to be handed down from the government in ham handed way as the primary LPs to local VC.  Completely wrong headed as well.

What Canada needs more than anything is more capital to work with.  We’re a resource rich country - in more ways than minerals and lumber.  I mean in skilled and talented people.  To scale and deepen the level of skill and experience you need to do it.  You do it by funding more companies and iterating more often.  We don’t have enough oxygen in Canada to do this and will always be chronically underfunding this critical emerging part of our economy.

Stephen Hurwitz recently articulated this much better than I and to a level of detail I’ve been craving ever since moving back from Boston and wondering what the hell was going on with Section 116.  His article titled: Reforming Section 116 – Key to Opening Canadian Borders to Foreign Venture Capital lays out the case:

The notion that Canada makes it simple for investment to flow outward but not encourage the other direction is in my opinion the single largest problem facing Canadian start-up founders (or would-be founders that fail to find investment).

By simply alleviating the administrivia surrounding this issue we can unlock the potential of billions of dollars of investment that is otherwise squandered or leaves for other more favorable places.  In this area I know of what a speak.  I’ve made that choice and met tons of fellow Canadians that did as well.

I’d place  abet that Section 116 is not a rational, thought out position with a purpose but rather a sloppy oversight that has yet to be corrected by people with interests in seeing entrepreneurs flourish in Canada.   If there was one thing we could do, wave a wand and change a single thing this would get my vote.

Steve Blank from Berkley’s Haas School has a great reminder about the (anti) correlation between good grades in school and success in entrepreneurship.  He remarks in The “Good” Student something I’ve been curious about for a while too: Google’s Hiring Practices.  Talking with bright co-ops and new grads and grad students at the University of Waterloo, Google is often lauded as the obvious first choice spot to land a job.  In fact Google often poaches the top talent - measured in terms of grades at least.  I’m always surprised to hear how uniform their hiring profile is, at least for engineers: bookish engineers without much life experience.  Probably too harsh but I liked Steve’s characterization.

Andre Kaminski quotes Barbara Nelson’s The Politics of Agile, “When product managers weren’t looking, the developers went agile.”  in a new post up at Pragmatic Marketing called “The Mythical Product Owner“.  Its great to see these two worlds combine.  The sum of the parts is a much greater help to companies wrestling with not only how to build products but what to build and for who.

Fitting tactical level thinking (where agile excels) into a compatible strategic framework is a powerful combination.  I’m not sure of the distinction between the Product Manager Role and the traditional Product Owner as drawn.  It appears that the Product Manager is defined to be more strategic and have more market orientation.  I’m not sure I buy the separation in my world where companies are small and people are stretched thin but I can see it in larger orgs.  I wonder abotu it because the Prouct Owner stops being the “owner” of anything and really just a middle manager of sorts with dubious authority.  In my experience the way for developers to have confidence in a backlog is to have them build it or have market data.  Not sure I’d want that Product Owner job.

I’ve spent a lot of time making agile development work in startups and it ain’t easy.  Necessary but not easy.  Agile has always felt natural to me - from a cultural point of view that when I read about Kent Beck and XP it was exciting to see some substance forming around this approach in contrast to more prevalent and much heavier methodologies.

I liked XP as an engineer but from the business side of things found that it was limited to encouraging good engineering practices but not much else.  That’s when I learned about SCRUM - the agile methodology that adds the project management rituals that are compatible with the engineering practices of XP.  Great, I figured,  now I can really build cool products! Er…maybe.

Scrum is the way we run the AideRSS engineering group its what I’ve used at Mindreef and previously as well.  But, over the years I’ve realized that the toughest problem - the one that matters most and was consistently the most challenging - was figuring out what the product backlog should be.

The backlog is the answer to the question: “What is the most important work we should do right now?” it presumes that you could confidently make that list, and keep it up to date as things change - or at least articulate what you’re building and for whom.  Embedded in that assumption is why startups fail.  How do you really make the best backlog for your company?

XP and Scrum don’t have much to say - they punt.  Its by far the hardest part of the puzzle of shipping successful products and both recommend that you get a customer in the room and ask them to clarify what they want as you go.  Well, that’s fine as far as it goes but when you’re a startup and you don’t have customers yet you need a way to bootstrap and that can feel awfully chaotic and wasteful. What’s worse is that as you grow you’ve probably developed some pretty bad habits as far as setting priorities and strategy: like thinking you’re a genius - just because you got funded - and that genius is what allows you to *know* what the market wants.

Product Management is the generally accepted answer to the question above and though I love the folks at Pragmatic Marketing for their excellent offerings in this area, product management isn’t all that well connected to agile development, especially in a startup.

I recently listened to the VentureHacks podcast of Steve Blank’s talks at Stanford on the topic of “Customer Development”.  A blog post: “How to develop your customers the way you develop your product” links to resources that describe the idea.  Wrapping the iterative nature of agile development in another outer loop called Customer Development makes a ton of sense to me.  Its the first time I’ve seen an approach to the Market/Product fit problem that makes sense the same way agile makes sense to software developers.  I’m looking forward to digging into this some more and applying it to how we evolve at AideRSS.

Oh, some guy called Marc Andreessen things Steve’s book is nifty too.

I’m really surprised by the blasé attitude of people I speak with and reporting in the Canadian media about the global financial crisis.  It seems many feel that this happens from time to time and doesn’t really affect them.

Banks

Autos