When your solution uses old tech, it's challenging to keep a modern mindset with the processes that surround it. However, keeping your processes up-to-date can really help to keep you motivated and remind you that even though the tech stack is old, you can still innovate and keep pushing forward. Here's how I keep my processes up-to-date as well as some tips and tricks that I use to keep myself on my toes.

When I started out in my first job, I was put into a space that I found familiar at the time. I dealt with all of the waterfall methodologies that the professor harped on about, married with the lack of documentation and communication issues we were warned about. I thought that this is what software development was all about: trying to work with logical solutions in an illogical business environment - and boy was I wrong!

This was made painfully clear when I realised that the tech stack was falling further and further behind as new ways of doing things came out each year. As I grew as a developer, I started having to take responsibility for failures - which of course meant working on solutions to help prevent them. This gave me space to start questioning the methods that I was using - since questioning the tech stack was, well, out of the question.

I was very lucky that my team was very small because this allowed us to break the norm and try something different. The first thing we changed was allowing the client autonomy by asking them to set the priority of the work that needs to be completed. Once the client had to prioritize work themselves, they started to:

1. Realise that changes don't happen at the drop of a hat, and
2. Think critically about requested changes which resulted in them throwing out a lot of them, or at least marking them as "nice to have" rather than "critical".

Once the workload was neat and prioritized, we tried out a KanBan approach, organising tasks into swim lanes and "backlog", "doing", "testing", and "done" columns. Unfortunately, we quickly found that the client resorted back to old tactics of slipping in "small" tickets and thinking that it wouldn't push out larger tickets.

This inevitably led us to the approach that we currently follow: Agile ceremonies with planned, two-week sprints that allow some space for the client to slip in smaller items. This supports their need for mobility, while satiating our need for realistic timelines and kept commitments.

Now it's one of my top priorities to ensure that my processes help me do better work. Here's how I do that.

Continuously evaluate your processes

If you have the ability to adjust your process to something more modern, it still wouldn't help if you didn't re-evaluate the entire process around your workflow. You need to continuously identify where current processes are "shooting you in the foot", because often we are so busy trying to see if we can, that we never stop to ask ourselves whether we should. If you've been doing the same thing day in and day out, pushing code at the same rate, you need to spend a minute and evaluate whether there might be a better way. I like to ask myself questions like:

• Is there some way to alleviate big pain points?
• Is there some way to streamline things that usually take a long time to complete?
• How do your teammates go about completing their tasks? Is there a different way you can work together to achieve better results?
• Are there certain tasks that can be automated to free up time and resources?

These changes cannot be implemented overnight, because we often work in spaces with larger or interdependent teams. That, however, doesn't mean that change is impossible.

A personal mantra that I always keep in mind is "Stay curious and willing to try new things". Never think that something doesn't apply or is too different to try out.

You won't know whether it works for your team until you try it out. Not to mention that, when you move onto a different project, it won't be the jarring and harrowing experience you might expect if you have focused on not letting yourself stand still - even if your tech stack did.

In taking this time, you will slowly but surely create a team that is not bogged down by unnecessary processes and instead able to remain highly effective. The time taken to evaluate your processes will pay off in the overall improvement to your workflow a thousand times over.

Updating your mindset and your knowledge

Keeping up-to-date allows you to remain current despite working on archaic technology, but it also helps you keep motivated and passionate for technology as a whole. It's like eating oats, if you eat the same oats every single morning, soon enough you will hate them. But if you change it up every now and then with different flavours, like banana and honey, you will find that you enjoy it for longer. This effect will benefit you and your team because passion drives productivity - especially if it's chased by the whole team.

By taking a look at what other teams and the wider tech world are getting up to and gaining knowledge of new trends, you can get so many new ideas for processes that your team can try out. This is important because the world is always changing and new ideas around existing things are always cropping up, even if you don't necessarily see how that knowledge will benefit your solution immediately.

I've found that the following things help me to stay up to date and achieve this new mindset.

Find inspiration

As great as a mind can be, ideas are sometimes finite within the confines of your own mind and you need to look to rest of the world for inspiration. As Forrest Gump said, "Life [is] like a box of chocolates, you never know what you're gonna get." The same goes for processes and ideas - until you look into the 'box' of what other people are trying you won't know what is out there.

I recently found myself immensely inspired by the team structures that the Azure DevOps teams are trying out, even though my own team isn't on the same scale, or even in a similar solution space. They use digital boards to organise their workload and sprints, but also to provide visibility to the stakeholders outside of their team. They also put a lot of thought into little things that might affect team morale. For example, for team names, they use the first letter of the type of space they work on so that no team appears better than another. The integration team would be named Team I, the core team would be named Team C and the front-end team would be named Team F.

Since we moved to a new office space, I found myself in a situation where we didn't have any sort of space for the physical boards that we were using for KanBan planning. I spoke to my other teammates about the problem and my team lead suggested making use of the Azure DevOps boards. We haven't yet figured out how to use them, but it's available to us and it's looking to be viable replacement.

Find resources

Our world is a strange and wonderful place - ever changing and ever evolving. There is always something new popping up in the most unexpected places and, even if you think you've read every article, there will always be more information in other places. Our KanBan approach, for example, was inspired by processes used in manufacturing factories. On the surface the two spaces seem completely unrelated, but skills and ideas are usually transferrable.

There are many resources available to help you, from internal company training and guilds, to publicly available forums, online courses, blogs and articles. Inter-team communication is also a great source for finding more team-relative information and ideas. For example, our team lead attends an internal Agile guild which meets every two months or so. Everytime he returns from these meetings, he has new ideas or new ways of seeing old problems and we sometimes end up being guinea pigs for new office experiments. Other times, when we don't agree with the new idea, I find that just having a different perspective helps the team understand our pursuit of effectiveness better.

Try new methodologies

With all of these new ideas that you and your team have gathered, you might be excited to try out new methodologies but not fully buy into them for various reasons: In some environments there might be red tape preventing you from making certain changes or other requirements that need to be kept by that clashes with new methodologies you would like to try.

That's why it can be useful to only take certain portions of it and leave others that are harder to implement or maintain. For example in my current environment, there are stringent requirements around information security that made the adoption of automated builds very slow to non-existent. We are making progress to prove that it would benefit the teams by automating sections of the solution the client is comfortable with.

Taking only partial ideas around a process could also prove to be somewhat dangerous: I've been in a situation where the company that I was working for told their clients they ran an "agile" house. In practice, however, all this meant was that there were small release windows with no management in terms of how tickets were prioritised or completed. There was also no responsibility assigned in terms of what needed to be completed by each individual, and people were just told to "take care of" a particular client.

This caused a perfect storm. I was running nightly updates on various clients for work completed during that day, while also trying to fight fires caused by unhappy clients who were waiting for us to get to their priority items. On a micro-scale, this meant I lost around 3-4 hours daily to maintaining terrible processes. On the macro-scale, it meant that we lost confidence in our abilities while disgruntlement became prominent within the team itself.

Once I identified these issues, I set out to change the process. Since the company's management already bought into the idea of Agile practices, I set out to implement it properly:

1. I started with short stand-ups that I initially called "check-ins": At this point in time everyone on the ground was very averse to any agile terminology because they believed that it didn't work.
2. The check-ins were followed by a physical board: I introduced this as a solution to the problem of people forgetting what they planned on doing yesterday or today.
3. Soon after this, I started roping the clients into weekly planning sessions: We discussed proper prioritisation and sizing of the week's items together. This also allowed space for us to plan weekly system releases rather than near-nightly ones.
4. The last thing I did was to introduce retrospectives: This was the first clearly Agile practice, which revealed to everyone how our new working processes truly were Agile. These retrospectives were the linchpin in the process as outlined later.

This experience taught me that I needed to be brave enough to try new things. You will only know whether something is better or worse in your work space by trying it out. Even if something looks like it won't work, don't be afraid to try it and fail. Fail early, and fail hard. In doing so, I can guarantee that you will learn something - even figuring out what doesn't work for you is learning something.

Be patient! Sometimes it takes time to get people on board with a new way of working, but persistence and knowledgeability is key.

If you know what you're talking about and talk about it often, slowly but surely, people will start backing you up. People are sceptical of change, but the more you talk about it, the more familiar it starts to feel which allows them to have a little bit of optimism. That spark of optimism is usually all you need to get a foot in the door.

Do retrospectives

I highly recommend following the practice of retrospectives on a regular basis. This will allow you to not only get feedback from your own team mates, but also to keep improvement on everyone's minds constantly. My team has a set meeting slot where each person answers three questions:

• What is working?
• What isn't working?
• Is there something new that is worth trying out?

This approach creates a space for everyone to be involved and also allows for crazy, new ideas to be brought to the table and discussed.

In certain instances, retrospective meetings can be expanded to include people from other teams, especially when a process regarding a team dependency needs to be be improved. This, of course, also opens the door for discussions which aim to help other teams improve their own processes. These interactions can build relationships between teams which, in turn, will also improve collaboration between the teams.

Always remember: It is imperative to remain objective with issues that are raised. Never point a finger, only raise hands with ideas that can help.

In short, this entire strategy for keeping your processes up-to-date can be summed up in this downloadable cycle. Check whether your current processes are working for you, find new processes, try these new processes and then check whether the new processes are working or not. And then rinse and repeat. Good luck for your own journey - I know that I have enjoyed mine and that I will continue to!

Resources

• Scrum User Group South Africa for monthly meetups
• Agile Alliance for Agile resources and information
• Udemy course on Software Methodologies
• Becoming a Better Programmer - Pete Goodliffe
• Implementing Lean Software Development - Tom Poppendieck, Mary Poppendieck

Gertruida is currently working as a Senior Software Engineer at Entelect. She has mentored at the past three, annual Girl Code Hackathon events and is actively involved in initiatives to share knowledge with women and girls in the tech space in order to close the gender gap. She completed a BSc IT degree at University of Johannesburg.