I can remember plenty of occasions that have caused me stress over the course of my career in IT. I’ve always felt more stressed when I’ve felt there are things I can’t control and having looked into the matter a bit it seems I’m not the only one.

In 2008, Dr. David Rock, a neuroscientist who specializes in neurological health in business, introduced a cognitive model called SCARF which he described as “a brain-based model for collaborating with and influencing others.”

SCARF stands for:

• Status – our relative importance to others
• Certainty – our ability to predict the future
• Autonomy – our sense of control over events
• Relatedness – how safe we feel with others
• Fairness – how fair we perceive the exchanges between people to be

According to Dr Rock, our key objective should be to minimize threat and maximize reward.

Threats are essentially anything that happens which makes us feel negative emotions; think everything from fear and sadness to anxiety and depression. Threats trigger the release of cortisol – also called the “stress hormone” – in our brains. When this happens our bodies react by redirecting blood from the brain to the muscles; we experience less creativity, generate fewer new ideas, and tend to focus solely on the here and now.

Rewards, on the other hand, trigger a release of dopamine in our brains which generally has the opposite effect on the body. Blood flow is directed toward the brain, creativity increases, we are able to generate new ideas, and are able to focus on the bigger picture.

Autonomy: Regaining control

According to Dr. Rock, “Autonomy is the perception of exerting control over one’s environment; a sensation of having choices. Mieka (1985) showed that the degree of control organisms can exert over a stress factor determines whether or not the stressor alters the organism’s functioning. Inescapable or uncontrollable stress can be highly destructive, whereas the same stress interpreted as escapable is significantly less destructive. (Donny et al, 2006).”

As an SAP developer or operator, it’s not uncommon to feel frustrated or stressed by the seeming lack of control you have over the overall production outcomes of your projects. You might write a great piece of code, but the production system fails due to something completely beyond your control, leading to an extremely costly outage.

And if you’re working in a waterfall development system, you have the added stress of knowing that by the time you finish the project the business needs of your customer might have changed, making the work you spent so much time on less relevant, or perhaps even completely unnecessary.

Regaining at least some autonomy – some control – in your development process can significantly reduce your stress.

Waterfall ABAP Development: Stressful Memories

When I was working as an SAP ABAP developer our implementations followed the waterfall methodology, meaning development projects lasted years and involved IT teams from different suppliers, sometimes numbering over 100 people. Each team was working in the same system landscape, but were siloed apart from the rest of the project.

SAP’s transport management system (CTS) provides a locking mechanism for code changes in the source development system, but once the transport is released, the lock is lost, along with certainty and control. My code change is unprotected – someone else comes to make a change to the same object, and is able to do so without any warnings or way of knowing that the object has already been changed. My change may or may not have been transported to the target system yet, and another developer then changes the code and releases it.

There are so many issues with this process which would lead to the Production system failing once changes are deployed. How do we even know which transport is going to get transported first? Will someone else’s precede mine, with my code overwriting theirs and their change being lost? Did my transport contain a dependent object, newly created in the target system, whereas their transport only contains the object which uses that dependent object (in which case if their transport goes first it will result in an error)?

For our landscape, the list of transports sent to the Basis team was often in a spreadsheet or email and the order may not have been correct. Even worse, it might only have consisted of my team’s transports and not all transports from all teams. This can lead to confusion and an incorrect sequence and/or incomplete list of transports being imported into the target system.

When these things happen, problems occur – often in QA, but in the worst cases in Production – and remedial firefighting is required to correct the situation. Now you must unpick the change, working out from version control and “whereused” searches what should have been promoted instead, in order to build the correction and resend it.

This break in Production, followed by further delays in releasing the project, can impact how you feel in relation to others. You may have not been directly responsible for the problems, but you may no longer feel like you are an important member of the team or perhaps that your coworkers or supervisors are unhappy with you. Your Status and Relatedness have been dented.

How are others impacted? The other developer probably feels the same as you, and the owner of the source system and the users of that system are all affected, through no fault of their own. Both you and the other developer’s perceived Fairness of the situation may be impacted.

Cortisol (remember: this is the stress hormone) is probably running high across the entire organisation by this stage.

Automation: Regaining Control

Back then I heard of a tool called Transport Express, created by a company called Basis Technologies (yep – this very one). I thought it sounded great, so I convinced my project manager to get Basis Technologies in to provide a demo. This cemented my impression and I tried my hardest to get management to invest in the tool. However, as a developer, I didn’t have the skill set to come up with a business case and only had my gut feeling to go on. Sadly, I wasn’t convincing enough.

And then guess what? A few months later disaster did hit in the form of a bad project deployment which put the target system out of action for a couple of weeks, resulting in a hefty cost and a considerable amount of the stress I was trying to help us avoid.

Transport Express is now called ActiveControl and I lead the team who develops it. As the name suggests, it’s a tool that gives you control over your SAP development systems. With that control, you are reducing risk and uncertainty, thus avoiding the threat of a bad deployment and rewarding you with success.

ActiveControl is designed to give SAP developers and operations teams more control of their landscapes. Instead of stressing about changes made outside of your control that might break Production systems, you can work confidently knowing that the changes you and your team make will be tested and checked before they go live.

If something does break once it’s deployed, you can also backout transports so you can quickly get systems back up and running while you fix the problem (rather than dealing with the stress and pressure of finding a fix while systems are offline). Ultimately, implementing ActiveControl helps you shift your SAP development left and move from outdated, inefficient processes to more agile, adaptable, and efficient ones.

Are you ready to see for yourself how impactful ActiveControl really is? Reach out to our experts today to schedule a personal demo of the software where you can ask questions and talk with our team about how to overcome your own SAP challenges.