Traditional concepts for software maintenance applied to custom software have resulted in unmotivated teams serving indifferent or unhappy customers. This presents the polar opposite of what Futurice aspires to be and do.
I don't want to write about the traditional models, so I won't! There is plenty of literature available on the subject, check out Amazon.
We needed a fresh concept. Since I had personally failed twice before to come up with anything substantially better, I hesitated in volunteering. The environment at Futurice was (and remains) unique, though, with mutual respect and low hierarchy; game on.
Having a technical background, I really like numbered lists. Hence, some axioms to base the new concept on, based on experience:
- Maintaining and improving complex custom software is damn challenging.
- A sense of ownership is important; traditional handovers never convey that.
- Systems usually start to generate revenue at launch – this is the real test.
- The needs of the customers are seldom alike.
- There is always technical debt; it's about how you manage it.
- Mentioning 'maintenance' turns ambitious jobseekers sad.
A logical first step was to talk with the people who were doing the maintenance here. What works? Not much. What disturbs you? Everything, pretty much.
To brazenly summarize a series of long, thoughtful discussions, the main issues were identified as:
- Doing erratic ad-hoc work instead of organized and planned development
- Less than optimal maintainability of the systems being maintained
- Lousy image of the work, it being "just maintenance"
There were also some issues with customer satisfaction and profitability. Nothing really bad, but we set the bar impossibly high here at Futurice.
For evidence, behold our new unit's goals for its first year of operation:
- Top employee satisfaction
- Top customer satisfaction
- High profitability despite growth
How's that for ambition? Yes, they are in order of importance.
We had identified the main six generic challenges, the three biggest issues voiced by the people doing the work currently, and now we also had ludicrous goals that I promptly communicated up, to the amusement of the CEO and the board.
Now, the new concept. It had to be simple for it to work. Again, what followed was a series of long discussions, scribbling on whiteboards, finding out what was written on the subject of agile maintenance (not much). Even some beer may have been had.
Here's the nine-step team recipe we came up with, if you want to give it a try:
1. Come up with a flamboyant name that does not include the word "maintenance". We went with Lifecycle Management, so please call your unit something else.
2. Recruit (internally and externally) a quality-focused team of developers. Make sure to include some people that are in the early stages of their career, but balance it off by having enough benevolent seniority. Having one or two people generally acknowledged as badass professionals to join from the start is beneficial.
3. Focus on service improvement instead of bug-fixing. Your primary goal is to help the customer get more out of the system they have ordered. Succeeding in this has a positive side-effect of preventing the post-production development from being marginalized. We want to improve the services and invoice the actual work we do. If we can do this, there's no need to ask for any compensation for fast response times. Or to bother the legal departments with strict SLAs, really. Mutual trust is the key.
4. Have your team members participate in the development projects to ensure quality and maintainability. They will learn about the solutions being built and can elegantly carry them to the maintenance phase. Handover averted. Sense of ownership achieved. Technical debt decreased. If this is not possible, and the solution is very complex, steal people from the project team for at
least a couple months. If they are stars, never let them leave... by making sure they want to stay!
5. Develop an ambitious roadmap. In a project house you are a logical internal services provider - services such as testing, auditing, coaching and so forth. Instead of being the Maintenance Unit, you should be aiming at becoming the Services Unit. In addition to helping your company, this will open up all sorts of fascinating career development opportunities for the team.
6. Make sure you are profitable. This is easy if your project teams generate high quality solutions, so that warranty fixes do not come into play and generate overruns. Productize your offering in order to make buying easy. Remember that customers have very variable needs; be flexible, but remember you are running a business.
7. Grant people a lot of responsibility. We have a service manager role; this is usually a software engineer acting as a constant point of contact to the customer, while simultaneously improving their solution - the lack of overhead is refreshing for all parties involved. Having the lead developer learning the customer’s business by heart is invaluable.
8. Perhaps needless to state, but keep the concept and your operation model under critical evaluation all the time - never stop improving. Ask for customer feedback and if that is not enough, demand it. You need it.
9. Keep everyone in the team involved in developing your new concept and way of working. Also invite people from other units and upper management constantly to contribute and review your offering. The best way to get people to understand the value of what you are building is to have them participate in the design.
Our unit has operated fifteen months now. We have grown from the initial mini-team to a respectable unit, and we are currently the fastest growing unit in the company. Our customer satisfaction is high, our employee satisfaction is high and we are quite profitable indeed. We are enjoying the work and meeting the targets.
Certainly there is room for improvement and this is precisely what we plan to do. We will author some more posts in the coming weeks, discussing the challenges, characteristics and opportunities of this business in detail. I am sure our thoughts about DevOps will be included.