Wie können wir helfen?

Über uns

Karriere

Kontakt

Blog

Staffwerke

Beschreibt einen Tag im Leben eines SCRUM-Masters. 

Follow a day in the life of one of the most useless people in a software project. Only available in German.

Hi, mein Name ist Peter (*Name und Handlung sind frei erfunden). Ich bin einer der überflüssigsten Personen, die du je getroffen hast. Wie du dir vielleicht schon denken kannst, bin ich ein zertifizierter Full-Time Scrum Master. Mein Beitrag, den ich jeden Tag in meinem Unternehmen leiste, ist 0. Jeder weiß das, aber keiner tut etwas. Ich nehme dich heute mit und zeige dir, was ich jeden Tag tue (oder auch nicht tue). Viel Spaß beim Lesen. Ich hatte viel Zeit diesen Artikel zu schreiben. 

**06:30 Uhr:** Der Wecker klingelt, und ich springe voller Enthusiasmus aus dem Bett – bereit, die Welt des agilen Arbeitens zu revolutionieren. Oder zumindest so zu tun, als ob.

**07:00 Uhr:** Nach einer schnellen Dusche und einem noch schnelleren Frühstück öffne ich meine Inbox. Vielleicht gibt es ja eine dringende Frage von einem Teammitglied, die nur ich beantworten kann. Spoiler: meistens nicht.

**08:00 Uhr:** Das tägliche Stand-Up-Meeting beginnt. Ich frage, wie jeden Tag, die Entwickler nach Updates. Auch wenn das überhaupt keine Auswirkung auf irgendeinen Prozess hat. Agile Buzzwords fliegen durch den Raum. Ich bin zufrieden.

**09:30 Uhr:** Nach dem Meeting ist vor dem Meeting. Ich verbringe den Vormittag damit, weitere Meetings zu organisieren und sicherzustellen, dass alle pünktlich erscheinen. Denn was wäre ein Tag ohne Meetings? Aber die Hauptsache ist, dass alle Meetings maßlos überzogen werden. 

**10:00 Uhr:** Ich verbringe eine unnatürlich hohe Zeit auf LinkedIn um zu ,,engagen'' und mich zu vernetzen. Warum? Damit ich endlich das ,,Top-Voice-Badge'' erhalte und mir diese extrem qualifizierte Auszeichnung über meine ,,Cross-Functional-Leadership''-Zertifizierung auf meinen Lebenslauf zu packen. 

**12:00 Uhr:** Zeit für ein ausgiebiges Mittagessen mit meinen Kollegen. Wir unterhalten uns über belanglose Dinge und versuchen, den Gedanken zu verdrängen, dass wir eigentlich viel produktiver sein könnten.

**13:00 Uhr:** Zurück im Büro geht es weiter mit dem Verhindern von produktiver Arbeit. Ich störe meine Teammitglieder bei ihrer Arbeit, um sicherzustellen, dass sie auch wirklich nach dem Scrum-Leitfaden arbeiten – schließlich müssen wir agil bleiben!

**17:00 Uhr:** Der Arbeitstag neigt sich dem Ende zu. Ich fühle mich erschöpft, aber auch unglaublich erfüllt. Schließlich habe ich wieder einmal bewiesen, dass ich als Full-Time Scrum Master absolut unverzichtbar bin – zumindest für mein eigenes Ego.

**18:00 Uhr:** Feierabend! Zeit, nach Hause zu gehen und mich auf einen weiteren Tag voller sinnloser Meetings und agiler Buzzwords vorzubereiten. Wer weiß, vielleicht werde ich irgendwann wirklich etwas Sinnvolles tun – aber bis dahin werde ich weiterhin so tun, als ob.

Klingt lustig, ist es aber eigentlich gar nicht. Natürlich wollen wir nicht alle über einen Kamm scheren und nicht jede Scrum Master Position als redundant erklären. Wenn aber nur auf das Durchziehen agiler Frameworks und damit verbundener Positionen geachtet wird, befinden wir uns nicht automatisch auf der Zielgeraden. Tatsächlich besteht die Gefahr, dass ein Scrum Master, der nicht richtig eingesetzt wird, die Effizienz des gesamten Entwicklungsteams sogar beeinträchtigt.

Ein Full-Time Scrum Master sollte keine Position, sondern eine Rolle sein, die innerhalb eines agilen Teams aufgefangen wird. Sobald diese Rolle wirklich als Vollzeit-Position bekleidet werden muss, laufen in dem Unternehmen ganz andere Dinge schief. Ziel sollte eher sein, sich als Scrum Master selbst fast überflüssig zu machen, damit das Team selbstständig arbeitet. Ein Daily wird nämlich genau dann überflüssig, wenn sich die Projektmitarbeiter sowieso im Austausch miteinander befinden. Hierbei sind dann Milestones und Sprints viel wichtiger, als hart vorgegebene Prozesse. 


>Quote Agile Prozesse sollen am Ende immer noch Sinn machen und nicht auf Biegen und Brechen einfach durchgezogen werden.

Unternehmen dürfen nicht nur auf die Oberfläche schauen und denken, dass das Einhalten agiler Prinzipien automatisch zu besserer Produktivität führt. Vielmehr muss darauf geachtet werden, dass der Scrum Master eine unterstützende Rolle einnimmt, die das Team befähigt und unterstützt, anstatt es zu beeinträchtigen. Effizienz sollte immer im Mittelpunkt stehen - und das bedeutet, dass wir manchmal über den Tellerrand hinausschauen und kritisch hinterfragen müssen, wie wir agil arbeiten. Sonst laufen wir Gefahr, in einem endlosen Kreislauf aus Meetings und Buzzwords gefangen zu sein, ohne dabei wirklich voranzukommen.
Und wenn du dich dabei nun auf den Schlips getreten fühlst, dann denk drüber nach warum. Wir wollen dir nichts Böses, sondern haben vielleicht einen Nerv getroffen. Aber Einsicht ist ja der erste Schritt zur Besserung 😉

Day in the Life of a Scrum Master

Ein Tag im Leben eines SCRUM-Masters

Ein fundamentales Missverständnis in der IT-Branche.

Stell dir vor, du versuchst, Fußball ohne Füße zu spielen.
Unmöglich, richtig?
Genau das versuchen Low-Code und No-Code-Plattformen in der Welt der Softwareentwicklung zu sein.
Sie versprechen Einfachheit und Schnelligkeit, sind aber selbst bei einfachsten Anforderungen überfordert.

Die harte Wahrheit über Low-Code und No-Code:

Die Vorteilsversprechen sind eine Lüge!

Low-Code & No-Code-Plattformen verkaufen die Idee, dass jeder ohne tiefes technisches Wissen Software entwickeln kann.
Doch das ist so realistisch wie Fußball spielen ohne Füße.
Diese Systeme bieten eine Illusion von Effizienz und Flexibilität, die sie in der Praxis einfach nicht liefern können.

Die bittere Realität:
Es gibt keinen echten Anwendungsfall, in dem Low-Code oder No-Code eine sinnvolle, nachhaltige Lösung darstellt.
Was als schnelle Lösung beginnt, endet in der Regel als langfristiger Albtraum.

Es gibt eine Ausnahme:
Lern-Software, mit der Kinder programmieren lernen sollen.
Das funktioniert richtig gut.

Wenn du echte Probleme zu lösen hast, vergiss die vermeintliche magische Pille der Low-Code- und No-Code-Lösungen – sie sind eine Illusion, die letztlich nur Bauchschmerzen verursacht.

Low/No Code vs. Softwareentwicklung

Wie du die Elite der Softwareentwickler für dein Projekt gewinnen kannst

Learn how to win over the creme of software developers for your project. Only available in German.

Es gibt eine einfache Wahrheit in der Tech-Welt:
Die besten Entwickler, die Elite der Branche, bewerben sich nicht auf Stellenanzeigen!

Wenn überhaupt sind sie bei den Big Playern, wie Google, Microsoft oder Apple angestellt.
Diese Giganten locken mit herausragenden Arbeitsbedingungen und führenden Technologieprojekten.
Genau das lieben Entwickler-Rockstars.

Was bedeutet das für dich?
Wenn du die Besten der Besten für dein Projekt gewinnen willst, vergiss konventionelle Methoden wie Stellenanzeigen.

Um die Elite zu erreichen, musst du strategischer vorgehen.
Modernes Netzwerken ist der Schlüssel.
Engagiere dich in der Tech-Community.
Baue echte Beziehungen auf.
Zeige, dass auch dein Projekt spannende Herausforderungen bietet.

#Realtalk
Das wird nicht von heute auf morgen funktionieren.
Unser CTO macht das jetzt seit 20 Jahren.

Du musst jetzt aber nicht verzweifeln.
Wenn du nicht die Zeit und die Ressourcen hast, solche Netzwerke aufzubauen, kommen wir ins Spiel.
Staffwerke ist darauf spezialisiert, genau diese Elite-Entwickler zu finden und für dich zu überzeugen.

Wir schicken dir nicht nur einfach einen Entwickler.

Wir stellen dir (d)ein Top-Elite-Team zusammen und entwickeln dir die maßgeschneiderte Software, die du brauchst – individuell & effizient.
Exklusiv aus unserer Entwickler-Boutique.

Spar’ dir die Mühe, unzählige Bewerbungen zu sichten oder auf Netzwerkveranstaltungen zu hoffen.

PS: Unser CTO? Ein wahrer Rockstar. Und was kennen Rockstars?
Genau, andere Rockstars. 😉

High-Profile Software Developers

Elite-Softwareentwickler

Was die Personalplanung mit dem Unternehmenserfolg zu tun hat

Nehmen wir mal an, wir sind der Mensch innerhalb eines Unternehmens, der ein Projekt plant und staffed. Der Zeitplan ist klar, die Anforderungen auch und wir wissen, dass wir 5 Personen brauchen. Diese 5 Personen werden intern oder auch extern eingestellt und fangen nun mit ihrer Arbeit an. An Projekttag 7 wird einer der Mitarbeiter krank und fällt für zwei Wochen aus. An Projekttag 12 geht ein anderer Mitarbeiter für drei Wochen in den Urlaub. Nach vier Wochen kündigt ein weiterer Mitarbeiter. Autsch. Hier brauchen wir nicht mal ein BWL-Studium um zu erkennen, dass der Projekterfolg massiv gefährdet ist. Mit nur 20-40% der ursprünglich geplanten Kapazitäten können wir niemals den Zeitplan einhalten. Die Stakeholder oder Auftraggeber, ob intern oder extern, werden wohl nicht sonderlich erfreut sein. 


>Quote Wir müssen aufhören, Projekte zu knapp und naiv zu planen. 


Was auf der Hand liegt ist, dass das Projekt von Anfang an falsch geplant wurde. Wir hätten eindeutig mehr Mitarbeiter als Backup benötigt um das Projekt nicht zu gefährden. Natürlich wissen wir alle, dass es Budgets gibt und nicht beliebig viele Mitarbeiter eingestellt werden können. Aber der Moment, in dem wir wirklich viel Geld verlieren ist der, wenn uns die zu engmaschig geplante Kapazität ausgeht. Wenn wir von Anfang an einen gewissen Puffer eingeplant hätten, würden wir 

- A, nicht in die Situation kommen, dass unser gesamtes Projekt weder in-time, noch in-budget noch in-quality geliefert wird,

- oder B, das Projekt schneller fertiggestellt wird und wir die Ressourcen wieder freisetzen können, z.B. für andere Projekte.

Ab dem Moment, in dem wir asap weitere Projektmitarbeiter brauchen, verbrennen wir extrem viel Geld für den Hiring- und Einarbeitungsprozess. Denn selbst wenn wir einen Projektmitarbeiter finden, der übermorgen anfangen kann, geht die Wahrscheinlichkeit, dass dieser Mensch dann auch noch wirklich was drauf hat und sich schnell in das Team integrieren kann, gegen 0. Und nun meinen wir, dass solche Szenarien selten passieren. Aber weit gefehlt. Das ist ein Standard-Szenario. 


>Quote Es gibt One-Man-Shows, die für die Entwicklung eines gesamten Systems alleine verantwortlich sind

Selbst in Großprojekten bei Milliarden-schweren Konzernen werden Projekte so besetzt, dass sie schon fast geschäftsgefährdend sind. In Software-Projekten ist es durchaus üblich, dass ein einziger Entwickler für die Programmierung einer gesamten Software alleine verantwortlich ist. Unverantwortlich? Ja irgendwie schon. Denn auch dieser eine Mitarbeiter wird mal krank, geht in den Urlaub oder wechselt das Projekt. So ergeben sich immer wieder neue One-Man-Shows und die Konsequenz bei den vielen Wechseln ist immer ein erheblicher Know-How-Verlust. Wird nun die Software sukzessive ausgerollt und irgendetwas funktioniert nicht, gibt es niemanden der von jetzt auf gleich das Problem lösen kann, weil es hochkomplex ist und ein neuer Entwickler teilweise Wochen braucht um den Code zu verstehen. Von der Personal- und Projektplanung hängt also, auch wenn es oft nicht erwartet wird, der gesamte Unternehmenserfolg ab und sollte deswegen immer als eine der obersten Prioritäten betrachtet werden. 

Personalplanung und der Unternehmenserfolg

Warum externe Softwareentwickler nicht zu teuer für dich sind 

🕤 Morgens halb zehn in Deutschland – 5000 Unternehmen suchen Softwareentwickler. 4999 davon machen bei der Suche gravierende und extrem teure Fehler!
Der teuerste Fehler ist ein Denkfehler:
„Externe sind zu teuer. Wir suchen so lange, bis wir die Stelle intern im Budgetrahmen besetzen können.“
Echt jetzt?
Wurde schonmal die Frage gestellt:
Wie teuer ist es, wenn deine Projekte stillstehen?
Hier ist ein einfaches Rechenbeispiel:
Deine HR hat ein Budget von 60K. Der Entwickler will 80K. 20K über Budget? Der Entwickler wird abgelehnt.
Und jetzt? Es wird weitergesucht, logisch. Kostet ja fast gar nix.

Und was passiert mit dem Projekt? - es stockt und kommt oft sogar zum Stillstand.
Was kostet es dich, wenn das Projekt nicht weitergeht?
Produktentwicklung, Projekteffizienz, Innovation – alles steht still.
Qualitätsverluste und verpasste Marktchancen – dein Unternehmen zahlt den Preis.
In Millionen.
Unternehmen sparen sich oft kaputt. Falsches Staffing kostet dich mehr, als du auf den ersten Blick siehst.
#Realtalk: Für Peanuts bekommst du nur Affen. Kannst du es dir wirklich leisten, dass dein Projekt stillsteht?
Effizienz und Qualität in Softwareprojekten sind der Schlüssel zu deinem Erfolg. Hol dir die besten Köpfe, investiere clever und erlebe, wie deine Projekte durchstarten. Externe Spezialisten sind keine Kosten, sondern Investitionen. Sie bringen Expertise, liefern Ergebnisse und sparen dir langfristig Millionen.
Unsere Erfahrung zeigt: Die richtigen Entwickler und Architekten machen den Unterschied. Nicht die Billigsten, sondern die Besten.
Lass uns mal darüber sprechen, wie wir deine Projekte zum Erfolg führen können.
Du wirst überrascht sein, wie viel du wirklich sparen kannst, wenn du in Qualität investierst.
Nutze doch einfach unsere kostenlose Projektanalyse.

Externe vs. Projektkosten

Sagt ein Lebenslauf etwas über den Entwickler aus?

🚀 Real Code, Real Skills: Der Schlüssel zu erfolgreichen Projekten 🚀

Hast du jemals darüber nachgedacht, ob Entwickler im Vorstellungsgespräch Code schreiben sollten?

Es ist nicht zwingend erforderlich, aber sehr ratsam.

Unerlässlich ist, dass Sie über den realen Sourcecode kommunizieren können.

Und das ist mehr als nur einfache Beispiele oder Algorithmen.

Warum?

Weil es keinen festen Standard gibt, der alle Fähigkeiten eines Entwicklers beurteilen kann.

Lebensläufe, Abschlüsse und Referenzen sagen einfach nichts aus.

Vor allem nicht die Wahrheit ❗

Stell dir vor, du stellst jemanden ein, ohne jemals einen Blick auf seinen Code geworfen zu haben. Das ist wie ein Blindflug ❗

Du riskierst nicht nur die Effizienz, sondern provozierst auch Teamkonflikte und letztlich Millionenverluste.

Der Code eines Entwicklers offenbart seine Fähigkeiten und seine Problemlösungskompetenz.

Das ist viel wichtiger als jede Referenz oder Zertifizierung.

✅ Unser Praxistipp:

Lasse Entwickler während des Interviews praktische Code-Aufgaben lösen.

Das gibt dir nicht nur einen echten Einblick in die technischen Fähigkeiten, sondern zeigt auch, wie der Kandidat unter Druck arbeitet.

So steigerst du die Produktivität deines Teams und verkürzt die Einarbeitungszeit neuer Mitarbeiter immens.

❗ Nur Achtung:

Du brauchst jemanden im Unternehmen, der die Code-Qualität auch wirklich beurteilen kann.

Real Code, real Skills

Scrum: 20% Overhead vs. 5% – Wie Du Deinen Fokus auf Ergebnisse legst und nicht auf Prozesse

In der Welt der Softwareentwicklung ist Scrum ein zweischneidiges Schwert. Einerseits bietet es enorme Vorteile durch Flexibilität und kontinuierliche Verbesserung. 
Andererseits heißt Scrum per Definition, 20% Deiner Kapazität in den Prozess zu stecken. Ziel muss es sein, diese Zeit auf 5% zu reduzieren. 
In der Realität sieht es aber genau andersrum aus. 
In vielen Unternehmen geht es eher Richtung 30%.

✅ Effektive Nutzung von Scrum

Scrum richtig angewendet, ist ein mächtiges Werkzeug. Es ermöglicht schnelle Anpassungen, fördert die Zusammenarbeit und sorgt für kontinuierliche Lieferungen, die echten Mehrwert schaffen. Der Schlüssel liegt darin, Scrum-Praktiken effizient zu nutzen, ohne in die Falle des Mikromanagements zu geraten.

❌ Prozessfetischismus vs. Ergebnisorientierung

Leider sehen wir oft, dass Fulltime-Scrum-Master die Methode missbrauchen. Sie halten sich akribisch an das Lehrbuch und fokussieren sich mehr auf die Einhaltung der Prozesse als auf die tatsächlichen Projektergebnisse. Sie sehen sich gerne als Hüter des Prozesses, obwohl sie in Wirklichkeit Mentoren, Moderatoren und Enabler sein sollten. Meetings und Zeremonien wie Daily Stand-Ups, Sprint-Planung und Retrospektiven werden zu Selbstzwecken, anstatt dem Team zu dienen.

✅ Optimierungspotenzial bei Meetings

Ein typisches Daily Stand-Up dauert oft 30 Minuten und findet jeden Tag statt. Das Ziel sollte sein, diese Meetings auf 5-10 Minuten zu verkürzen und die Frequenz auf 2-3 Tage pro Woche zu reduzieren. Dies spart nicht nur Zeit, sondern auch Geld. Frage Dich: Habe ich wirklich eine effiziente Kommunikation oder bitte ich nur zum Rapport? 
Überflüssige Meetings sind die größte Zeitverschwendung.

✅ Der wahre Sinn von Scrum

Scrum sollte Teams befähigen, nicht einengen. Ein guter Scrum Master versteht, dass der Prozess ein Mittel zum Zweck ist – und dieser Zweck ist die erfolgreiche, effiziente und qualitativ hochwertige Fertigstellung des Projekts. Der Fokus muss auf der Lieferung von Ergebnissen liegen, nicht auf dem bloßen Einhalten von Zeremonien.

✅ Unsere Empfehlung

Überprüfe regelmäßig, ob Deine Scrum-Praktiken wirklich dem Projekterfolg dienen oder nur den Prozess um des Prozesses willen unterstützen. Sei bereit, unnötige Schritte zu streichen und konzentriere Dich auf das Wesentliche: das erfolgreiche Abschließen Deines Projekts mit minimalem Overhead und maximalem Ergebnis.


Ergebnisse vs. Prozesse

Warum Referenzen nichts über wahre Kompetenz aussagen 

Du kennst das: 
Eine glänzende Referenz von einem Großkonzern, und schon ist jemand der Star im Team. 
Die bittere Wahrheit ist jedoch: 
Referenzen werden völlig überbewertet. 

Sie sagen nämlich nichts darüber aus, wie die Leistung erbracht wurde und wer die Referenz gegeben hat.

In vielen IT-Projekten im deutschsprachigen Raum ist das durchschnittliche Skill-Level erschreckend niedrig. 
Da ist es leicht, zu glänzen – selbst für jemanden, der im Vergleich zu echten Experten nur mittelmäßig ist. 
Eine Top-Referenz ist schnell gesammelt, aber was steckt dahinter?

Wir bei Staffwerke setzen auf nachweisbare Expertise und echte Ergebnisse statt auf oberflächliche Referenzen. 
Uns interessiert, wie jemand heute arbeitet, nicht, was er aus der Vergangenheit vorweisen kann. 
Deshalb arbeiten wir z.B. kaum mit der Schweiz zusammen – dort zählen Referenzen mehr als echte Leistung.

Echte Kompetenz zeigt sich in der täglichen Arbeit und im Projektfortschritt. PUNKT!

Referenzen vs. Kompetenz

Der Schlüssel zu erfolgreichen Projekten 

Hast du jemals darüber nachgedacht, ob Entwickler im Vorstellungsgespräch Code schreiben sollten?

Es ist nicht zwingend erforderlich, aber sehr ratsam.

Unerlässlich ist, dass Sie über den realen Sourcecode kommunizieren können.

Und das ist mehr als nur einfache Beispiele oder Algorithmen.

Warum?

Weil es keinen festen Standard gibt, der alle Fähigkeiten eines Entwicklers beurteilen kann.

Lebensläufe, Abschlüsse und Referenzen sagen einfach nichts aus.

Vor allem nicht die Wahrheit ❗

Stell dir vor, du stellst jemanden ein, ohne jemals einen Blick auf seinen Code geworfen zu haben. Das ist wie ein Blindflug ❗

Du riskierst nicht nur die Effizienz, sondern provozierst auch Teamkonflikte und letztlich Millionenverluste.

Der Code eines Entwicklers offenbart seine Fähigkeiten und seine Problemlösungskompetenz.

Das ist viel wichtiger als jede Referenz oder Zertifizierung.

✅ Unser Praxistipp:

Lasse Entwickler während des Interviews praktische Code-Aufgaben lösen.

Das gibt dir nicht nur einen echten Einblick in die technischen Fähigkeiten, sondern zeigt auch, wie der Kandidat unter Druck arbeitet.

So steigerst du die Produktivität deines Teams und verkürzt die Einarbeitungszeit neuer Mitarbeiter immens.

❗ Nur Achtung:

Du brauchst jemanden im Unternehmen, der die Code-Qualität auch wirklich beurteilen kann.

Real Code, Real Skills

Achtung: Falsches Spiel in der IT-Branche – Wie Unternehmen mit “Senioren” getäuscht werden!

Du gehst in ein Sternerestaurant, bestellst ein Filet Mignon und bekommst stattdessen einen Hamburger serviert – aber die Rechnung bleibt dieselbe.

Genau das passiert häufig in der Welt der IT-Dienstleistungen.
Viele IT-Dienstleister versprechen dir die Crème de la Crème der Entwickler, schicken dir dann aber nur die Juniors ins Projekt. Natürlich zu Senior-Preisen.

Das Geschäftsmodell einiger IT-Dienstleister ist echt bizarr:
Täusche beim Pitch Qualität vor und liefere nach Beauftragung Quantität.

Aber es geht ja noch weiter…
Egal, ob du nach einem Softwareentwickler, einem Facility-Manager oder sogar nach einem Nachtwächter suchst – sie haben immer jemanden parat.

Marge ist das Lieblingswort.
Da wird dann schonmal der Junior-Entwickler in eine Warnweste gesteckt, bekommt einen Elektroschocker an den Gürtel und wird als Spitzenkraft für Wachschutz vertickt.

Es klingt absurd, fast schon satirisch, doch für viele ist das die bittere Realität.
Die Praktiken mancher Dienstleister in der IT-Branche sind nicht nur fragwürdig, sondern haben für Unternehmen, die auf echte Expertise angewiesen sind, verheerende Folgen.

Deswegen:
Augen auf bei der Partnerwahl!
Auch dein nächstes IT-Projekt wird mit den falschen “Experten” scheitern.

Wie es besser geht, können wir gerne mal in einer kostenlosen Projektanalyse besprechen.

#ITSkandal #TechTäuschung #BusinessEthik #DigitalTransparency