Alright, I know, that’s not entirely true. But still, there is something to this I only figured out a little while ago. A colleague was looking at the team and I discussing new features and choosing the ones we would tackle the next coming weeks. Frustrated by a tight deadline he threw the words “Don’t you guys have any deadlines?” at us, leaving us a bit baffled not knowing what to reply apart from “No…”. And then it hit me. No, we did not have deadlines anymore. At least not of the spirit murdering, demotivating type. How come? One year earlier we did have those deadlines and unhappy developers in the team. What changed?

Last year, part of the frustration of the team was that we always had to rush to finish things whenever a new price plan was in the pipeline (we maintain the Viking App at Mobile Vikings, a mobile operator). At first, I took this feedback to the business meetings and told them we were unable to create quality in such short time frames. As most of you know, and probably experienced, nothing ever changes after addressing feedback like that. I had a discussion with our CTO who stated tight deadlines do not exists and it’s all about how efficient you are as a team. I was quite angry after this meeting, thinking everyone in a business position had no respect for the team and everything was going to hell. Don’t tell me you never had that feeling before, I know you do.

A week later I was working at our app thinking how ugly it looked hacking all that new stuff in there when I saw the light. Not the business was creating the tight deadline but the app was responsible for our frustration. The app’s design did not lend itself to a more generic handling of basically anything, which made it really difficult to put all the pieces together every time the puzzle changed. At that moment I took the decision to recreate both the app and API behind it from scratch.

There were 2 parts of the app that needed a generic approach so the team could focus on features, improvements and granting wishes from users instead of our business department. We spent 4 months working like crazy to do this, we even grew as a team and company as it triggered more changes along way (more about this later). The end result is that we are now able to work on things our developers want to do, instead of what they have to do. We removed the freelancers from our team and only work with a core of 3 people who can do everything the previously larger team did, even at a faster pace.

When you go to a Scrum Master training they always talk about impediments. We make fun of this during standups and usually respond with “deadlines”, or another classic, “crappy code base”. But the most difficult part of being a Scrum Master is seeing what the hidden impediments are and what is holding back a team to really become awesome. I was mad at our CTO at the time, but he was right. There are deadlines, but that’s not what’s holding you back.