When working on large software projects, it's tempting to hold on to all code until launch. Read our lessons learned on agile programming.
Agile development and iterative releases are keys to a successful website launch. Here's some other takeaways we practice here at Business.com to ensure our software releases go as smooth as possible.
Release Early, Release Often
For the last six months, we have been heads down in developing a new site for Business.com. Our development team made the commitment to themselves to release code into our production environment at the conclusion of each two week sprint cycle. In previous big projects we neglected this commitment and regretted it only a few iterations into the project as we tried to merge months’ worth of code together.
When working on large software projects, it’s tempting to create a release branch, set it aside in some beta environment, and move onto the next sprint’s set of features without merging the code into something that you know already works. You must resist this temptation and figure out how features can be broken into blocks that can be moved into production code bases despite you keeping the curtain closed for your big release. Neglecting to release code into production will naturally defer extensive post-release testing, fail to uncover regression bugs, and will keep features out of the stakeholder’s hands.
In our example, we started by building and immediately releasing our big-data tracking platform. The rationale was to get any tracking stuff out of the way first so we could release into production and capture learnings on our existing site to be compared with data upon release of the new model. While we couldn’t complete the entire tracking suite in a single iteration, we were able to lay the foundation with storing basic events (impressions, visits, referring information, etc) from the onset. In following iterations, we layered on more complex data points such as scrolling percentages, user profiling, time on page, topics of interest, engagements and more.
By releasing consistently throughout a project, your final release to the public is no bigger or more technically challenging than each previous iteration. That gives your development team the opportunity to enjoy the public fanfare and cocktails that come with release while spending less time frantically trying to squash bugs introduced by merging 6 months’ worth of work at one moment in time.
Memorize the Principles of INVEST User Stories and SMART Tasks
I won’t define those two concepts in detail, instead I suggest that your development team read this article and make INVEST & SMART a part of their core ethos.
The gist is development teams (with the help of product leadership) breakdown user story features into their smallest independent form that still provides benefit to stakeholder. The benefits of following this principle are multiple. Major items are less likely to slide from one sprint cycle to the next, no team member is solely responsible for any large component, and you limit the chances of your team being victim of their own poor task estimation.
Early on, we struggled with our burndown charts looking like burndown cliffs as we were continuously scrambling at the end of each iteration trying to get big features through QA at the last minute. This would delay release, frustrate the team, and ultimately make us inefficient. Once we adopted INVEST and SMART our burndowns resembled the downward stairs you’d see in an agile textbook. As a result, we found ourselves getting smaller tasks in the hands of QA early on in the cycle and developers swarming related but independent stories. Everything from our demos, releases, knowledge sharing, and team morale improved almost immediately. We never looked back.
Here are actual burndown charts from this project:
Focus Less On Estimation More On Coding
As a scrummaster, this was a particularly difficult lesson for me to learn as I thought efforts spent on perfecting our estimation would make us a more efficient team. At the end of every iteration our retrospectives would reveal our complete failure to correctly estimate the size of our tasks. Those we estimated as small took us twice as long. Those which we thought were big were often completed in the same time a small task would be.
In planning meetings, we wasted too much time and energy debating whether something was a 1, 2, or 3 point story, leaving everyone frustrated and no closer to the understanding of how much work is involved in a task. Not a good way to start a development cycle!
As I’ve mentioned before, software estimation is basically impossible. Humans are notoriously bad at estimation. We underestimate the amount of time it will take to do something and we overestimate the impact of our efforts. I often speculate, as one myself, that developers are some of the worst estimators on the planet!
Eventually, we realized the futility in our estimation efforts and made the conscious effort to spend as little time possible estimating unknowns. All we wanted was a comparable measurement: “do we think this task is the size of any previously completed task?” On the count of three we raised our fingers and took the mean as our estimate and moved on with little debate. As before, we’d always find out that our estimations were awful but at least we got through planning quickly which gave us more time to work on coding new features and spared us the heartache of trying to identify every single detail prior to estimation.
By the end of the project we were blowing through features both big and small with little regard for how many points we assigned to them. If you break up your stories into small enough chunks, it doesn’t matter that something takes a developer two days when you assumed it would only take one. It all evens out in the end.
As with any any 6 month endeavor undertaken by a group of people, you’re bound to learn numerous lessons and this recent release is no different. While I could write a book about solutions to our problems, these three important lessons outlined above helped us overcome our biggest obstacles including losing our lead engineer in the middle of the project, hiring a new developer and bringing him up to speed without sacrificing output, navigating a complex data import across multiple systems (some of them 3rd party), and releasing a project that will revolutionize B2B digital marketing.