The Good, the Bad, and the Legacy
Everything you always wanted to know about legacy and Scrum (but were afraid to ask)
26 September 2017
When we imagine a Scrum Team, we typically picture a group of happy, motivated people ready to work on some awesome project with the most modern technologies. The reality is sometimes quite the opposite, whereby the team is formed of unhappy, disappointed members because of some old and problematic system based on the most ancient technologies imaginable — a legacy application.
I do not want to lie: Legacy applications are a real pain. Legacy is where the programmer’s dreams go to die, where every good practice is forgotten, and the enthusiasm is suppressed by the harsh reality of an application that no one seems to be able to manage. For this reason, it’s important to get these monsters under control. I’ve seen plenty of people, including myself, who had no way to express their professional skills, creativity, or eagerness because of a software product that presented no opportunity for such values.
When applications turn into legacy
When we talk about legacy applications, we usually think that the problem lies in the mere obsolescence of programming languages, framework, or release version, but the real root of all evil is the technical debt that these systems bring with them. The word legacy refers to “something that has been left to us” — something we do not know how to handle. Unfortunately, this is not only caused by forgotten technologies but also by strange application designs, lack of documentation, hidden and unexpected logic, or the absence of automated tests, which are all problems that can arise even with modern technologies.
I admit that some of the most problematic applications I had to work on, and that were such a burden based on this legacy definition of mine, were written in modern programming languages and modern frameworks. Perhaps they even followed a brilliant design, and perhaps they had some serious reasons to justify their complexity. But inevitably people change workplace, position, or role; or the company decides to externalize every development. When one or more of these events occur, suddenly the application is incomprehensible and uncontrollable, which is the exact moment when a system turns legacy.
Challenges of legacy applications
For obvious reasons, working in these situations is difficult; programmers are called to intervene in systems they have no competence in, new developments are usually expensive because of their great effort, and the result is an unstable application that generates many incidents and that requires a strong support team to tackle customers’ dissatisfactions.
So, how do we handle this challenge? The cheesy but accurate answer is courage and, of course, the iterative approach of Scrum.
As I stated, the first and only enemy we have to confront is the technical debt, usually a big amount of it. I say that courage is fundamental because, in front of the great effort needed to reduce the technical debt, teams surrender even before getting started. The amount of work necessary to explore recurring incidents, enrich logs, improve performances, or analyze faulty front ends seems a mountain impossible to climb, so it is often left as is. “We have better things to do than correct a situation that has been in production for years“ is a statement I think we have all heard (and perhaps even said ourselves) at least once.
Overcoming the challenges
Leaving things as they are is completely understandable. To fix these monsters requires a lot of time, and no strategy can deny this fact. However, we can confront these beasts bit by bit, day by day, and enforce some of the good practices that the Scrum and the Agile community suggest.
Reacquire technical skills
First, we cannot understand a voice that speaks a language we do not know. The development team must be able to produce software and fix the legacy application context like any another nonlegacy application. This is the first and mandatory step. Sometimes it’s the most difficult, because it requires a lot of time that will not produce any real and measurable improvement.
After the team regains control over the code, we can really start to work on other aspects. If your project management style allows it, you can add “study“ or “training“ backlog items to your queue. Encouraging pair programming within the team could also be a smart idea.
Add mandatory nonfunctional backlog items
After (or while) we learn again how to speak with the magical beast, we have to plan our strategy. Because of the great number of things to fix, polish, remove, or substitute, we have to start gradually — but we have to start. For this reason, I recommend that you always put nonfunctional items in the sprint backlog. You can start easily during the planning meeting by putting in the queue, for example, a query optimization or an error message improvement.
Usually, competent developers know exactly all the little things that can and need to be fixed. It does not matter if those small chores do not seem like game-changers; always factor spare time in your iteration for technical enhancements, and do not allow yourself to forget about this. Be relentless. Be severe. By doing so little, something incredible is achieved: You grant yourself that your application will get better in time, piece by piece. This is the start of the healing process.
Understand the importance of test automation
One of the most challenging things to do in legacy is to intervene in old application logics for business enhancements. This fear is completely justified, because the programmer does not know the consequences of changing that “damn comma in the main engine of the software.” The only solution to this problem is a careful test strategy. This is valid if done manually, but eventually you will need to introduce test automation.
The requirement here is to have a system that can tell, at the click of a button, whether the application is working correctly after development. If such a procedure is available, the fear is gradually removed. This is the reason for planning the construction of big integration tests in every iteration (again, you can write dedicated backlog items). This also serves as documentation for future developers, who would want to see an end-to-end application flow.
Listen carefully to every application user
It is likely that your users know better than you what is wrong with the application, so you need to listen to them. It’s no big deal to do this, because every Agile project management framework reminds you to do this. Remember to listen to every user. Of course, business stakeholders are the main voice to pay attention to. However, legacy applications breed a strange phenomenon: If they produce a lot of production incidents and problems, they generate another category of users — members of the support team.
The broken nature of this software requires that these users spend significant time working on the application, and I think that the lengthy time promotes them to proud application users (and perhaps even stakeholders). If the support team is not the Scrum Team itself, do not forget to involve these individuals in your planning or backlog refinement. They are the front line, the soldiers that stand first on the battlefield, and the group that is called when things hit the fan. They know stuff; they’re not just the geeky guys in the basement. Trust them. Involve them. Analyze every incident, especially the recurring ones, and always add backlog items to correct and track all the issues that the support team encounters.
Report your success
On your own, you can hope to achieve only local optimizations and small successes. Eventually you will need to have stakeholders and all of management on board with your renovation process. This can be a real challenge, but without it, you will not have the capacity to do the “big things” that need to be done. For all of us with an IT background, it is clear that investing in this renovation is the right thing to do, but remember that a nontechnical person could have difficulties understanding why all his business enhancements might have to wait for some strange and incomprehensible programming activity.
For many, the IT department is perceived as a cost factor, not as an asset, and, unfortunately, sometimes we do little to convince them otherwise. Therefore, you must speak in a language that business people can understand. Gather data, and every time you gain control of another piece of the application, show the stakeholders what you have gained in terms of performances, user experiences, and incident decrease. Show statistics, and demonstrate to your business that you can be trusted with the application and that you can make their work better even when you talk in your IT and technical gibberish. When the stakeholders see that a real gain can come from letting the Scrum Team do the job they know so well, you’ll finally have the time to plan for the really big and crucial renovations. The right place to fight this battle is, of course, in the review meeting.
Plan the migration to the future
When all these things are achieved, you should have the time, knowledge, space, and resources to really make a difference. Learning from past errors, you should work first on the changes you want to see. The values that guide you are exactly the same as those that have been forgotten and why the application was written in the first place: knowledge diffusion, effective documentation, test automation, and developing the best solution you can afford, forgetting those bad and unhealthy work-arounds and quick-and-dirty solutions. In this situation, you will finally be able to plan a complete application reengineering, and a move to more modern technologies.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.7 (3 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.