In our previous blog, we discussed what makes a software development project succeed or not succeed. We explained why you need “The Champion” to support you and your team. This is the person who wants to modernize the original legacy application. And we showed how a Champion can make an enterprise software project an exercise in innovation and creativity embraced by the business.
Ah, but the Champion is a rare breed, and often, you must instead deal with the Champion’s doppelgänger, the Original Author (OA), as well as other roadblocks. The good news is that if you are prepared for the possible scenarios and show a little EQ, you may be able to turn an adversary into a resourceful ally.
Here are some tips for a successful software modernization project:
The OA has likely become more prominent in the business since the creation of their application. Part of your job now becomes to help the OA, and all of the business stakeholders, to start thinking about the bigger picture (like return on investment and total cost of ownership) and other advantages (like business agility, innovation and better customer experience) that your revitalized application can potentially deliver.
An experienced software developer with deep expertise of the business and of the legacy application can add a lot of value to the new solution. Ask the OA to participate with your team and give them opportunities to weigh-in. Take their ideas when it makes sense. Get their buy-in and even their excitement about the software modernization effort. Respect their input, but help them understand things must move fast for the sake of the business. The insights that can emerge from conversations happening early on can eventually lead to a better product more aligned with the current needs of the business. Be aware that there may be a tendency for company stakeholders to fall back to a mentality of “It’s the way we’ve always done it.” You should be ready with a sound rationale (focusing on big picture business benefits) for why the new approach should be adopted.
If you know from the beginning that the OA’s contribution is going to be negligible, in the spirit of collaboration, it is wise to always listen and acknowledge their feedback. If they continually put obstacles in your project path, consider how to best work with them. You may want to provide them with brief project updates, and create direct communication channels for just the current developers and any other essential stakeholders.
One way to turn the OA into a Champion? Make them a pure “stakeholder,” where they
are free from the chains of the role of Product Owner. You can do this by suggesting ways to improve the development process. Most of the time, stakeholders will need to go through the product owner to drive the development process. It’s important they don’t micromanage the backlog and are not forced to mix explicit and implicit requirements. Only what is “official” should be delivered.
Maybe YOU are the author. If so, let’s look at how you can make your life easier and
empower your business for greatness. First, give yourself a big pat on the back…You
did a phenomenal job! There were a lot of constraints, and you did the best job
possible at the time. You probably also did a lot of things by yourself. However,
while you’ve been busy with some very important things, other people have had
the opportunity to experiment and learn a lot of cool stuff you might not have much experience with because you grew up and moved into a different role.
It was fun in those early days, wasn’t it? Not so much responsibility (the business wasn’t that big, after all) and the business needed you.
But ask yourself: Isn’t it time to do something more modern, something different, for the business?
If you’re the OA trying to transform into a Champion, try to erase the past
solution from your mind. Get out of your comfort zone a little bit. You’re good, you’re talented. And everybody already knows that you can solve many problems with your expertise and tools. Challenge yourself! Try modeling with entirely new tools instead, look at different implementations. It boils down to the fact that software development is learning, and that’s where the fun is.
The frustration of leveraging legacy software and their creators is not an easily solved problem. Anticipating that they may present challenges to your software development project is the first step toward a solution. Flattery, redirection, and avoidance alone are not going to work. Decide early on whether including an OA in meetings could help or hurt your team’s progress. And recognize that the challenges they present are from unconscious behaviors and beliefs, not deliberate maliciousness. Getting their buy-in requires a softer, subtler strategy that is dependent on the players and their personalities. Include the OA in the process, (but not too much) while continually reminding them that the goal is to move the business forward with a modern software product that delivers more value, more innovation, and more ROI.
At Servoy, we have helped many companies to create strategies for success around these big discussions to mitigate risk. A good start is probably to have us take a look at your
application and talk about strategies to first accelerate and simplify this process.