I haven’t blogged much about software development and usually don’t blog about work related issues at all. Which is kind of strange, as this is a huge part of my life, and something I’m really interesting in.

With this post I try to change that. Slowly. Just to see how it goes.

I’ll start by telling you a story about failure, and how to learn from it. Not because I’m a negative person, but because failure, should be see as an excuse to stop and ponder. There’s often something important to learn.

We, and by we I mean me and the development team of Metaconomy, of which I’m the product manager and daily contact person, failed last week. The goal for the week, was to refactor the partnership functionality and UX, in our Channel Performance Manager solution.

The week started on Tuesday, as Monday was a public holiday in Ukraine, with me presenting some wire-frames, made in the excellent tool Balsamiq, with my idea to the new GUI and some of the changed interactions. After some discussions about the needed architectural changes, the Devs spend sometime time without me (we are working over Skype, I’m in Denmark, they are in Ukraine), breaking down the tasks and estimating them, before we got back together again.

The plan looked good – the estimates where, a bit beyond, what’s realistically possible within a four day iteration. But it looked doable, if we would allow some of the tweaking to bleed into next week. And we like to be aggressive with our weekly iterations.

The Wednesday status meeting went well. In hindsight, there might have been a few more questions and a bit more uncertainty that normal, that I could have picked up on, but I didn’t. We didn’t have a status voice/video status meeting on Thursday, as that was a public holiday in Denmark.

At the Friday status meeting, it was clear that we where not going to make the cut (we normally present the weekly changes to the Business team each Friday afternoon). Changes had been made, but weren’t in a state where they could be demoed and there was a lot of uncertainty about how to finish the task.

The team had learned things about the task, during the week, that made it possible for them to ask questions about how the system should work, I just couldn’t answer.

Pull the Plug

It was time to pull the plug on the task. So we decided to stop the task and get back to it Monday. Go do something else – maybe even take some time away from the keyboard.

It was kind of perfect, that this happened on a Friday, but I think (and hope) my reaction would have been the same in the middle of the week. Sometimes you need some distance. Allow your brain to focus on something else and just leave all that new knowledge, to do it’s own thing while you aren’t watching.

I must admit that I was a bit nervous, about the Monday iteration start-up meeting. But we all had some good ideas. I had some ideas on how the business logic could be changed to make more sense (inspired by the twitter form of follow based relationships) and the Dev guys had some idea for architectural changes, that would be easier to implement and allow us to be more flexible in our business logic, if I had gotten it wrong (again), without having to throw everything out (again).

Lessons learned

This may not sound like a major catastrophe, and it isn’t, but I still think it’s a good opportunity to learn something.

1. Just do it

We have been pushing this refractory job in front of us for a while. We knew we had to simplify the partnership design, but we didn’t seem to find just the perfect way of doing this. I did wire-frames and discussed it with Business. We thought we kind of had it. But we kept pushing it, because we might get an insight or new knowledge that would help us do right.

But deadlines are deadlines, and sometimes you have to just do it, even if you don’t know it all. This is want happened last week. We tried to implement something, with an incomplete idea of what it was. That didn’t work. We failed our iteration objective, which was a Friday demonstration of  “the new partnership functionality”.

But something else happened – we gained a lot of insight into the partnership domain. All that time spend with Business at the whiteboard or over wire-frames, was well spend, but trying to actually develop that – and failing, was the mechanism that allowed us to collect the missing pieces in our knowledge.

Lesson learned: Sometimes you just have to do it, brace your self for failure, but be ready to learn.

2. Identify the odd iteration

We knew our knowledge was a bit weaker then it usually is, when we started last weeks iteration, but we set out with the same goal, as all the previous, successful one-week iterations. Run for a week then demonstrate whatever we had. It may not be a full feature set, but it’s in a good enough state, that it can be demonstrated to Business.

I think we forgot to question the process. Okay, I forgot – that’s my job.

The one week iteration, with a demo at the end, have served us really well. We’ve been running a good long successful streak of them.

But with the level of uncertainty in this task, it might have been a mistake to leave a demo as the goal. A simple change of goal to “Validate the proposed partnership functionality/UX – if possible by implementing it”, would have left us more open to a running review of the assumptions in the proposal.

It would have left the developers with more freedom to scrap the iteration, faster and without consulting with me (who had the audacity to take a day off), instead of luring them into a useless work-harder-to-get-this-to-work-before-Friday-state.

Lesson learned: Identify iterations with a higher uncertainty that normal and treat them differently.

There’s also some lessons learned about communication, and the limits of what you can do, when you don’t have any real ways of validating your designs, but that’s for another post…