TL;DR
Your UAT process is currently external to your development team, and your delivery and deployment are tightly coupled. Without changing your underlying process or business assumptions, there is no way to make what you’re currently doing “agile.”
However, you can:
- select a more approrpiate agile framework,
- improve your agile practices,
- redesign your development and delivery processes, or
- accept the costs of doing business with your current implementation as-is.
While different answers may provide you with various potential solutions, they will typically fall within one of these four buckets. Which of the available options you choose will largely be a business or political decision, so be sure to factor that into your decsion-making process.
Analysis
Thanks but when we push to the staging environment for UAT we need to push the whole release in one go. This allows us to treat it like a dry run testing our production deployment. This means that the UAT can't be the same sprint as Development, no matter how long we make the sprint.
Despite the original question, the real problems, as described in comments, are:
UAT is an external process.
The UAT team and process are not internal to the development team, and therefore outside the span of control.
Delivery and release of each increment are tightly coupled.
By equating delivery with release, especially with an external dependency, your process can’t meet the Definition of Done within a single iteration.
Once you acknowledge these two built-in process problems, you can begin evaluating solutions.
Potential Solutions
There are a large potential pool of possible solutions to your problems. Which ones are politically palatable, and which ones make business sense to your organization, are going to vary greatly from company to company.
In no particular order, some of your options include:
Do Lean or Kanban, not Scrum.
Even though the question wasn’t tagged Scrum, the notion of “Sprints” is generally a sign that a team is trying to follow Scrum. However, if you are routinely unable to meet your Sprint Goals within a single iteration for institutionalized reasons that will not change, then Scrum may not be the right framework for you.
Internalize UAT.
If UAT is outside the team, it is possible to bring it into the team. Whether or not that’s something your company wants to do is a completely separate issue. It’s possible, so don’t dismiss the notion simply because it’s not the way the process is set up today.
A Scrum Master or agile coach should actively educate senior leadership on fundamental process problems like this. Allow the executive team to earn their paycheck by solving organizational process problems.
Decouple delivery from deployment.
In an agile framework, each cycle or iteration should deliver a potentially shippable increment of work. However, you don’t actually have to deploy it just because it was delivered.
Many agile teams use feature toggles and other continuous delivery practices to enable the team to deliver features at Sprint boundaries (or even more often), without necessarily having to deploy those changes to non-development environments. By removing deployment to your UAT environment from your Definition of Done and leaving it up to them to enable feature toggles when they’re ready, you create the ability to decouple those elements of your process.
Of course, this means any issues discovered in UAT will need to be sent back to the Product Backlog or input queue as new work to be estimated, prioritized, and scheduled in accordance with your agile framework. You have lots of flexibility in how you do this, but the one non-negotiable is that you cannot have an external process that hijacks or bypasses your internal agile process.
By choosing to have separate teams or an external testing process, management must accept the trade-off that UAT and deployment are out-of-band, and that the external processes can only create new work for the team at iteration boundaries and through the consumption of team resources that must be pulled from other activities. One way or another, this is true regardless of the agile (or even non-agile) framework you’re using!
There are other solutions possible, too. However, what they all have in common is that you (the collective and organizational “you”) must re-evaluate your current assumptions, and then inspect-and-adapt until you have achieved a more efficient process. Note that accepting the drag on productivity and financial costs of continuing to do business the way you do today is also a legitimate business decision, but that management can’t have both “business as usual” and “continuous improvement” at the same time. TAANSTAFL.
