The agile software delivery process can be many things. Essentially it is a process owned by the team that uses it, and should be adapted by the team that uses it, to make it best work for them. There is nothing set in stone, but typically you have quick iterations of software development, sprints, in which you deliver end to end functionality. If you can deliver that functionality to a Customer who can then use it, and provide feedback - brilliant. You can then act on the feedback.
At the end of each sprint the team should take time to reflect on what they have done, and see how they can improve the way they work, in order to make their lives easier. Not the lives of their managers, but their lives. These sprint retrospectives are an incredibly important part of the agile software delivery process, as they allow every team member to express their thoughts on what went well during a sprint, and what did not go well. The team can then celebrate what went well and reflect on what did not go well, and define a mechanism to make sure the things that didn't go well improve moving forwards.
It's important to understand that it is the team that owns the agile software delivery process, so it should be the team that decides how to best implement it for a specific project. The team should be empowered to make whatever change they feel will improve their lives based on discussions held within a sprint retrospective. A retrospective is not a witch hunt, it is an open, and sometimes frank, discussion about how, as a team, you can work better together.
So if you don't have retrospectives at the end of a sprint, there is no mechanism to calibrate within the team. There is no mechanism to allow team members to provide feedback as to how well they feel the team is working. There is no feedback to allow team members to suggest improvement. If you don't have retrospectives - there is no way to improve. If you think your software delivery process is fine as it is, then the chance that you are wrong is huge. Nothing is perfect.
I don't care how many two week sprints you deliver (or not as it may be), if you don't have retrospectives and allow for team evolution and growth, then you are missing the point of agile. One thing is certain working in sprints isn't what the process of agile software development is about. If you refuse to allow your team to improve, because you think you are right, then you ain't agile! You are about as agile as a brick.
Cheers
