Strategically Using Slack Time after a Release
I just finished working on a big release. All in all, the team I work with spent about six months on this, between planning, writing code, testing, replanning and discovering new scope, and then more development and testing. We tested iteratively and got frequent feedback from our stakeholders, but it was still a big-bang release.
Knowing this, and knowing that it is in the nature of software to have bugs, what do we (and you) do after a big release like this?
On release day, I usually think my code is pretty solid—not bug-free, but still ready to go. However, after a release you will ideally see a rapid increase in the number of people using your new software, and those users have a lovely way of reminding me that my software is definitely not bug-free, and only questionably solid.
The week after our release, we had a couple of reports that needed to be written (SQL queries and generating a CSV file), a small UI change, and a couple of hours spent on education for new changes. Any aspirations we had of immediately starting the set of changes were set aside because of distractions, including testing code that was freshly moved into production. So we added a little slack and time to breathe.
The first sprint after our big release was maybe 50% or 60% of what we normally do. The changes were a little more straightforward and easier to finish in a day or so. The point of this was to pad time for emergent requests without overloading the development team.
I might start working on a change and then hear some feedback from users. That feedback requires getting an export of production data and loading that into my development environment, seeing if I can reproduce the issue, isolating the problem in the code, and either fixing it quickly if I can, or letting the people above me know what the problem is and how long it might take to fix.
After a big release, there will probably be more testing to perform. Unless you have a large budget and development team, that testing will take time and development resources. To test something release-specific, I need to get as close to that code as I can and then try to get the same data locally. The next step is more familiar to people in a testing role: try to decipher the feedback the best you can so that you can find and fix the problem.
So, what do you do after writing code and testing for a big release? Plan for more development and testing on the same code branch.
Slack time is crucial because it gives me time to fully think about a problem. After a release, I use that spare time to address customer feedback—without feeling the stress of having a full sprint at the same time as a possible production patch.
