Part 1 of What is Agile? looked at Agile, Waterfall, Scrum and Kanban. In this article, we’ll look at how teams are able to ship code quickly and with high quality.
It’s the question that most teams want to crack – “How do we respond to change in an ‘agile’ way?”. Automation, and lots of it.
In a global market, it’s critical that you’re able to quickly ship software changes to your product. Not only do will competitors do the same, but what your customers want six months from now can be very different to what they want today. Using your customers’ feedback (along with old fashion research) enables your teams to build software that will be actually used.
Let’s face it, without feedback, you’re just taking guesses and assuming your customers want these guesses.
Technically enabling your team to ship software fast is where Continuous Integration, Delivery and Deployment come into play. These practices will automate everything from testing to software releases.
Continuous Integration
“Being agile” is a mindset. It prioritizes testing and iteration over assumptions.
So if you can test and ship code faster, you’ll receive feedback quicker and, as a result, make more efficient product decisions. All in all, it means less waste.
To do this in practice, you:
- Ship a small, but workable, version of a feature you believe your customers will use (after asking them and conducting initial research).
- Calculate the feature’s usage metrics, and the like, so you can decide whether or not to a) continue developing the feature, b) pivot the idea or c) drop it all together.
What’s the first key to quicker feedback? Automated testing with Continuous Integration.
Continuous integration is:
“a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible” — Martin Fowler
To get Continuous Integration to work, there are a few basic steps which involve developers committing code to a source code repository which is then tested, integrated and built by a continuous integration server.
When your product is continually being tested, you can feel comfortable with releasing software more often. To boot, you’ll take your test suite completion time down from days to minutes.
Here are some Continuous Integration tools to get you kickstarted:
Continuous Delivery
Testing is essential for any software product, but getting the product into customers hands is when the real magic happens.
Continuous delivery is when “software can be released to production at any time”. The ‘can be’ refers to still needing to “push a button” (or run a script) to release the software.
By Yassal Sundman from Crisp’s Blog
This results in three benefits:
- The team can control when software is shipped, at the push of a button.
- There are no software release headaches, since releases are now automated.
- Teams can receive feedback from customers significantly faster.
For continuous delivery to work, a script must be written by the development team to automate the deployment process. In a nutshell, this deploys the latest successful continuous integration build of your software to your customers.
Many companies are now taking this to the next level, and automating the push of the deployment button. But should you?
Continuous Deployment
Continuous deployment does not require the push of a button to release software. Instead, code is deployed to production (and is “live”) automatically after it is successfully tested and integrated.
Theoretically, it’s not much more effort to skip continuous delivery entirely and go straight to continuous deployment. But, it’s not always ideal to automatically deploy code once developers commit their code.
Here are some situations of when it’s okay and not okay to continuously deploy code:
- Okay – UI changes
- Okay – Fixing small bugs (“Little changes [will only create] little problems“)
- Okay – Adding independent features
- Not okay – Changing critical systems (e.g. payment processing, order fulfilment)
- Not okay – Changing core functionality (some users may prefer the old feature, so this depends more on the product, for example, this is not okay for an accounting system, but perfectly fine for Facebook).
While Continuous Deployment is inherently suited to SaaS companies (people access the product via the Internet), both Google Chrome (installed software) and Tesla Motors (car firmware) have made it work in their less traditional situations.
For some inspiration, here’s a bigger list of successful continuous deployment adoption stories:
- IMVU, since 2009 (50 deployments/day)
- Wealthfront, since 2010
- Etsy, since 2010
- DISQUS, since 2011
- Box, since 2013
- Hubspot, since 2013 (300 deployments/day)
- Tesla and Adobe
- and many more…
What now?
Master continuous integration, delivery and deployment to get feedback faster from your customers. This will enable your team to develop valuable features whilst helping minimize wasted resources and time.
In the next article, we’ll look at how to design features with an ‘agile mindset’.
Read on for Part 3 of What is Agile? – The Pursuit of Product/Market Fit.
Sign up to get notified about future articles!