Ok, I'll explain the title a little later. Let me start with a little bit of background, so you might understand me and the title better.

Some of you might have read my blog where I mentioned I deal with some sicknesses. One of those sicknesses is depression. I have this depression quit some time now. Mostly it comes in the dark month of the year and it is pushed by external influences, like e.g. bad experience at work.

Over the years of treatment and talking about it I learned some strategies to deal with this downward spiral. E.g. like go on walks on sunny winter days or use light therapy or talk about my thoughts and feelings in a support group. And especially have adopted a strategy from someone who suggested a treasure chest with success stories. In this treasure chest I put success stories I had in my life and where I felt happy and complete. With this stories I can counter the feelings of failure with a success story. Lately I had that feeling of failure at work a lot.

But one of my treasure story is actually not a story it is a bunch of videos on Youtube. There are some very good teaching videos on YouTube from the late Vera Birkenbihl. Here is a little background on Mrs. Birkenbihl. She was a Management Trainer and Behaviour Change Expert.

Whenever I have bad feelings these videos reminded me, on a core principle of our existence: "We have the power of our thoughts."
With our thoughts we can control our feelings and control what we do about it. You are not powerless, you can change it.

So I took the time over the holidays and quite some time after that, and thought long and hard why I have these feelings of failure at work. And I found two reasons for those feelings and how I should deal with them ASAP. And ultimately revealed the sentence I choose to use as my blog title: "Love to fail (at work) or fail to love (your work)".

Well, you might be curious and ask, so what went wrong at work. I don't want to leave you hanging and give you a glimpse into the backgrounds of my failure feelings.

Since a couple of month I'm responsible for three Agile Teams. These teams work at a large project at a major car manufacturer on different parts of the contract. And these teams work for different departments at this car manufacturer. So that means they have different responsible PO's. That means with that, there are a lot of different rules, requirements and other difficulties for the teams.

Eg. one Team's PO actually likes agile SW development and Scrum a lot. He/she and the Team do a very good job applying Scrum guidelines. But since the Team setup is a little bit odd - Devs and Ops and Customer Support Agents mixed together as one Team and called DevOps -, this setup causes a lot of not so agile work patterns and changes to the "normal" Scrum process.

In case, for example, the CSAs are overwhelmed with customer tickets, the Devs and Ops guys have to drop everything and do CS tickets. We talk here about mostly simple tickets, like reset password or extend my account, aso.. And of course this kind of work for the Devs is not tracked in anyway on the Scrum Board via a special ticket with some default Story Points. This work the Devs do is simply hidden work they have to do but don't get credits for in the form of velocity. Velocity is only tracked for actual Dev work. The Devs have to do this kind of not "plannable" work, but it is expected to full fill the Sprint Commitment. This is mainly because the CS "part" of the Team is understaffed and sometimes cannot do all the work. So it falls back to the "Rest" of the Team to help out. In those cases, most of the time the sprint goal cannot be achieved.

Or another example. The Ops guy, ja there is only one - also understaffed for a 24/7 service -, has to do all the changes for production and test environments. No Dev is allowed to help out, cause he is the sole person who has the authority to communicate with the WebOps guys in India directly. You probably already guessed, every change has to go trough India to be put on production/test machines. So if this Ops guy is sick or had a long work night with a change. Every dev ticket, and he has regular dev tickets (Build Pipeline, Cloud Maintenance on the Dev environments, aso) in the sprint, too, are delayed as reason of that. And so the Sprint Goal is sometimes also not achieved.

Alright, so I tried for over a month now to rise awareness at our Management that this Team setup is bad and it will get even worse when we are held accountable to actually deliver the 24/7 CS. The Team structure and how work is organised needs IMHO to be change ASAP or at least analysed, so we can adjust it accordingly, so the Team can work better, with less interruptions and conflicting work.

But every talk I have, every e-mail I sent, there are only answers like that: "Yeah you're right, but we can't do that.", "There is no time to change it.", "There is no budget for more personell." or "The customer doesn't want that. The system as it is now, works for the customer." or the all in one killer argument "Never change a running system!"

These kind of answers are very frustrating for me. It is hard on me to know there is something wrong, but you do not have the power, the right connections or maybe the right charisma to change something in the system and that gives me the feeling of failure.

The second example is from the other Teams. They work for a different department. This department says they do Scrum and organise their work in Sprints, but in fact they do Waterfall with feedback in 4 weeks cycles, and of course with a lot of politics, delays on delivery of information and testing and of course a lot of spontaneous "We need this fixed immediately" sprinkled in.

So since I'm the Scrum Master for these teams, I never saw the Teams successfully complete a sprint because of that. Best result was 65% of the Sprint Goals. And I'm sure that it does not fall back on the performance of the teams.

The Customer PO does not know what agile SW development means and he/she does not want to be educated in that regard. E.g. for him/her a sprint in Jira is not planned work in a defined amount of time with a deployable deliverable. For him/her it is a work order for a period of time. And he/she can change the work order whenever he/she likes it or sees the necessity. Of couse he/she think they pay the bill so it can be done like that. No care if the team agrees to the change, no care what the velocity for the teams are, no care if all of the members of the teams are available, no care if starting and stoping work is hurting feature progress, no care if re-prioritisation causes ("politicly") promised features to get delayed.

And there are more things the PO is very reluctant to change. Switch to cloud based test environments or feature based tests and releases. No, it has to be a snow-flake environment for testing. Testing is only done before the quarterly releases. Yes, there are acceptance tests at the end of the sprint, so we get tickets closed and get paid, but that doesn't mean anything for a release, since most of the time this is done not done on a stable and defined environment. Means even if the feature is accepted, cause it works on the current test environment, it doesn't mean it work two month later for the Quality Gate Test before a release. Hence Devs have to work overtime before a release to fix those bugs, which where most of the time introduced after the acceptance of the feature or because something changed on the snow-flake environment, eg. DB changes they didn't know. And you guessed it, automatic testing is not a Prime citizen in this setup. So there are only a hand-full of Smoke tests. The rest of the tests are done by manual clicking stuff to do end to end tests.

Well I hope you can imagine, that I tried over an extended period of time to change many of those things or at least make them aware of the problems they cause, but in my position and working in a Customer / Service Provider setup, I was not very successful. Same problem/answers as before with the Scrum team. So this all is very frustrating for me and because of my helplessness a source of failure and for my bad feelings.

Anyway enough with the bad work experience, the main goal of my blog was to explain the title "Love to fail (at work) or fail to love (your work)" and why I think this is a good guideline. With the help and the reminder of the Vera Birkenbihl's videos, I found out, that it is noting bad if I fail at those projects. Actually it is a good thing that I fail and I have to love the fact, that I fail, cause that gives me the freedom to accept that I cannot change anything in the current setup. So I shouldn't invest to much time and energy into it, if the customer is happy and my employer is happy, why should I fight and be unhappy. And with this acceptance, I found more freedom to look for things I love to do, things I want to do, things I can control.

So for a long time I wanted to explore the Jira Rest API and what you can do with it. And since I'm a somewhat decent python programmer, I started developing a python program which extracts information from Jira Tickets and do analytics and reports on them. And what was the good thing about that is, I learned also the Confluence Rest API, to publish the Sprint and KPI reports for our teams. And that made me happy.

And since the Python program is almost done, only some fine tuning, refactoring and documentation needs to be done, to be completely finished. Hence I started to look for more happy things to do. And I picked to explore the RSS feature of Jira. This time I want to use Node-Red and a no-sql database to publish changes in MS Teams with a webhook. I decided to do it with Node-Red, since I use Node-Red at home for my Weather Dashboard and it is spectacular what you can do with Node-Red. Ja, another happy little project at work. But details about these projects might be some future blogs.

Ja, so I hope you understand now a little bit the background and the meaning of the title. I learned to love to fail at work, so I could start to love other things I can do at work. And with this new feeling, my depression was not as bad as in the years before and I could manage without medication and emergency help. And that made me happy, too.

As always apply this rule: "Questions, feel free to ask. If you have ideas or find errors, mistakes, problems or other things which bother or enjoy you, use your common sense and be a self-reliant human being."

Have a good one. Alex