I don't believe software development should end. If a software is in use, being sold or supported I believe there should be software development work taking place on that software. As a general principal I believe there should be little difference from the first day and all days until its decommissioning. The size of a software system as well as the team that operates it will vary over time, as will the technologies used and the principles lived after but it will be there as long as it provides value.
At the very least this means a team should be self-sufficient when it comes to the bare necessities of its work. This, to me, is a combination of being cross-functional, owning the operational aspects, being on-call as well as providing some notion of end-user support. Cross-functional is to cover the technical necessities of getting work done. Owning the operational aspect implies being responsible for operations, but not necessarily infrastructure, in which I include being on-call for the production system as well as providing end-user support in whatever fashion makes sense for the given software.
I believe much of the power and potential in software comes from the unknown. If a software already exists that does what we want to do in a way similar to how we want to do it, then we should not develop it. I think that all software must, at its core, be warranted by some differentiating factor. In the vortex of new and old technology coupled with our belief in a better way of solving a specific problem lies a lot of unknowns. To effectively address these unknowns and produce working software we need to be innovative and creative. Limiting detailed planning is a way of freeing up time and increasing ambiguity. By giving a team time and ambiguity we provide them with an environment better tailored for creativity and innovation.
A possible drawback of being self-sufficient and not having much detailed planning is that one can both get caught up in technical lily gilding as well as loose track of the bigger picture. To parry this a few team members need to have a nick for technical strategy, solution design and architecture in order to keep the mere technicalities together on a medium to long term basis. However I strongly believe there must also be a high-level direction, vision if you will, which is, to a large degree, set from outside the team, preferably together with the team but not by the team alone. This works together with the limited detailed planning to nudge the team in the right direction while not being detailed nor dictating.