Agile processes give you an ability to do something faster. Often agile approaches give you an ability to deliver smaller chunks of software faster than legacy processes. But why does your team or organization feels the need to do "agile"? Why do you need faster or at a quicker iteration cycle?
Answering the "why" questions is critical. If there is not a defensible answer, substantiated by some mesurable business need, then either seek the answer or don't change a thing.
Examples of good reasons:
Get feedback from the product owner before releasing to the customersReduce the risk associated with monolithic deployment
In some cases releasing something early doesn't make sense. For example, the software that drops the ball on Times Square at midnight at the start of a year doesn't need to be released in increments to the customer. It may be developed using agile processes, but it doesn't need to be released to the customer in chunks.
From the SEI podcast series: "We know from existing SEI work on attribute-driven design, Quality Attribute Workshops, and the Architecture Tradeoff Analysis Method that a focus on quality attributes prevents costly rework. Such a long-term perspective, however, can be hard to maintain in a high-tempo, agile delivery model, which is why the SEI continues to recommend an architecture-centric engineering approach, regardless of the software methodology chosen. As part of our work in value-driven incremental delivery, we conducted exploratory interviews with teams in these high-tempo environments to characterize how they managed architectural quality attribute requirements (QARs). These requirements—such as performance, security, and availability—have a profound impact on system architecture and design, yet are often hard to divide, or slice, into the iteration-sized user stories common to iterative and incremental development. This difficulty typically exists because some attributes…