Release Ready
One of the principles of agile is to Deliver Working Software: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. What that principle doesn’t tell us is: who are we delivering the software to exactly? Of course the answer is (and should be) it depends!
A small team would deliver software directly to the consumers. In larger organizations, and specifically ones going through an agile transformation, the delivery of working software has different meanings. For example: your team builds the front end of a complex system. Can it simply upload your software to a production server when it’s development ready? It is likely that someone deploys it for you. Training and documentation may also be necessary, and scheduling and executing it also requires additional time. Integration and regression testing at scale is yet another factor, and the list goes on.
As we work with agile at scale the definition of done for a team is only sufficient for the team. The definition of ready for a user story is sufficient for those developing the stories. So how do we know when we’re truly ready to release?
The Definition of Release Ready.
Our Teams work with a supportive cast of characters that help us get our work to its destination. Much like a business analyst will consider what the developers need, it is logical that developers consider the downstream activities that affect their ability to release. Developing the software doesn’t end our responsibility to deliver working software.
I use the Definition of Release Ready as a way to give the Team an opportunity to explicitly understand and track what needs to happen after the development is done. To define Release Ready I include various stakeholders that are responsible for getting the work to the finish line. Some groups that should be involved in the definition are:
- Security
- Integration Testing
- User Acceptance Testing
- End User Documentation
- Training
- Tech Ops
All the work mentioned above should take place as close to development as possible. Some of the work by its nature will tend to leak beyond the sprints. Defining Release Ready together with the Team will not only validate your work, but also build on the agile principles of building relationships, respect, face-to-face communication, and delivering working software.
When are you really done, done…done?
Comment (1)
Jeevan Mathew
Nice thought! Yes, I do agree that completing user story per DoD is the major part of the task but as you have defined in the Definition of Release Ready, there may be other tasks team still need to accomplish before it can be called truly production ready.
Some of these tasks will be known before we start the project.
For example the security guidelines is something i have seen handed over to the team before start of the project to make sure that the team will always adhere to it.
Some will be identified while the team is working on a user story and may be too late to fit in the sprint or may need to wait further to see if it needs to be worked on or not. For example need to include a piece of code in Performance Testing. Another example usually happens on heavy integration project is the need of a piece to be included in the integration testing.
I typically do this
1) Have a check list of the item to be included in Definition of Release Ready
2) As the team is working through the User Stories, identify the impacts.
2.a) first, during user story grooming or sprint planning sessions, and accommodate them in the current sprint if the capacity allows.
2.b) It is also worth running through the check list during sprint demo. For example : An end user or product owner should be happy to identify any piece of to be added in the use guide or training.as it may be worth to make that decision during the demo (and not during sprint planning)
– Jeevan