Project iterations or sprints are not an excuse to cobble together some software and toss it over the wall to the end users and stakeholders. This happens because the team knows the software isn’t done yet. If it doesn’t work properly or isn’t what the users want, the team will fix it in future iterations. That’s wrong.
This mindset is a derivative of waterfall thinking. When software development teams practice an iterative waterfall approach, they deliver incremental software updates to software quality assurance (SQA) and wait for feedback. The team fixes problems found by SQA and tosses the software back for more testing. That’s the way it works.
Now they decide to make a switch to agile software development in the form of Scrum, Kanban, Lean or XP. Instead of tossing the software to SQA, the team tests the software internally then tosses it to the stakeholders and end users. The development team can always fix it later, right?
There won’t be a later.
The stakeholders, end users and senior managers will quickly become disillusioned with the quality of the software (or lack of it). They will blame the recently adopted agile process. It won’t be long before the team hears that agile development doesn’t work. It’s out of control. There’s not enough documentation. There are no management controls. Development and SQA are too cozy. It’s time to go back to waterfall!
The real problem lies in the fact that the team is clinging to its waterfall values. They have adopted an agile approach to software development but they are not fully invested in it. They have carried over many of the habits and techniques from the old waterfall process. They view iterative software deliverables as snapshots in time — the deliverables might work, they might not. Nothing is complete until the end of the project.
Is it production-ready?
This is why some agile practitioners are so adamant about delivering production-ready software at the end of each iteration or sprint. This technique forces the team to focus on quality and getting stuff done. It doesn’t matter when the project ends. The software is ready for production use at any time.
In my opinion, having each iteration deliver production-ready software is often overly restrictive. I prefer to think about production-ready releases that are composed of iterations. However, teams that are new to agile might benefit from the discipline that production-ready iterations enforce. Once the team settles into a good delivery flow, they can opt to loosen the constraints on iterations and focus on making releases production-ready .
Whichever approach you choose, always strive to deliver only high-quality software to the end users. Anything less puts your project, your team and your company at risk.