Traditionally IT-systems and products are developed in a project. Once developed, it is deployed and handed off to the maintenance organisation. But the new companies that start out with an agile way of working does not have these maintenance organisations. How do they do it? Is there no Maintenance in Agile?
Stick with your product throughout the lifecycle
When developing a product in an agile way, the developers are divided into teams. These teams have all the knowledge needed to build a feature and deploy it to end users. One of the agile principles is to continuously deliver new or improved features to your end users. Agile teams do not wait until the whole product is done (because it is just nearly impossible to know when the product is finished).
To fulfil this, the easiest thing is to let the teams that work with a specific product continue to work with that product until it reaches end of life. And that is actually a great idea.
On the other hand, an organisation that separates projects from maintenance requires a hand off from the project organisation to the maintenance organisation. This leads to several bad things.
-
Loss of knowledge
It is for a fact impossible to replace knowledge in a person’s brain with a document, no matter how big the document is. So those working in the maintenance organisation will have to build up all that tacit knowledge those in the project already has. -
Costs time and money
It takes quite some time to be ready for a hand off. For instance, the receiving maintenance organisation must be in place. In order to do that, several mid level bosses have been locked in discussions on who, why and when should be on the receiving end when the project finally is regarded to be finished. -
No learning in the project team
As all feedback from real users lands in the lap of the maintenance organisation, all learning about what the end users actually need goes to those who have the least knowledge on how the system is built. Those working in the project team have no idea what end users think about what they built, as they happily have moved along to the next project. Sometimes the project manager has written a report with learnings which is filed in the document repository and, if you’re lucky, has been presented at the last steering committee meeting.
Eat your own dog food
Teams that continue to develop a system over time tend to take pride in what they build. As they get feedback from users or stakeholders, they realise that they have to change their code and that is hard if you have a lot of technical debt. So they keep their code clean, nice and tidy, and develop techniques for being able to change functionality fast, as for instance automated tests or continuous delivery.
On the other hand, if you have a project that is lead by a Project Leader whose success is measured by delivering a system on time and on budget, you’ll have a Project Leader that makes d**n sure that the system is done when it is supposed to. This means longer working days the closer to the delivery date you’re coming. Cramming out features, barely making them work, thus creating huge amount of technical debt, but the project will be celebrated as a great success. The mess created by the project will be the maintenance organisation’s problem instead.
Plus that leads to another bad thing: the A-team and the B-team. Those working with new development are considered to be a little bit better than those just working with fixing bugs. They get the new and shiny tools first, the nicer part of the office, while the maintenance guys, well, they’re just the maintenance guys, right? How motivating is that?
Agile is maintenance!
If your organisation is truly agile, there is no need for a separate maintenance organisation. Your teams will be developing and maintaining the product at the same time. So no, Agile maintenance does not exist. Agile is maintenance!
2nd Photo Credit: smiteme Compfight cc
Nice blog!
The other way around is true as well..
Quite often a project is a bunch of additional requirements for an existing product. One might argue that after the ” hello World” a project is maintaining an existing product as well 🙂
Breaking a project in to peaces makes is possible to absorb the demand for changing products into multi disciplined maintenance teams.
Whether no dev or no ops.. it turns out to be responsible lifecycle teams.
Thanks for a great post Mikael!
Pretty obvious that its better that developers of a system also maintain it. But we have to prove that it’s not only better, but also cheaper in the long run. We also have to rebut the argument that new development is harder than maintenance and thus we must free our top resources (which are scarce) for that. This is were it gets challenging.
Hi Marcus and thanks for your comment!
I agree totally with what you are saying, and I would like to add that there is an economic problem involved as well. Capex and opex must be handled in some way. It is very difficult to see which change in a software system that is capex and which is opex.