Angekommen

Mein Start in die Selbständigkeit vor etwas über einem Jahr war durchaus holprig. Ich wusste natürlich, dass ich viel zu lernen hatte und rechnete auch mit dem einen oder anderen Setback. Nachdem ich im Frühjahr 2023 meinen Master in der Tasche hatte, ging ich ernsthaft auf die Suche als selbständiger Agile Coach oder SCRUM Master, und wurde auch bald bei der Statistik Austria fündig. Leider musste ich rasch herausfinden, dass die Umstände dort für mich nicht erfolgversprechend waren. Mein Ansatz des kontrollierten Kontrollverlustes – gibt dem Team vor, was es erreichen soll, und gibt ihm alle Freiheiten, *wie* es die Ziele erreicht – kam gar nicht gut an. Micromanagement und Scrum vertragen sich nicht. So folgte ich dem Grunsatz „Fail fast“ und verließ die Bundesanstalt bereits nach zwei Monaten wieder.

In den folgenden Wochen lernte ich auch, dass der Frühherbst eine ziemlich schlechte Zeit für die Projektsuche ist. Die Budgets für das laufende Jahr sind da so gut wie gänzlich verplant, für das nächste Jahr sind die Planungen dafür noch nicht in trockenen Tüchern. Das gab mir die Zeit, meinen Gewerbeschein als Unternehmensberater zu lösen. Der Plan war ja, nicht nur in der Softwareentwicklung arbeiten zu können, sondern mein Angebot allen, die an meiner Expertise interessiert sind, zur Verfügung zu stellen. Es waren dazu einige Diskussionen mit der Behörde nötig, doch im November hatte ich endlich die individuelle Befähigung in der Tasche. Ich habe nicht alles bekommen, was ich angemessen gefunden hätte, aber genug, dass ich Agile Arbeitsweisen abseits der Softwareentwicklung allen Organisationen anbieten kann, die sich dafür interessieren, und zusätzlich noch einige andere Dinge, unter anderem Datenschutz und Personalentwicklung. Insgesamt also ein sehr breites und abwechslungsreiches Feld, genau wie ich es gerne habe.

Schließlich fand ich bin zum Jahresende ein sehr spannendes Projekt bei den ÖBB, für das ich auch einen recht niedrigen Stundensatz in Kauf nahm. Es geht dabei um Modellrechnungen, mit denen die Bundesbahnen ihren Personal- und Materialeinsatz optimieren wollen. Zwei Monate lang lernte ich alles über Züge, Umläufe, Schichten und natürlich auch, was der Unterschied zwischen Bahnhöfen und Haltestellen ist. Um die Modelle kümmerte sich die Drahtwarenhandlung, Niki Poppers Firma, die auch die COVID-Modelle gerechnet hatte.

Man kann das jetzt als KI verkaufen, wenn man will, muss aber nicht. Überhaupt bemerke ich immer öfter, dass KI als Marketingargument verwendet wird, ohne dass klar ist, was davon genau eigentlich in einem Projekt steckt. „KI-Washing“ nennen sie das in der Branche. Man schmückt sich mit dem gehypten Begriff und macht abseits der schönen Präsentationen einfach sein Ding. Mir solls recht sein. Der Hype ist bereits wieder im Abflauen, wir bewegen uns auf das Tal der Enttäuschungen im Gartner Hype Cycle zu, und danach werden wir erfahren, wofür die Technologie tatsächlich sinnvoll und produktiv eingesetzt werden kann.

Die Kolleg*innen bei den ÖBB waren großartig, und ich hoffe, ich laufe einigen von ihnen irgendwann wieder über den Weg. Letztendlich wussten sie aber nicht so recht, welche Aufgaben sie mir geben sollten, und die Kombination aus schlechtem Stundensatz und schlechter Auslastung führte dazu, dass ich mich mit Jahresende wieder verabschiedete und meiner Wege ging.

Seit Anfang des Jahres bin ich jetzt bei group.one, einem großen europäischen Anbieter von Webhosting-Lösungen, zu dem in seinen Kernmärkten auch einige der bekanntesten Marken gehören. In Deutschland sind das etwa Dogado und checkdomain, in der Schweiz Metanet und in Österreich easyname und Herold. (Nein, ich bin trotzdem nicht der Herold.) Man suchte dort einen Business Analysten und Product Owner, nicht meine bevorzugte Tätigkeit, aber absolut Teil meines Angebots.

Die Branche funktioniert so, dass neben organischem Wachstum auch M&A eine große Rolle spielen, das heißt, du hast immer ein Konglomerat aus zugekauften Firmen, und die wollen in ein harmonisches Ganzes integriert werden: Produkte, Abläufe, Hostingsystem und so weiter. Es gibt hier also genügend zu tun. Das Arbeitsumfeld ist äußerst angenehm. Alle sind sehr wertschätzend, und da die Teams ganz verteilt sitzen, gibt es zwar ein Büro, aber sehr selten die Notwendigkeit, auch dort zu sein. Mir ist grundsätzlich ja beides recht, aber wenn ich es mir aussuchen kann, weiß ich die störungsfreie Umgebung zuhause schon sehr zu schätzen.

Neben der bezahlten Arbeit habe ich in den letzten Wochen auch mein Geschäft in Ordnung gebracht. Ich habe jetzt eine Geschäftsadresse und bin auch als squadrat consulting e.U. im Firmenbuch eingetragen. Jetzt fühlt es sich so an, als wäre ich in der Selbständigkeit angekommen.

Fail Fast

One time, I was asked to work in a project in an mixed role as Scrum master and requirements engineer. Many people will snub their noses at such an arrangement, and often with good reason. Mixed roles are not well received in the agile world, but for me this is right up my alley. I have a very broad set of interests and skills, and I like situations enabling me to bring as much of that skill set into play as possible.

But when I started to work at the place, I soon hit a major road block. Agility, as I understand it, wasn’t required or indeed welcome there at all.

How did I know? Well, they told me, and they didn’t beat around the bush either. “Agile is chaos,” one project manager let me know, “we don’t want that here.”

“We’ve hat bad experiences with agile work. That one team we tried it with just went about their own ways, and the end result wasn’t what we expected,” said another.

So you failed once. Not a big deal, considering that according to some sources 70% of classically managed software projects fail. Try again, fail again. Fail faster. (BTW, did you notice how this business often feels like phrasemongering? That’s because you need to repeat a few central ideas over and over, until the concept sticks in the brains of your teams. If you are starting agile work and do nothing else, choose a few crucial phrases well, try to understand the concepts behind them and stick with it.)

Of course, it wasn’t over with those blanket statements. In the course of the work, we stumbled every time the team was supposed to make a decision for itself, even small ones, like deciding on the time of day they want to have their daily. It was to be at 9 AM, come hell or high water, no input from the team required.

Why is that important? The framers of the agile manifesto had a crucial insight: People want to be helpful. They are motivated, if they feel trust and empowerment. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” I don’t know a more effective motivation killer than micromanagement, especially when working with highly qualified individuals.

And it doesn’t help if you put your team in a double bind. “These are the sprint goals, which I’ve presented to the team, and now get to work. No, don’t waste time discussing if these goals make sense at this point, or whether the goals are indeed reachable. We need to reach them, or the project won’t be done in time.”

If a thing cannot be done with the given resources, it cannot be done. Wishful thinking won’t help, and neither will additional pressure, at least not in the long run. What will help, is listening to your team. After all, it consists of highly qualified individuals you chose for the job because you thought they could do it. So why not listen to them? And you can only listen, if you give the team the room to talk. Demos, plannings and retros are the space for exactly that. There is always something to learn from them. The Scrum framework even gives you guidelines for how much time you should allow for these events each sprint.

Look, the thing is: You don’t have to do agile, if you don’t want to, much less Scrum, which can be a bit of a challenge for people who have no experience with the method at all. It’s not a law, and there are other frameworks available. In fact, don’t do it if you’re not fully committed to it, or you will end up with zombie scrum. You know, because a zombie somewhat looks like a human, but inside it’s all dead and it stinks.

Anyway, how do you deal with it if you find yourself in a similar situation? Here’s what I tried:

– Educate: Explain the advantages of agile work. Also, make the limits transparent. Agile is all about discipline in the right places, so that the team can have the freedom it needs where it counts. Don’t let a team wander off into the wilderness. Demand progress, and demand the progress to be shown. Sprint reviews are important, and so are retros. It may sound like a huge waste of time in the beginning, but the benefits will become evident if and when the team forms a habit of constant inspection and adaptation.

– Also important is strict time boxing. There is a reason why scrum will only allow 15 minutes for a daily. The purpose of a daily is not to report to the manager, and also not to solve problems. It is to identify the problems and assign them to people who are able to solve them. This will indeed work better if the time is limited.

The same ist true for the length of a sprint and the time any story is in the works. If you cannot get your stories finished in time, you might actually be better off using Kanban and focus on a limited number of items of which you have a very clear idea how long they can stay in the works. Put first things first, and the first thing to focus on in a team that doesn’t want to do agile is to make sure things are actually getting done.

– If all of this is not enough, try to find allies. This is actually a good idea in any case, but it get crucial if the resistance is too strong for one person. Your allies don’t have to be in upper management – in fact I’d rather they weren’t, agile is nothing you can impose top down – but if your conflict is mainly with a manager, you can work around them sometimes. If it’s just one or two team members, they can sometimes be swept off their feet and carried along by the developing dynamics.

In my case, that also didn’t work. The situation got worse week after week. I never got criticised for any mistakes I made, but for the things I did well and right. I could have given up on my role as Scrum master and just written up requirements for the rest of the duration, but that wasn’t what I was taken on for in the first place. So when, after two months, I was given a way out, I took it. After all, “fail fast” is another one of the driving principles of the agile approach.

How would you deal with such a situation? Help me learn an let me know in the comments.

Agil ohne Software – Geht das überhaupt?

Ich habe ja vor inzwischen über einem Jahr beschlossen, der IT vorerst den Rücken zu kehren. 25 Jahre Softwareentwicklung in verschiedenen Kapazitäten waren immer spannend und herausfordernd, vor allem, weil ich immer sehr an den Menschen und an den Methoden interessiert war, mit denen wir gute Produkte auf den Markt gebracht haben.

Letztes Jahr habe ich mit zwei Dingen gleichzeitig begonnen: Ich habe einen Abstecher in die Politik unternommen, und ich habe eine Ausbildung als Unternehmensberater begonnen. Es war klar, dass ich nicht längerfristig im Grünen Parlamentsklub bleiben werde. Die Möglichkeit, eines meiner Herzensthemen auf der ganz obersten Ebene mit zu betreiben, war ein Jugendtraum, den ich mir erfüllt habe. (Andere Leute kaufen sich, wenn sie 50 werden, vielleicht ein Motorrad oder ein schnelles Auto, aber das hat mich nie so gereizt.) Natürlich bin ich dem Klub sehr dankbar, dass sie mir diese Chance gegeben haben. Ich vermisse Euch!

Das ist jetzt aber zu Ende, und vor ein paar Wochen habe ich ein Gewerbe als IT-Consultant und Unternehmensberater angemeldet. Warum Unternehmensberatung? Continue reading “Agil ohne Software – Geht das überhaupt?”