Let's take a look at our role in the Futurice project ecosystem:
The graph above is an abstraction of different types of projects. The vertical size of the project columns signifies the development bandwidth. Light green colour displays the effort of Futurice project teams, dark green displays the Lifecycle Management team effort. The initial production deployment is marked clearly in the graph, while subsequent production deployments are not. The existence of subsequent releases is assumed.
In project 1, the development effort winds down quickly after the production release. This would be a small project with a clearly defined end and minimal afterlife, or alternatively a very specific component with minimal need for changes after the deployment. These project types do not concern Lifecycle management.
Project 2 is a 'typical' agile project as it is often described in literature. The development continues with significant effort after the first production deployment and goes on until the customer no longer wants to invest in it. In this case, it makes sense to keep the original development team on board as long as possible.
Lifecycle Management becomes relevant in projects 3 and 4. Project 3 is a medium-size project where development continues after the production development, but with a constricted bandwidth. We get involved slightly before production deployment and quickly take over the development effort post-release.
Project 4 is a larger project. Our involvement starts early, typically with a team member joining the project as a developer. This ensures a painless handover after the go-live, as we now have continuity in the development effort and we retain the all-important project knowledge. In projects this large, we also provide usage and usability analysis on the software for the client to base future decisions on. When the project development pace picks up later on, a Futurice project team gets involved in order to bring in additional development muscle.
Takeover by Lifecycle Management becomes a good option when the development bandwidth in a project gets cut below 2 FTE. The core reason is that working alone is boring and often leads to relaxed quality standards and creative shortcuts, which is detrimental to maintainability and should be avoided. While a project team works best when its people can commit 100% to their current project, Lifecycle Management is set up in a specific way to be able to work with FTE fractions.
While in the classical definition of software maintenance the divider between development and maintenance is the go-live moment, in our agile reality that line is a bit more vague with development teams doing maintenance and vice versa. Saying that we do agile maintenance when post-release development effort drops under 2 FTE would be too simplified, but that establishes the general context of the work in a realistic way.
What about other brands of Agile maintenance?
A quick Google search on the web reveals that Agile maintenance is considered to be either the usage of some adaptation of Scrum in a maintenance team, or something called 'DevOps'. Scrum adaptations is a very broad definition, ours is a Kanban-styled continuous development approach that removes the need for sprints, as sprints do not really work in this context. The only branded alternative is the DevOps movement, so it's worth taking a look at it.
The movement was born from the clash of the goals of traditional maintenance/hosting departments, which the movement refers to as 'operations', and the goals of agile development teams. Traditional operations departments value stability and minimal deployments, while agile development calls for continuous deployments. A strong need to alleviate the pains caused by these conflicting needs arises.
The basic environment of the DevOps movement is an organisation which employs development and operations departments, with these departments entangled in a strong long-term relationship. This relationship creates the need and opportunity to bring together these separate parts of the organisation, which is the essence of the DevOps movement.
Compared to the DevOps approach, our brand of agile maintenance is more development- and less operations-oriented. This stems from our differing environment. We usually co-operate with a customers IT department or a third party hosting service. Sometimes we configure services that are hosted in the cloud, such as Amazon Web Services. We are familiar with the realities and issues related to hosting services, but we don't specialize in doing that kind of work. This is unlikely to change significantly as long as we are a company providing custom software projects, as the clients usually have their own preferred hosting solutions.