Last night I had a great opportunity to deliver this slide deck to the Turner…
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:
- Integration Testing
- User Acceptance Testing
- End User Documentation
- 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?