Updated on by Daniel Twigg
The 10-Minute Build is the gold standard for getting what, in Agile/Scrum, we call Fast Feedback. With the click of a button, you should be able to build your software, run comprehensive automated tests, and deploy to a testing environment.
This matters. It allows the team to “fail fast”.
Fast Feedback
Agile/Scrum emphasises the importance of feedback loops, for example, our Daily Scrums and Sprints. These ceremonies provide rapid information to the Team as to the status of User Stories, and, hence, the progress of the product. Adding a 10-Minute Build to your toolkit can greatly enhance the speed of information and the acceptance of User Stories.
When a Feature or User Story can be put in front of the Product Owner and stakeholders within minutes, feedback, acceptance, or rejection, can be given to the team in near real-time. Agile/Scrum moves pretty fast, but our 10 Minute Build means that when Sprint Review rolls around our Stories have a higher acceptance rate. Fast Feedback has helped reduce the amount of Undone work, meaning we hit more of our targets.
Another consequence of our 10-Minute Build is that we minimise the amount of In Progress User Stories in our Sprints. Team members can often get Fast Feedback before they get too deep into other User Stories.
Any ScrumMaster will tell you that In Progress is toxic; a very common cause of failed Sprints.
Building in quality from the beginning
I’ve built and shipped a few SaaS products using Agile/Scrum, but with Cyclr this was the first “blank page” that I was able to approach as a Product Owner. Previous projects sometimes felt like Agile/Scrum was adapted for a process rather than adopted (not uncommon!). With Cyclr we invested time and effort upfront in engineering to give us:
- Continuous Integration (we use Jenkins)
- Automated Build (asynchronous on an AWS instance)
- Automated Deployment (we use Octopus)
Here’s our current process:
- A developer merges code to our development branch on Github
- A webhook pings Jenkins, who picks up the branch and triggers the build
- Octopus deploys the build to the development servers
- Jenkins posts a message on our /builds Slack channel announcing the deployment and build status
- Product Owner and stakeholders review the build
- High fives or real tears…
One of the biggest lessons we took from our 10 Minute Build was the need to integrate often, ensuring that a development branch didn’t drift too far. Complex merges are much more likely to snag on regression tests, meaning a higher frequency of failed builds.
If your software doesn’t have a 10-Minute Build, I definitely recommend you start to work towards one. It will tighten up your entire Agile/Scrum process and so help ensure you deliver better quality software on time.
