An interesting take on Agile project management

Just yesterday I ran into a friend and former coworker while getting a mid-day coffee. He's the product owner for a project at another local tech firm. With him was the dev manager for the product. The conversation turned towards upcoming product releases (we both have one in less than a month) and agile development. They were recently a Scrum shop, but have switched to XP because of the testing lag problem that I now believe is inherent to most Scrum projects.

But that wasn't the interesting part. The interesting part is that as a condition of taking this job he demanded to be QA manager first, then added the dev manager role. Brilliant! Our parallel product team coming online with agile is suffering the same issue with regards to test that we have. Namely, the QA manager refuses to buy in and commit any resources at the beginning of development. Or when he does it is only for a short period, then that resource is retasked to pick up every piddly little project that comes along, essentially not being part of the team. Rolling the QA manager role into the dev manager role, while smacking of dictatorship, will remove that main impediment (in my experience) to fully integrating dev and test.

Patience

is not one of my strong suits. While I was bloviating about how the new team was doing development as usual, they were working themselves up to pick tasks and start a sprint. Go team - you self-organized. Maybe my lack of patience is why our team still stumbles a little in the self-organization realm.

The difference between Desire and Belief

In trying to bring our second team online with Scrum, I've hit an unexpected road block. In retrospect it should have been expected, but 20/20 hindsight, etc. Previously I'd mentioned how it was refreshing at Agile 2006 that there were so many pragmatic people and fewer "true believers" than I would have thought. That's a good thing for the state of the art, but not necessarily good for a day to day rollout.

On the other team is a peer team lead that also desires to move to Scrum. He was one of my early allies in getting the first team online and making sure the effort wasn't squashed from above. Now, trying to bring his team over to Scrum, I've realized that he doesn't fully believe. Let me say that again. He desires to move his team to an agile development model, but he doesn't yet believe it is the best way to deliver the product. Without that belief in success, the desire simply sits there, unfulfilled.

We did do the first release planning and initial backlog prioritization, but they (as a development team) have as yet been unwilling to take the time to plan their first sprint (iteration). At best, the devs see this as a new organizational idiosyncraticy to be tolerated, at worst they don't buy in and view it as a top-down edict that will hamper their work. Ironic, given that it started on our team as a bottom-up effort. They're also forgetting what an unmitigated disaster their last product release was - months late, feature poor, and of such crummy quality that an additional four month on-site development effort was needed to stabilize the product. The former head of product development was fired, we almost lost our largest customer, a multi-million dollar contract, and at best the product simply limps along.

Which brings me back to an earlier post - Alway Be Selling. And sell the rank and file before you bother with the top.

One winds down, One winds up

We're almost to ship! The pilot agile project has just passed it's feature complete stage. Yes, not "technically" correct for scrum, but required based on external realities. Essentially we'll be doing a normal test cycle a-la waterfall. Interestingly enough, a classic test phase is very agile. We do weekly or bi-weekly drops to test (weekly sprint), run off a single, prioritized bug list (backlog) that is always being reprioritized in triage (sprint planning meeting). Bugs (stories) are worked to completion or they have no business value.

On the wind-up side, our next agile product team just did the kick-off meeting. I helped facilitate since we haven't been able to jump thru all the hoops to hire an on-site coach yet. Boy I wish I had some budget authority. Unlike our first agile project, which started half way through the cycle, with this one they have a reasonable backlog. We just did the planning poker game using Mike Cohn's estimation cards (http://www.mountaingoatsoftware.com).

The planning was actually fairly smooth. There was a little back and forth. And interestingly a few items where bids ranged from 1 to 13 (cards use Fibonacci numbers, if you're not familiar with them) and represent Story Points, although I like the idea that they represent Poptart Points and on our next release we'll bid things in Watermelon Points. The estimation is actually very quick doing this instead of ideal days. People don't get so hung up on actual time or feel they're giving a delivery commitment, so the answers seemed more honest. And estimates story point estimates, since they give relative complexity, will continue to be accuratish even if five of our one point stories each take 10 days to complete (just means we'll ship some time in 2008).

Next week we'll do the first sprint planning meeting for them. Stay tuned.