In this post, I want to talk about how teams I work with manage the differences between software development and delivery.
In an agile world, most teams purely focus on the sprint cycle being the only container for any work that the team perform. During this cycle, the software development happens, as does releasing any software that has been developed.
Continuous delivery is often seen as the ultimate goal that works alongside this sprint model, with the ability to automatically deploy a change to production as soon as it has been developed, according to the definition of done.
In my experience, whilst many developers might idolise this approach, for most organisations it is the wrong approach.
For most customers of platforms developed for these organisations, it is the wrong approach.
This push towards the continuous delivery goal can create an unnecessarily high level of QA and other coordination work throughout the entire development process. This can dramatically slow down development, increase the risk of delivery, and reduce the level of traceability across the development as a whole.
Rather than seeking to integrate all types of work into a sprint cycle, if we are to develop quality software efficiently, we should instead recognise that there are different cycles of work that have different requirements and patterns.
Development of software
The development of software is the work performed by developers day to day, writing the code to implement the required features.
This work should be done in a sprint cycle in a flexible way that allows developers to determine the best route to getting that work developed.
With an agreed definition of what done means, a developer should be able to break down a feature as a required and transition it from in-progress to review, and then done.
Whilst many developers may be involved in the development of a particular feature, or story in Jira, there should be a developer that assumes overall responsibility for ensuring the future is delivered in a complete, or usable form, rather than in a way that renders it unusable.
Defining the stages of an issue under development are outside of the scope of this post. The only thing I will say is that we should seek to keep these as lightweight as possible.
The aim for this sprint cycle is to allow developers to move items from the backlog through to done in as short a time as possible, limiting the dependencies they have whilst still protecting the quality of the work developed.
Delivery of software
At key intervals, milestones, or mini-milestones, we will need to deliver work.
Delivering work in this context means verifying the quality of the work that has undergone development and delivery into a staging environment.
Once work has been verified in staging, the delivery can progress to delivering the same changes into production.
Delivery is something that needs to be planned, to allow for test cycles to be defined, and for any stakeholders to consider what actions they need to have relating to the release. This could involve managing customer expectations or other external activities.
This delivery process firstly requires the work required to be delivered to be identified. This should involve drawing a line in the timeline of development that has been merged to master, and deciding a point in time that best defines the functionality to be released.
Once we understand the functionality to be delivered, we should create a test cycle, a plan of the manual tests that we wish to execute to prove the candidate changes are fit for purpose.
Once we have this feature list and test plan, we can merge the relevant changes from master branches to staging branches, which should automatically create staging builds and deploy changes to the staging environment for validation.
The test cycles defined should be executed against the staging environment, with any failures resulting in new issues being created. For these issues, a decision should be taken to decide whether these should block the release or not.
Once we are in a position where we are happy with the results of a test cycle, the staging release is considered to be validated. At this point, the customer should be given final approval, a chance to explore the features themselves and will have the final decision on whether these changes should be deployed to production / released to app stores.
The aim of this delivery cycle is to deliver release candidates into staging for quality and other approval before then delivering into a production environment.
Timing of work
The development and delivery cycles operate in parallel with each other.
There should be a development and delivery cycle in progress at any time, although delivery cycles may complete quicker than work is available to fill that cycle.
In this instance, anyone involved in the delivery cycle should be able to contribute in many ways to the development work.
People involved in the delivery work may well operate on work that has been developed in past sprints, assist with information gathering and feedback during sprint work as well as have a view ahead of the current sprint and perform anaylsis with a test focus on items that are soon to be prioritised for a development cycle.
Other work such as UX work, technical architecture, and product analysis should be operating ahead of the current sprint,
By recognising the different cycles of work, and how they overlap with sprint work, we can form development practices that are much more efficient than those that are trying to force everything into a sprint.
It does not mean sprints are not very useful. It simply means that there is more to life than the sprint, and we should recognise that fact and organise ourselves recognising this reality.