Life in the Agile Lane

[jducoeur]

One reason I've mostly been fairly quiet lately is that my brain is being positively eaten by work. Being Product Manager is a whole new set of responsibilities to get used to. In particular, while I can traditionally leave my programming at work, and get away from it in the evenings, that's harder now -- a lot of my job is simply thinking about the product in the early mornings and late evenings, continuing to feel around the edges and try to figure out where it needs to go. On the one hand, it's a lot of fun, especially to the world-building side of my brain. OTOH, it's very distracting.

All that said, the shift to being a purer startup is proving excellent for my blood pressure. Yeah, we still have arguments, and they can still get pretty heated, but they're just plain more *manageable* at this size -- they're typically between two or three people, not a whole roomful who are factionalizing. And since the group is now made up more or less entirely of professional programmers, all of whom are decent at getting their egos out of the way, we're tending to resolve the arguments pretty quickly.

And as I'd hoped, we are finally doing something that's credibly Agile. We've dumped most of the tools we were using (including the execrable VersionOne), in favor of keeping track of things mostly on 4x6 index cards taped to the white board. The cost of this is that we lose some precision in keeping track of what's going on and where we're going -- OTOH, I'm not sure we're losing any *accuracy* in that process. Our schedule so far is mainly based on Onur's and my gut-feel about how long things ought to take to implement; so far, that gut-feel looks to be about as accurate as our old heavyweight processes were.

Perhaps most importantly, we don't know exactly what we're building yet, but that's really a feature as far as I'm concerned. Historically, we've tended to spend months agonizing over every detail, nailing down specs in one form or another, implementing to those specs -- and then finding that we were wrong in the first place. Instead, we're attacking the system on a story-by-story basis, making progress far more quickly, and I don't see any evidence that we're heading in any less correct a direction. Rather, I've been drilling home the mantra "Nothing Is Set In Stone". The odd advantage of knowing that we're out on the bleeding edge here, and are going to have to learn as we go, is that we're spending a lot less time making decisions: since every decision may change down the line, we're a lot more willing to try stuff out and see how it goes.

All of which boils down to: yeah, this is why I like working in startups. It's crazier and riskier, but man, it's a lot less soul-deadening.

As for what the product itself is -- I'll probably start talking about that soon. We're not really in stealth mode this time, having decided that that's really not very helpful, but we want to get a little further along before we start shouting it to the rooftops. Basically, we're combining a number of fairly conventional ideas about communication and conversation, stirring in a bunch of little elements that really *ought* to be common but for some reason aren't, and baking it all together into a communications tool that's just plain more *useful* than any other single product out there. If I'm right about this, we'll wind up with a feature set that everyone else will then trip all over themselves trying to copy, and we'll be off to the races...

Comments

[laurion]

Very cool. Always good to hear that someone is enjoying their job, for a change.

[umbran.livejournal.com]

Our schedule so far is mainly based on Onur's and my gut-feel about how long things ought to take to implement; so far, that gut-feel looks to be about as accurate as our old heavyweight processes were.

May I recommend Planning Poker? Physical decks are avaialable from Crisp, and an online version is also available from planningpoker.com.

I've just completed Scrum Master training with Jeff Sutherland. Mayhaps we should arrange a meeting of minds.

[umbran.livejournal.com]

Sorry, a link above was b0rken.
Physical decks are available from Crisp

[jducoeur]

[Caveat: the original note was mainly talking about long-term schedule, rather than short-term, which affects the below comments. For the short term, we're currently just doing a pure story-oriented model, and only worrying slightly about formal costing. We can get away with that mainly due to the nature of the team, since everyone has a fairly good gestalt understanding of task costs. We're still experimenting with this, though.]

Oh, we've got Planning Poker decks -- indeed, we'd put together some homebrew decks before we got our hands on enough of the Official and Pretty ones. In the Relay period (when we were vaguely Agile but still very heavyweight) we used them quite a bit.

But they're of limited utility for serious long-term scheduling and costing, I've found. Planning Poker tends to introduce a bunch of biases into the data, and moreover tends to magnify them as you add things up. Those can *eventually* be accounted for, but it takes a lot of data and experience to do so accurately. Moreover, it's worse for long-term, large-scale planning, because you wind up simply missing more large tasks, adding to the errors.

For small-scale use, Planning Poker is quite useful, and we've used it moderately often. When trying to understand what's likely to happen in the single iteration, in particular, it's a good way to go. We haven't been bothering recently, but that's mostly because we haven't particularly needed that level of insight. I expect it'll come back eventually.

But for large-scale, where you're juggling many dozens of stories and very rough estimates, it's important not to fool yourself into believing the numbers too much. That "gut feel" actually was loosely based on a very rough planning poker session, but was then heavily adjusted and grouped by the two of us into big crude buckets. Those buckets were informed by the poker game, but we're pretty clear that at that level it really amounts to guesswork -- we just don't know enough about the future direction to speak with great confidence. Which is fine by me: I've never seen any project that *actually* did much better than educated guesswork when talking about the 2-6 month timescale. Most just paper over their lack of accuracy with a lot of precision, so they can pretend that they really understand their schedules...

[umbran.livejournal.com]

But they're of limited utility for serious long-term scheduling and costing, I've found.

Yeah, well, given that the whole point of being Agile is that the long-term schedule is flexible, this should not be a major cause of concern. You are not supposed to expect that Product Owner will hold the same priorities in the long term, so the details of the long-term schedule are supposed to be vague.

That was a major point in the training - it feels like a loss of control, but it is actually merely a shifting of the control handle.

[jducoeur]

Yaas, and as (essentially) the Product Owner that works fine for me. As far as I'm concerned, the focus is entirely on "get something useful as soon as we can", and I prefer being able to reorder the stories pretty fluidly. (As it is, I'm coming to suspect that some features that we had seen as critical as little as two weeks ago aren't really all that central.)

But we have to tell something to the investors, so that they feel that they're going to make their money back -- the developers may all have signed on to an Agile approach, but the Board of Directors hasn't. Hence the guesswork of a long-term vision and schedule, so that they can have a clearer sense that it's all going somewhere. And so far, that guess is looking reasonably on-track, at least from the thousand-foot view...

[umbran.livejournal.com]

But we have to tell something to the investors, so that they feel that they're going to make their money back -- the developers may all have signed on to an Agile approach, but the Board of Directors hasn't.

Hm. If that's how they feel, there's a really simple way for them to get their money back. Next time there's a meeting, surreptitiously leave a copy of The Toyota Way in their briefcases. The 14 Principles therein are what brought Toyota to lean manufacturing, which is the moral equivalent of software's "Agile".

If they don't understand that they want to use the same basic ideas that brought the Toyota Prius into existence in 15 months, rather than 4 years, they need education.

[jducoeur]

It's not that they're hostile to us doing Agile: they simply aren't tied enough into the process to be *part* of it. It's hard to really be part of an Agile process when you're only involved once every month or two. Remember, we're talking about the Board here, not managers -- it's a very different kind of beast, with a very different kind of involvement. (This is very normal, especially for the Board of a small company: it's not even remotely a full-time involvement.) The current story stack isn't very helpful when you've only got two hours to describe what the next six months are going to look like.

And honestly, the Toyota principles are a little too simple in this case. In their case, they at least have a reasonably good consensus idea of *what* they are building -- they may not agree about all details, but they all know what a car is. You don't quite have that luxury in this world. We have to balance the need for a clear vision of where we *think* we're going (so that we don't thrash), with the very real possibility that reality may take us in a very different direction (if the market pulls us that way). Even Toyota's Board would be nervous if there was a possibility that their project to build the next Camry might find itself building speedboats instead. Owning an evolutionary process is rather different from owning a revolutionary one -- in particular, the communication needs are different.

In other words, the Toyota principles are mainly about how to get there, and they're generally sensible for that. But they kind of assume that everyone shares a 95% common understanding and agreement of what you're building, not 30%. In our environment, simply getting to the point of understanding roughly what you think you're building and vaguely how long it's going to take is much of the communications challenge. And they have a fiduciary duty to their own stockholders to have *some* idea of where we're going to be in six months and in a year, so that they can honestly say that they have faith in the corporate direction. So it's quite reasonable to expect us to produce some guidance about that.

(And keep in mind, most of the Agile wisdom comes from single projects inside much larger institutions. The stakes are just plain different when the Agile project is the entire company -- it means that the project must interact directly with the finance side of things, and that's a *very* different world...)

[umbran.livejournal.com]

It's not that they're hostile to us doing Agile: they simply aren't tied enough into the process to be *part* of it. It's hard to really be part of an Agile process when you're only involved once every month or two. Remember, we're talking about the Board here, not managers

Yes, that's rather the point - they aren't supposed to be that deeply part of the process. That isn't their role. They need to internalize the fact that the point is not to deliver something of a pre-specified shape, but to deliver what the customer wants.

As to the "single projects inside larger institutions" - methinks that is rather out of date now.. Yahoo has 150 scrum teams. Google Adwords was built using Agile processes. Japanese car makers continue to whoop our butts using lean processes. There are VC firms out there who now won't invest in a startup unless they doing Agile.

[jducoeur]

As to the "single projects inside larger institutions" - methinks that is rather out of date now

Not what I meant -- or really, it emphasizes what I meant. I was referring to the fact that each team is typically a modest component of a much larger whole. Yahoo having 150 teams is *very* different from a company that has only *one* team, which is the entire company. It means that our Board is directly interested in the product in a way that Yahoo's mostly wouldn't be...

[jducoeur]

Another note or two:

Our process is pretty heavily influenced by Mike Cohn's book on story-writing, which I commend to you if you haven't already read it. It does a lovely job of being both concise and cogent, and it's more or less been our bible since we started on Agile six months or so ago. We don't follow it completely faithfully, but we try to keep it in mind while we're working.

And yes, I'd be happy to get together and chat sometime. I suspect our approaches are pretty different due to different circumstances, but it would be worthwhile to trade ups and downs. (Heaven knows I have some horror stories to tell, and one or two specific software disrecommendations...)