Tuesday, November 23, 2010

Neither, I mean a North American Thanksgiving turkey. And no, this is not some kind of cheesy Python-esque skit. Rather, as my favorite US holiday approaches, a particular truism of turkey roasting occurred to me: your 12-16lbs bird will need about 15 minutes per pound at 325F until it reaches an internal temperature of 160-170F.

So that, I would say is the velocity of a turkey – 15 minutes per pound. And the internal temperature is your “acceptance criteria” since I’m doing dubious cookery/scrum metaphors.

Just like a scrum team’s velocity is what it is, the same is true of our turkey. You can try and "turn up the heat" to get it done quicker, but in reality the results will suck. Your end result will be all dry (for the turkey) and the product flaky (for your scrum software team).

So, to get good results, work with the reality of the situation. Plan based upon your known velocity. If you want 100 points worth of features implemented, and your team’s velocity is 25 points a sprint, reckon on it taking around 4 sprints. If your family is hoping to sit down and feast at 1pm get that 12lbs turkey in the oven with enough time for it to cook and rest afterwards. You just can’t rush it. If you have other features you want within the next 4 sprints you are going to have to make some hard choices about what you drop from your current plans. You simply can’t have it all. Similarly, if there are other things you need the oven for, plan accordingly. You can’t fit everything in there with the turkey all at once.

As much as scrum is about prioritization, it’s also about accepting the reality of what your velocity tells you can be realistically done, and working with that. That means good planning, and sometimes hard choices.

Wednesday, November 3, 2010

I'm just about to finish sprint four as the Scrum Master for a team that has a higher than average number of distributed members. And I don’t just mean that we got two offices involved, one in the US and one in Europe or India. We have three software engineers spread around the Denver Metro area, all working from their individual homes. Then we have our Product Owner in Billerica, MA. Alongside her are a couple of QA engineers. Then we have some folks over in Hyderabad, India: another software engineer and a couple more QA engineers. Finally we have me, working out of my home in the Rocky Mountains above Denver, CO. That’s six locations for just ten team members.

Add in some interested stakeholders in Berlin alongside those in the US and India and you can see what we’re up against. I’m sure we’re not alone in such a setup, but I suspect that having a number of people, including the scrum master, “decentralized” (my organization’s term for those of us that work permanently from our homes) is less common than a team made of people from two or three offices.

It’s been a fairly interesting experience, and not in the “OMG-what-a-total-disaster-I-have-a-dozen-more-horror-stories-to-take-around-with-me-warning-people-about-the-folly-of-distributed-scrum” sense.

One of the interesting things about this experience was how incredibly smoothly it went. I may just be one of the luckiest scrum masters in the world. I can’t claim superior scrum mastery as the root of this easy transition. The team was a well-established, mature team that had been working well together for a long time. The relationships were strong and team members trusted and respected one another. They had already introduced many agile practices way ahead of other groups within the organization. It seems clear to me that this helped immeasurably as we layered scrum on top of what they were already practicing. The other contributor to this, which I discovered serendipitously earlier this week on Twitter is explained in this excellent blog post by Bob McWhirter. In it, he makes the distinction between simply being a remote worker, and being a remote worker in a distributed team. In a truly distributed team there isn’t a single center of gravity where a ton of conversations occur that remote workers aren’t privy to. Due to people being spread out, a distributed team necessarily uses communication techniques that support remote workers, such as mailing lists, IRC etc.

I think the most interesting thing though is that we haven’t really seemed to need any special dispensations for what is a fairly unusual team configuration. No tweaks to scrum; no special tools, tricks, techniques etc. I’m not saying those won’t necessarily come as the team reflects more on areas for improvement during future retrospectives, just that we’ve been able to get going just by sticking to the basic principles. Our only accommodation has been for the people in Colorado to start a little early and the people in India to finish a little late (it’s a fairly brutal time zone difference).

So how are we doing it? Well, here are the basics:

We use Rally as our tool for agile project management, so that’s where our product and sprint backlogs are.

We use a wiki to organize a lot of other material. It all starts from a team home page which links to all manner of useful things: our definition of done, agreement on how we document stories, the build server, source code repository, released software etc.

We have a build server. This team’s current product is a rather old piece of legacy software that, presently, doesn’t lend itself to CI due to the lengthy build time. But it does still build every night.

We have used http://planningpoker.com to do distributed, real time story estimation in points. It’s not quite got the natural feel and immediacy I would like, but it’s not half bad at all.

We have daily “stand-ups” held in the morning (US time) which is evening for team members in India.

We have a phpBB discussion forum for the team set up…we also have an email distribution list that includes all team members. Interestingly the distro list gets all the action. I’m not sure if that’s because people are less familiar with using the discussion forum medium. I think it might be because there’s a greater immediacy to email based communication.

Interestingly the team has, through retrospectives, identified all the usual early issues I’ve seen other teams come up with during scrum adoption:

Big stories are bad

Spread out completion of stories during sprint

Recognize and raise impediments ASAP

Need the right people at the sprint review to make it truly valuable

Be clear that we have commitment from people outside the team for stories that depend on them for success

We have technical debt and we need to pay it down

We have, of course, faced some challenges; the two key examples being:

Meeting our commitments, i.e. getting stories “done done” by end of sprint. After a couple sprints we realized we would be much better off with smaller stories. Better to slip one small story than fail to finish two large ones.

English is a second language for a number of team members. With more spontaneous verbal and (due to our distributed nature) written communication there has, understandably, been moments of confusion. This isn’t quick to fix, but with more and more practice things can surely only get better.

All things considered, I’m very pleased to be part of what’s shaping up to be a really great scrum team.

Now, I’ve argued hard against distributed scrum before. That piece was mostly borne out of frustration, seeing teams of two halves. I still stand by the views expressed there. Having your whole team co-located alongside your customer still seems, by my experience, the preferable situation. The really interesting lesson for me here though was how, with a truly distributed team, Scrum can be made to work better than I anticipated. Moreover, it seems that by adding more team members at the office based locations we might weaken, not strengthen, our existing team. Perhaps we would do better to let those who are currently office based work from home too. With the right people, it seems that perhaps a fully distributed scrum team could trump a team split between two offices. I remain skeptical that they could better a fully co-located team. That said, I wouldn’t mind the chance to find out. It’d be a fascinating experiment.

Tuesday, November 2, 2010

Over my first coffee this morning I happened across the following tweet from Corey Haines:

"Today is day 2 of a month long positivity-fest! Love your life: #positivember http://vurl.me/WJU"

I almost feel bad for saying this, but it’s the truth: that handful of words irked me. Why? I think it’s because of my default interpretation. A month long positivity-fest sounded to me like some kind of rose-tinted denial of reality. Images of well-meaning but naïve parents that abound in a nearby town I’ll not name sprang to mind. The kind that work really hard to stop their children from expressing themselves when upset. The kind that want to insist that everything is always great. Even a cursory look at the psychological impact of that kind of suppression reveals that it probably ain’t healthy...

Then I read Corey’s blog post. It’s not (thankfully) quite that kind of hippy-dippy call to action. It’s much more an observation on how high levels of negativity are counter productive. How a concerted effort at positivity is the order of the day for advancing the notion of software craftsmanship. I’m up for that.

Still not sure I can quite buy into the notion of being completely positive about everything for the whole next month. Dropping the moaning and whining and negativity though is a good thing. It’s a bad habit I’ve had since forever. It’s easy to find fault and complain about silly little things.

A bit later, as I was walking the dog, an idea popped into my head that might help explain why the “all positive all month long” concept is hard for me. I believe gunning for all out positivity is an extreme reaction to the unpleasant other end of the scale. I think when we respond to something, that response lies somewhere along a continuum a bit like the following:

Reducing things to a binary negativity/positivity option over simplifies the matter. It’s the stuff to the left of the middle that’s toxic. To the right is great. I like to think I’m over there more and more these days, but still have plenty of work to do.

Not too long ago I read “The Lazy Manifesto” blog post by Leo Babauta on his zenhabits.net website. Items number 5 – “Do less complaining and criticizing” and number 7 – “Do less judging and expecting” are, for me, a more palatable way to think about what I believe Corey is trying to achieve with #postivember.

I hope I'm not too far off track. Even if I am a bit, those two ideas resonate with me and since making a conscious effort to try and adhere to them I have to say things feel good.