The past four months, I really haven’t shared any updates on what I’ve been working on. Let’s change that, right now!
Since early January, I’ve been contracting for Bitgenics, a tiny startup company based in Melbourne, Vic., founded by Erwin van der Koogh. The product we’ve been working on is called LINC, which is positioned as a ‘Front-end Delivery Network’. Using the power of the cloud, our aim is to take away the hassle of running Single Page Applications (SPA), and adding some awesome features like Server Side Rendering (SSR). For now, we’ve focused on React-based SPAs, but we will soon be adding more profiles. For more information about Bitgenics and LINC, please refer to https://bitgenics.io.
Mostly, I’ve worked from home or from Spacecubed, a co-working space in Perth CBD. In addition, I’ve flown to Melbourne a couple of times for face-to-face discussions, usually working at Cluster, a co-working space in Melbourne CBD. Since I only need a laptop and an internet connection, I can basically work anywhere, and so I’ve found myself working sometimes in a coffee shop, or in the Hilton hotel in Perth. It’s very liberating to not have to work in an office from 9–5.
I’d like to take this opportunity to talk about some of the things I’ve learned over the past couple of months, which can be split roughly into two categories: lessons learned around development and coding, and those around working in an agile fashion. Let me start with the second category. I’ll address the development and coding lessons in the next blog post.
Even though our team exists of only the two of us (Erwin is the other one), we’ve been using Scrum to structure our work. The Scrum guide advises team sizes of 3–9 people, but doesn’t prohibit smaller or larger teams. If you still think Scrum prescribes team sizes of 7±2 people, please read the Scrum guide.
At the start of every week, we’d have a short Skype session to determine our Sprint Goal. I would say this is one of the most important aspects of Scrum, and often overlooked completely. During the meeting, we’d discuss what we’d like to see achieved in order to meet the Sprint Goal. Our Sprint Planning was usually done within an hour or so, which is fine given our Sprints were just a week long.
The Daily Scrum consisted (again) of a short Skype call, though we sometimes had to revert to using a regular phone if the Australian internet infrastructure wasn’t up to it. (Slow internet is one of the biggest frustrations of many Australians.) Did you think the ‘Daily Standup’ is a part of Scrum? Please, read the Scrum guide.
Apart from having synchronous conversations using Skype or the phone, we’d have additional asynchronous convos on Slack. We created Slack channels for basically every module we’d be working on, ensuring information is retained in a logical place. Sometimes, Slack just didn’t cut it and we’d revert (once again) to Skype. All this communication serves both the transparency and inspection aspects of Scrum.
Everything we planned to do was placed in a Trello board, so we could keep an eye on what was going on. We didn’t estimate our work using story points or anything, so no Planning Poker for us. Did you know the Scrum guide doesn’t mention story points at all?
For us, this way of working was ideal, and for many weeks we’d hit our sprint goal every single time. It has actually rekindled my appreciation of Scrum, which I had lost after years of being forced to do “corporate scrum”.
While we did hit a few bumps, which is expected if you’re working on a complex piece of software, we were able to mitigate the problems we encountered. “Scrum is a framework for developing and sustaining complex products” and as such provides enough room to handle such problems without being too prescriptive. Throwing away the entire backlog may sound Draconian, but it has happened once and it allowed us to start with a clean slate. Just remember: throwing away a backlog doesn’t mean the work you’ve done so far is thrown away! The backlog only contains items that haven’t been done.
As a side note: I reckon more companies should do this, because backlogs consisting of 1,000 items or more that will never be worked on are utterly useless. Unfortunately, many companies use Jira, which has the memory of an elephant (which are said to never forget anything). Just because you can store everything doesn’t mean you should.
One of the biggest lessons I’ve learned is that I had started attributing certain ceremonies, like planning poker, and artifacts, like story points, to Scrum, whereas the Scrum guide mentions neither; I need to go back to the basics and unlearn everything thrown at me during years of doing corporate scrum (which therefore isn’t scrum at all) and relearn what Scrum actually is. But having experienced firsthand how Scrum should work will make this process a lot easier.