Categories
agile programming project management

Scrum: I added a feature to my game, but it’s 5% broken

With Scrum, you’re constantly focussing on:

How does the application look / work for the user *right now*?

…to the extent that you care more about “does this feature work for the user?” than “is the code/art/architecture for this feature ideal?”.

“It’s not done” … “but it looks done!”

We regularly get situations where a feature *appears* to work, to a casual observer – but on deeper inspection, it’s clearly broken in one or more significant ways. Sometimes, the “broken” parts are so obscure that you’d need help to even find them. Other times, they’re obvious if you try to to use the feature more than just once or twice.

In Scrum terms, it’s pretty clear what’s gone wrong: the Product Owner didn’t describe the feature clearly enough (they implicitly included functionality they didn’t really care about, … or they described it too vaguely to be implemented well).

Scrum’s in-built check/balance against that is the Team. The developer who adopted the task should have rejected it during the Planning meeting, should have insisted on a clearer User Story (or a more explicit feature description).

But in the real world, this stuff happens. Leaving the issue: What do you do next?

One technique: Divide and Conquer

Here’s an approach I’ve been experimenting with recently.

When it happens, you split the feature description in half, re-defining one half as the part which is done + working, and the other half as the part which isn’t working. Or into 3, 4, etc – if there’s multiple “player visible” ways in which it’s not working.

This seems to work pretty well – it lets us independently prioritise “the bit we’ve already got (hence: zero extra dev cost)” and “the hard stuff that’s not working”. And quite often, we end up redesigning some other part in a way that makes the broken edge-cases no longer exist – so we never need to fix them.

…but I’m still experimenting with it. I’m sure we could do our Planning meetings better – both from the PO side (more detailed descriptions, more PO planning) and/or from the developer side (more questioning, demands for more detail).

One reply on “Scrum: I added a feature to my game, but it’s 5% broken”

I agree. Visibility is very important, particularly when you’ve got a non-technical person who is unable (or unwilling) to acknowledge technical costs. They see the tip of the iceberg and just assume that’s all there is to it. Sometimes this is OK and the ramifications aren’t huge, but in the games industry (a stronghold of The Crazy) it’s not uncommon for pressure to be applied to “Go Faster”. Don’t actually apply any reasoning or rigour, just Go Faster.

“Chris got his feature working in 2 days” aside: while fucking over all the other programmers on his team “… so why did Pete take 2 days?” If you have an unbalanced or unwieldy team, this can be a horrendous influence, as the technical consequences for cutting a swath across a codebase can be particularly nasty (I call guys who indiscriminately program in this way “straight line” programmers, because they will solve the problem by knocking down each and every wall that is in their way.

I’ve lost count of the amount of times where it takes a few days to do a rough feature (either as a prototype or first pass implementation to see if the feature fits / works with the product), but to make it robust can take much longer. Even with painfully explicit delineation (“this is a rough version and we aren’t ready to go live / turn the feature on yet”), some folk will see screenshots / a video / use it in the build and just assume it’s 90% of the way there and refuse to schedule more time (or put pressure on you to finish faster). Making these reality distortions visible is a good thing for all.

Moreover, by making the tradeoffs explicit, it gives the product owner choices — we can ship fast and loose, or we can spend n extra days on it and make it robust. You choose. What is important to you? You can have one or the other, but not both.

Regarding the gap between visible progress and technical soundness, I can’t remember who said it, but the gist of the comment was “you can use scrum without agile processes, but it’s a bit like a penguin flapping its wings — it’s not going to fly”. This all sounds a bit wanky, but the justification is sound: you have a much better chance of maintaining good levels of progress if you’re not building on a shifting mountain of shit (which, again, brings me back to choices — “you can have this now, but it will make is slower later unless we allocate some time to fix it”).

Comments are closed.