In the last few episodes I've started a mini-series introducing some of the tools and practices that allow for the fast delivery of software and ultimately delivery of value to our customer. In episode 18, I introduced Source Control, what it was, why your developers will be using it and the value it brings. Following your development team saved their software code to the Source Control, I then introduced Continuous Integration in episode 19. I described how Continuous Integration allows us to find problems faster - allowing us to address them much more cost effectively and making Software Development much more productive. In episode 20, I introduced Continuous Delivery. It builds on Continuous Integration and make the releasing of our of software as easy as a button press. Through automation we make our release process a repeatable, reliable, easy, non-event. And then in the last episode I introduced Continuous Deployment which builds upon Continuous Delivery by removing the manual button press - automating the entire process from developer to customer many times a day. In this, the final episode of this mini-series, I want to talk about how to handle incomplete work.
Or listen at:
Published: Wed, 18 Dec 2019 16:31:58 GMT
Transcript
If you've listened to this mini-series from episode 18, you would have heard about a number of processes that build on top of each other - which I claim will deliver better quality in a safer and quicker manner to your customer - thus achieving return from that investment quicker.
You will have heard how these processes allow a developer to make a change to your software - be it a new feature or a bug fix - to be then automatically validated, tested and deployed to the customer.
And that this can be done multiple times a day.
Now if you are traditionally used to your software changes take weeks, months or even years for them to come to fruition, I would certainly expect you to question this.
Specifically in this mini-series I've covered techniques to get those software code changes from the developer into the hands of the customer quickly. What I've not talked about is developer work before that.
Just because we have made the process of getting the software code from the developer to customer quicker, it doesn't mean that the developer will suddenly write their code in the space of a few hours rather than weeks, months or years that you maybe be used to.
It doesn't compress time in that way.
These processes will definitely help in getting the software developed quicker - and in a massively better manner for ROI. I'll go through some of those in a second. But there is still time needed for the developer to understand the problem and write the software code - something I'll cover later in this episode.
But I want to be explicit. Simply following these processes will not suddenly reduce the development team's work down from 6 months to 6 hours - even if they do release code changes every hour.
Right, so lets re-iterate some of the benefits to developer throughput brought to us by Continuous Integration, Delivery and Deployment.
Firstly we identify problems quicker. The automated merging of disparate team members and automated testing highlight problems earlier. In traditional projects these problems get highlighted towards the end of the project - maybe 6 months after the original work was done. By highlighting that problem earlier ... Generally within a few hours of the work being done, the original developers will still have the problem in their mind. This makes fixing it considerably easier, quicker and cheaper.
Secondly, we reduce the efforts of the development team through automation. Previously any effort put into manual merging, testing and release by the team are feed up for more valuable activities.
Thirdly, and possible most importantly, we can get feedback from the Customer much quicker. When I talked about Minimum Viable Product, Lean, Agile and DevOps in episodes 6 through to 10, I emphasised the massive returns gained from quick feedback from the Customer.
As I've said time and time again, every change we want to make to our software is a hypothesis - a theory. Until such point as you can prove or disprove that theory with your customers, you have no true understand of its potential value. You as a team may think its a brilliant idea - but it doesn't mean your customers will want or use it.
Again, wouldn't we rather know that something is a failure after a few days rather than 6 months?
Sometime the most valuable investment is the one you don't make.
Ok, so how do we handle those development changes that are going to take weeks, months or years?
If traditional development would have taken weeks, months or years to deliver the change, then, even with the benefits these practices bring to the development team, there is a disconnect between getting those changes developed and putting that code through the practices even as infrequently as once a day.
To enable this to work, there are two things we need to think about;
Firstly, making the changes smaller.
Secondly, handling incomplete features in production.
Making the changes smaller will be a team effort. It will take creativity to break a larger initiative into smaller changes.
But again this is very much in line with the mind set from Minimum Viable Product, Agile, Lean and DevOps.
It changes our thought process to one of "what next" based on feedback rather than slavishly following a plan drawn up many month previous.
Keeping that "what next" focus helps us to keep it small and thus much more likely to be something that can be delivered in sub-day increments.
With all that being said, regardless of how small we try to make those changes or the how much time is freed up by the practices, we have to decide what to do with incomplete work.
Incomplete work could be a change that is only half done or it could be a number of changes that make up a larger initiative which are not appropriate to release to customers yet.
If the remaining work to reach completion is days, weeks or even months - what do we do?
Do we release that incomplete work into production?
The answer to that is simple - yes. Yes we release that incomplete work into production.
We make sure that the investment in that incomplete change brings as much of the benefits that these practices can provide.
We make sure that the incomplete change isn't causing merge problem, isn't breaking automated tests and can be released safely.
The choice we make is if the Customer is aware of it.
In many cases we would choose, quite sensibly, to hide incomplete changes or initiatives from our Customer - or at least the majority of them.
We would use a technique known as Feature Toggles to hide those changes from the Customer.
Wikipedia describes Feature Toggles as:
"[...] a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches), such that a feature can be tested even before it is completed and ready for release. Feature Toggle is used to hide, enable or disable the feature during run time. [...] The technique allows developers to release a version of a product that has unfinished features. These unfinished features are hidden (toggled) so they do not appear in the user interface. Feature toggles may allow shorter software integration cycles. A team working on a project can use feature toggle to speed up the process of development, that can include the incomplete code as well."
The development team would wrap their incomplete code within a Feature Toggle - which would be switched off - meaning that the Customer was not exposed to the changes.
Once the code is complete enough for Customer exposure, then the Feature Toggle could be "flipped", allowing the new code to take affect.
An exceptionally powerful benefit of Feature Toggles is the ability to vary "flipped state" by groups of customers.
So for example, while you may hide your incomplete feature from your Customers, you may choose to make it available to internal users to review.
You could even expand this idea out into having multiple groups that a change moves through.
Say for example, you have a 4 groups:
- Internal Staff
- Canary Customers - those Customers that want access to your new changes as quickly as possible. They are engaged and happy to work with you on incomplete changes to help refine the direction of the product. They are generally vocal and very keen to provide feedback
- Early Adopters - those Customers that want to have access to your changes once they are seen as complete. They again are keen to use the new changes, but they are unwilling to take the risks that may come from being a Canary
- Stable Adopters - those Customers that will likely benefit from your change - but are not keen to engage in unstable changes like the canaries or early adopters
These groups are commonly described as Deployment Rings - where your change will be released first to your inner ring - your most trusted and accepting group for change - your internal staff.
That change can then progress from your internal staff to the canary customers, then the early adopters and finally the stable adopters based on the desire of your business and customers for the change.
Its the same software that is release, but the Feature Toggles controls what is available to each Deployment Ring.
The Feature Toggles provides your organisation with the flexibility to choose how to handle every change.
You may choose for example that an incomplete change may only every make it as far as the Canary customers to get sample feedback.
Or you may choose to release a security fix very quickly to all rings.
When used in conjunction with the post-release monitoring I talked about in episode 15, it can help to reduce risk by monitoring the effect of a change as it is rolled out to subsets of your customer base.
This is very much a practice is use today;
Microsoft for example have their Windows Insider Program which provides early versions of Microsoft products to subscribed users.
Google Chrome has a similar concept with canary, development, beta and stable versions of its browser. The earlier versions allow customers to see new features and provide feedback. And sometimes these features will never make it into the stable version based on that feedback.
Feature Toggles and Deployment Rings can be an exceptionally powerful tool to achieving great ROI on your investment.
In this mini-series I've talked about Source Control, Continuous Integration, Continuous Delivery, Continuous Deployment and finally how to handle incomplete code.
Through the course of this mini-series I've aimed to cover the topics and practices that provide a means of getting your investment in software development from the development team and into the customer as fast as possible in a safe manner.
The practices maintain a focus on getting valuable feedback from the customer while maintaining quality.
And in this episode I concluded the mini-series by introducing Feature Toggles and Deployment Rings to complement the practices both for incomplete code and controlling rollout to your customers.