As a developer, I really dislike having completed software sitting on the shelf. Possibly waiting weeks for deployment. I actually find it a bit disheartening and stressful to have complete software “gathering dust”. I want to get my completed piece of code into production as soon as possible. I want to get feedback on the usability of an approach, or whether the clients are actually using the piece of functionality I sweated over.
A developer truly only learns how their code reacts and how clients interact with their feature once it is in production. So by delivering fast, you are aiding in Amplifying learning. By delivering fast you are eliminating the potential for the perpetuation of incomplete or incorrect assumptions.
By delivering as soon as a feature is complete, any assumptions are ratified immediately. This allows for the developers to either continue on the same tack, or to change tack based on the feedback they receive. Thereby immediately eliminating any rework that could have arisen out of the incorrect assumptions.
Apart from my needs as a developer, getting code into production allows the benefits to, most importantly, accrue to the client and the organisation in a more reasonable time frame. Clients are on the receiving end of new features, that should ultimately be solving problems for them. And the business can make money, indirectly or directly, from these changes.
Over time, requirements also inevitably change. And if they are not deployed, the requirements are changing based on assumptions of the business analysts or product owner. We want changes in requirements to come about based on feedback from the clients using the functionality in production. We want the validated learning that Eric Ries describes in his book The Lean Startup 1.
It is stated that
Changes in requirements as a percentage of the original requirements increases non-linearly as the amount of time increases. A typical 9-12 month project generates roughly a 25 percent change in requirements. However, the amount of requirements change over a month averages only 1-2 percent. And it is much easier to get users to accept waiting until next month rather than next year.2
Even though a month is still a long time to wait for a requirement to be delivered into production, a one to two percent change in requirement is a bit more tolerable than a quarter of your requirements changing over a course of the year.
In my experience, the 80:20 rule also applies to requirements. Very often 80 percent of the value is achieved by 20 percent of the features. So get the 20 percent out there quickly. Often you will find that many of the features are actually not even required. So by deploying quickly we are validating requirements and eliminating unnecessary work.
For a developer, there is nothing worse than having to support a piece of functionality when it goes into production weeks or months after it was completed. I can barely remember what I did yesterday, let alone what I did a week or a month ago. I want to get feedback immediately so that if things do go pear shaped I don’t have to dredge what I did from the back of my mind.
So, in order to achieve this, developers must have the practices and infrastructure in place to be able to deliver as often as possible into production. If you have to go through a number of steps to do a deployment, then doing one everyday is a drag. You should be able to trigger a build and deployment at the click of a button. Not only does this eliminate waste, but it also reduces risk by having a repeatable process. Humans make mistakes, machines don’t. Machines do what you tell them to do every time. And machines can do it quicker.
Developers must also be in the habit of checking in production quality code, often. If the developer is working on a large piece of work, which is not going to be complete before the next deployment, then they should be toggling their code with feature toggles. This takes effort and foresight on the part of the developer, but there are a number of benefits.
The use of feature toggles allows for the deployment of incomplete features into production. Feature toggles also allow for dark launching of features that can be switched on at a later date. There is also the added benefit of having the capability to “switch off” a piece of code that has recently being release if it is defective or not behaving as expected. Thus providing a “safety net” for when things inevitably do go wrong.
Delivering code into production as often as possible will eliminate the traditional, manual approach to quality assurance. As much testing as possible must be automated from automated unit tests to automated acceptance tests. Having teams of “testers” running manual regression test packs is not economically viable. Especially when you need to do this every day.
In my opinion, the role of the tester in a Lean or Agile team changes. In a traditional waterfall project testing would be a quality gate that must be ticked before moving into production. When a project is delivering at a high cadence then the role of a tester should be elevated to the start of the change to assist in the identification of missed scenarios, unit tests that need to be written or changes to automation scripts based on the change.
The culture of the organisation also needs to change to enable rapid delivery. Organisations that are very hierarchal and rely on waterfall development methodologies will battle to move towards rapid deployments. This is where a move to the DevOps model of teams really starts to bare fruit. I like this statement by Werner Vogels – “you build it, you run it”3. This approach leads to a longer term view and builds on my preference for “product teams” as opposed to “project teams”. Teams learn to work together and their decision making is directed towards the long term, rather than the duration of a project.
And obviously, agile project management methodologies are a must to be able to deliver fast. Techniques such as Scrum allow for short iterations and rapid feedback. Scrum also makes it harder to hide any incompetencies or issues. Even if the issues are not picked up in the daily stands up, the issue should not persist beyond the sprint duration.
Creating the ability to deliver fast is not something that can happen over night. There are many practices and tools that are required to be in place in order for a team to operate at its maximum cadence. Top of which are Test Driven Development, Continuos integration and Continuos Delivery in my opinion. Along with tooling and practices, the organisational culture also needs to evolve in order to enable this to happen, bureaucracy will slowly smother all good intentions to move towards delivering fast.
- Lean Startup – available at http://theleanstartup.com/principles
- Lean Software Development overview – available at http://codebetter.com/darrellnorton/2005/02/02/lean-software-development-overview/
- Operations is dead, but please don’t replace it with devops. – available at http://diversity.net.nz/operations-is-dead-but-please-dont-replace-it-with-devops/2013/05/15/