A few weeks ago we started to tweet our Sprint goals and after a Sprint we posted whether we achieved it or not. This week we stopped doing that and we want to tell you why.
While we believe openness is key to our service, Twitter is not the right medium to share complex information such as project progress in a very short message.
Instead, we’re going to switch to documenting our progress here in form of short blog posts. We’re not only going to share what our goals are for a Sprint but also what worked out and what didn’t. And if we have any resolution, any learning from a failure, we’re going to talk about it as well.
What we’re currently doing
Let’s start with our current work: For the past weeks we improved our front-end a lot, fixed a lot of bugs and refactored some of our modules. But most importantly, we’ve been working hard on building our technical infrastructure—our staging and our production server clusters.
The reason why we failed to achieve our Sprint goal of “setting up the production environment” is that we’ve discovered way more challenges when automating the server environment and its monitoring than anticipated. Looking at what we have now, at how quick we can scale and rebuild our environments, I personally think it was worth every missed Sprint goal, every decision we made, every single time our team’s mood was affected because of it.
In a team of three people, it’s incredibly important to have a well working infrastructure that is as automated as it can be and that makes it easy to be up and running again in a short amount of time in case of an emergency.
As I write this post, we’re QAing the production environment, so I’m confident that we’re close to finishing the story that expanded over three Sprints already.
But what else do we do currently? We’re on some UX improvements, have some more infrastructure work to do to sync our server-contents and will add some additional security features.
From now on you’ll find such news each week here.