Week 11: Expectation Management

This week I started working on a new iteration for the feature I’ve been working on for the past couple of weeks. It’s going to be a nice feature and with the changes of this week it almost feels done.

It’s going to be great, the best, I guarantee it.

-Donald Trump, probably

Anyway, this week started with some suggestion from Sybren, as usual his suggestions made a lot of sense so I implemented them right away. I iterated on the feature, removed some old code that we no longer use.

The interesting thing this week was that I worked on code someone else worked on too. I can hear you think: “This must go wrong, right?”. Answer: It did. Although it could have been prevented.
I worked together with Klaas on making sure both our codes would remain working and when we realised it wouldn’t, it required some more thinking and going back to the drawing table. This time together, so we could adapt our code to the other’s code from the start. Klaas nor I realised, I guess, that we needed to inform Stefan about this because his planning was based around the fact that we would finish our features/iterations in time. Turns out, it took 1-2 days longer than he expected. This resulted in some unmanaged expectations and some frustrations on both ends. When we got together in a call we cleared some things up, planned ahead a bit more and decided what was important so that the rest of the team could continue working.

What I learned from this was that when something takes longer than how I planned it by more than 1-2 hours I should let Stefan know. Especially since I’m working on a feature that still needs more art implemented and needs a couple of iterations before it’s finished.
I also learned that I need to stay focussed on what it says in the sprint planning, and that when some code clean-up comes inbetween I shouldn’t do this right away but create some time for this later on.

Leave a Reply