Wie stelle ich sinnvoll (agile) Leute ein?

Fast jedes Unternehmen hat mittlerweile das Problem: Wie finden wir die richtige Verstärkung für unser Team? Welche Leute passen zu uns? Welche Aspekte sind uns wichtig? Als wäre diese Aufgabe durch den Fachkräftemangel nicht schon schwer genug, stellen vor allem agile Teams auch noch besondere Anforderungen an die Kandidatinnen. Die Entwicklungs-Teams sollten es daher nicht der HR-Abteilung überlassen, neue Teammitglieder zu finden.
Der Vortrag bietet Anregungen für das Recruiting von IT-Mitarbeiterinnen aus der Praxis.

Transcript

1. Konstantin Diener | konstantin.diener@cosee.biz | @coseeaner Wie stelle ich sinnvoll (agile) Leute ein?
2. Konstantin Diener CTO und Gründer von cosee
3. Produktentwicklung starten Produktentwicklung skalieren
4. Am schwierigsten ist es, jemanden für die So ft ware- Entwicklung zu finden.
5. Als erstes müssen wir dazu unser Bild von So ft ware- Entwicklern korrigieren.
7. Sie sind aber nicht diese Einzelgänger.
9. Insbesondere So ft ware-Entwickler wollen sich neue Team-Mitglieder selbst aussuchen.
10. Das bedeutet auch, dass ihr sie nicht beeindrucken könnt …
11. … aber die Leute in eurem Team können es.
12. Aber nach wem sucht ihr eigentlich?
13. 1 Bedarf festlegen
14. Seid ehrlich! Wer schreibt bei euch die Stellenausschreibungen?
15. Jemand in HR?
16. 80% der HR hiring Manager sagen, dass Stellenausschreibungen wichtig sind. Kate Leto, Hiring Product Managers
17. 50% geben zu, dass sie sie zusammenkopieren. Kate Leto, Hiring Product Managers
18. Kate Leto Hiring Product Managers
20. Ist das wirklich alles gleich wichtig?
21. Nein! 👎
22. Deswegen: Findet heraus, was wirklich wichtig ist.
23. Beschreibt eure Stellen zusammen mit den Betro ff enen.
24. Werkzeuge wie der Joel test können euch dabei helfen.
25. 1. Do you use source control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do programmers have quiet working conditions? 9. Do you use the best tools money can buy? 10.Do you have testers? 11.Do new candidates write code during their interview? 12.Do you do hallway usability testing? https://www.joelonso ft ware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
26. https://github.com/annaloew/devopstest
28. the PMwheel — Page 1 Petra Wille, https://www.strongproductpeople.com/pmwheel 9 Account Management 6 10 Vertrieb 4 11 cosee Controlling 4
29. Aber o ft fehlt etwas …
30. The two hardest things in Computer Science are: People, and convincing others that "People" is the hardest thing in Computer Science. @listrophy
31. Kate Leto, Hiring Product Managers
32. ROLE CANVAS www.kateleto.com Kate Leto Purpose: Why does this role exist? ROLE NAME: VERSION: Accountabilities: What are the goals or outcomes the role will be working towards? Technical Skills: Roadmaps, JTBD, Design Sprints, OKRs. etc. Human Skills: Leadership, conflict resolution, influence, adaptability, etc.
33. Füllt den Role Canvas für die Rolle aus, für die ihr einstellen wollt.
34. 1 Scrum Master sicherstellen, dass das Individuum produktiv und wertschöpfend (zusammen-) arbeiten kann Weiter- entwicklung, Selbstreflektion & Initiative stärken Kommunikation - Transparent, zielgerichtet, offen (keine Angst vor Ehrlichkeit) aber trotzdem sensibel, redet mehr mit Menschen als über sie Scrum Muster erkennen (auf individueller, Team und Orga Ebene) Emotionale Intelligenz Überblick behalten miro jira Empathie Resilienz Active listening Konflikt Lösung Fokussierte und ertragreiche Kommunikation in und außerhalb von Meetings Baustellen in der Zusammenarbeit (Team & Orga) sichtbar machen & Hilfestellung beim Lösen geben Grundlegendes Discovery Wissen Organizational awareness (z.B. wirtschaftlich und sozial) wir regen Knowledge Sharing an, damit Wissensinseln aufgelöst werden Klarheit schaffend Coaching Haltung (ich bin verantwortlich für den Prozess) Personalentwicklu ng -> Strategien zu Weiterentwicklun g von Einzelpersonen Vertrauensperson (die bei menschlichen Schwierigkeiten unterstützt) Klarheit schaffen z.B. visualisieren, Beispiele Kanban Retro- Methoden Flipchart- Gestaltung (Systemisches) Coaching Moderations- Methoden Facilitation Skills Training Skills cosee- Way vermitteln intern und extern Collaboration (Vernetzung nutzen, Teamplayer) Critical Thinking (hinterfragen) Selbst- Organisation (eigenständig, strukturiert) Beziehungsaufbau und pflege sicherstellen, dass das Team produktiv und wertschöpfend (zusammen-) arbeiten kann sicherstellen, dass es einen (organisationalen) Rahmen gibt, der wertschöpfende Arbeit unterstüzt Hilfe zur Selbsthilfe lebendes Vorbild für Agilität (intern & extern) Konflikte aushalten, emotionale Abgrenzung Probleme aufzeigen und helfen, sie zu lösen Minimal viable process - Agile prozesse schaffen und bewahren, die die Zusammenarbeit fördern und nicht einschränken Zeitmanagement Agilität vermitteln intern und extern kühlen Kopf bewahren Konstruktiv Feedback geben und einholen sich durchsetzen, wenn nötig Mut (unangenehmes ansprechen, mutige Sprintziele) Leadership positive Perspektiven aufzeigen, Vorbild sein
35. PO oder PM? Neugier 1 Siehe PMWheel links. Ordnung und Roadmap Inhaltliche Führung im Kundenprojekt (insb. durch Product Vision und Sprint- Ziele) Dem Team effektives Arbeiten ermöglichen (geteilt mit SM) GF vom Kunden Accounting & Controlling entlasten Sicherstellen, ein großartiges Produkt zu finden und zu bauen, das einen positiven Impact hat. Klarheit schaffen decision facilitation & making effective communication effective self- management schnelle Auffassungsgabe (Intellectual Horsepower) Emotionale Intelligenz Zug zum Tor erzeugen Reduce value risk Reduce business risk Ein Kundenengagement ist wirtschaftlich erfolgreich für cosee. Begeiste rungsfä hig Wertrisiko (Value Risk) und Geschäftswertrisiko (Business Viability Risk) reduzieren – für unsere Kunden und cosee. Problem erkennung und - lösung Zug zum Tor haben Mit Product- Discovery- Techniken das "richtige Produkt" finden. Erstgespräche und Discoverys organisieren Heißt auch: hunting & farming von neuen Engagements User Story Maps Durch Prognosen (Aufwand etc.) insbesondere den Kunden Steuerungsmöglic hkeiten schaffen. Risiken sichtbar machen. Vertrieb Zielstrebigkeit Flexibilität Bereitschaft zum Lernen Verständnis für Softwareentwick lung und Verteilte Systeme TBD: technical skills aus pmwheel destillieren
36. Baseline / Standards in Teams egende In der ersten Ebene befindet sich das Oberthema. Bsp. "Definition of Done", d.h. es soll eine DoD geben In der zweiten Ebene können konkrete Tasks zu dem Oberthema gesammelt werden. Bspw. "In einer DoD muss ... enthallten sein". Wir unterscheiden mit Color Coding ob die Tasks wirklich Must Haves sind (Dinge, die wir von Beginn an einfordern) oder Wünsche (wo wir die Team hinentwickeln wollen). Zu jedem Must Have wollen wir das Why/Ziel ergänzen, damit wir nachvollziehen und begründen können warum wir das einfordern. Wie gehts mit den Ergebnissen weiter? Wie geht es weiter? Was t wir je dami Was passie wenn die Entwicklun darauf kein Lust hat? Wie / mit wem besprechen wir trunk based development? Wie binden wir die Meinung der Devs ein (Beispiel Trunk based dev) mit Kodi in nächster PO CoP besprechen Miro aufräumen + Platz für CoP- Regeln perspektivisch: Blogpost Arabella Was passiert wenn sich jemand nicht daran hält? ins Gespräch mit den Personen gehen Vane packt e Trel Boa Micha Engineering Standards Definition of Done Es wird eine Definition of Done erstellt Done heißt die Entwicklung ist abgeschlossen & auf dem Live- System gemeinsames Verständnis ab wann eine Aufgabe Done ist & Qualitätssicherung Vier- Augen- Prinzip (durch Pair/Review/..) getestet Why: Qualitätssicher ung (vier Augen sehen mehr als zwei) Why: sicherstellen, dass Lösung die Anforderungen erfüllt und fehlerfrei funktioniert Urlaubsplanung wird mit dem Team abgesprochen, bevor der Urlaub beantragt wird (Kunden mitdenken) wir reden mit Menschen statt über sie Why: Sicherstellen, dass genug Personen da sind, um sinnvoll am Produkt arbeiten zu können Terminabstimmung sinnvoll an Bedürfnissen des Teams, des Kunden und der Einzelnen ausrichten Teamvertrag Reaktionszeiten pro Kommunikations- kanal abgestimmt Bescheid sagen, wenn Dinge fertig sind es anderen einfach machen, die Arbeit zu prüfen (links zu Ergebnissen) selbst eigene Arbeit prüfen weil wir nur verbessern können wovon wir wissen wir machen Retrospektiven um unsere Zusammmenarbeit zu reflektieren und zu verbessern gute Urlaubsübergabe machen (keine Tickets behalten, laufende Themen an bestimmte Personen übergeben kundentermine vs cosee- interne termine arbeitszeiten von Werkstudenten z.B. für @channel Why: Team kann sinnvoll weiterarbeiten und Urlauber sich ungestört erholen Abwesenheiten ankündigen (auch kurze) Why: Team präsent halten wer nicht da & professioneller Eindruck gegenüber Kunde Way of Working Testing Why: sicherstellen, dass Lösung die Anforderungen erfüllt und fehlerfrei funktioniert Wiederkehrende Aufgaben werden automatisiert so gut es geht. CI/CD Wir wollen unseren Code schnell und regelmäßig ausliefern, um Feedbackzyklen kurz zu halten und keine Angst vor Veränderung zu haben You build it, you run it. feste Zuständigkeiten, Verantwortung, Regelmäßigkeit, Einigkeit, Mehraugenprinzip (Fehlerfälle, Logging, Alerting) Code & Architektur auf Verständlichkeit, Erweiterbarkeit, Testbarkeit hin schreiben (z.B. mit Clean Code) Why: wartbarer Code Why: lauffähige Software, die einen reibungslosen Betrieb sicherstellt Rollen Remote Workig Agreements Wir arbeiten mit einer dezidierten PO- Rolle Kamera in Calls an Wir arbeiten mit einer dezidierten SM- Rolle Why: Es braucht eine Person, die den inhaltlichen Überblick & Fokus gibt, die Vision schärft und priorisiert Why: Es braucht eine Person, die sicherstellt, dass das Team produktiv zusammenarbeiten kann und agile Methodiken / Inspect & Adapt wertstiftend nutzt Die Entwickler sind für die technische Qualität & Technologieentschei dungen verantwortlich Why: Weil sie sie auch tragen müssen & Experten darin sind Slack & Discord für Teamabsprachen Why: Fokus und Präsenz in Meetings + es gehen viele non- verbale Informationen ohne Video verloren Definition of Ready Es wird bei Bedarf eine Definition of ready erstellt gemeinsames Verständnis ab wann eine Aufgabe bereit ist zum Umsetzen und in den Sprint ziehen Alle Entwickler sind gleichberechtigt (Keine Lead Developer) Damit es keine (oder möglichst wenig) Wissensinseln und Abhängigkeiten gibt und alle Devs gleichrangig Entscheidungen treffen Abwesenheiten beim Pair/Mob Programming ankündigen (auch kurze) cosee- intern: Jeder visualisiert Abwesenheiten auf Tagesbasis in Slack über den Status = Urlaub = Uni/Abwesenheit Werkstudenten = krank = abwesend (andere Gründe) Arbeitsmethodik wir arbeiten mit Scrum oder einer anderen agilen Methodik Pull- Prinzip: niemand außer die Entwickler selbst weisen sich Aufgaben zu (auf Basis der Priorisierung des POs) Why: Für Produktentwicklung im komplexen Setting bieten agile Methodiken die nötige Adaptivität 3- Personen- Regel für Technologie- entscheidugen (Leitfaden für Technologientscheid ungen beachten) bei Unsicherheiten zu Technologie- entscheidungen in der CoP / mit Experten besprechen Entwickler wissen selbst am besten was sie in der gegebenen Zeit angehen & abschließen können + freiwillige Verantwortungs- übernahme, denn Verantwortung kann nur genommen und nicht gegeben werden Why: keine Alleingänge (verfügbares Wissen nutzen) und die Entscheidung muss auch längerfristig umsetzbar und wartbar für die Verantwortlichen sein (you built it you run it) regelmäßiges Pair / Mob Programming Why: - kreativere & strukturiertere Lösungen - Knowledge Sharing - gemeinsamer Fokus - Entwicklung gemeinsamer Standards & Teamgeist Timeboxing für Meetings Gemeinschaftlich e Arbeit ist auf festgelegtem Medium sichtbar (als Board in Miro, Jira usw.) Why: Damit es ein gemeinsames Verständnis von aktuellen To Dos gibt und auch bei Abwesenheit von jemandem ein Überblick möglich ist + Qualitätssicherung Why: effektive & fokussierte Meetings auf Terminanfragen antworten (akzeptieren o. ablehnen + begründen) Lieber einmal mehr anrufen als einmal zu wenig Why: Um falschen Annahmen zu entgehen und Missverständnisse zu vermeiden Why: eigene Verfügbarkeit kommunizieren, Erwartungshaltung der anderen steuern und Missverständnisse vermeiden Why: effiziente Terminfindung und Vermeidung sinnlose Meetings (weil wichtige Leute fehlen) Why: hilft implizite Regeln explizit zu machen und kann als Referenz dienen Halte dich an die Entwicklungsprakt iken, die ihr als Team zu Beginn definiert habt. Hinweis: siehe unten für detaillierte Standards der CoPs dazu habe ich eine Frage / Redebedarf damit bin ich nicht einverstanden
37. DDD / Clean Architecture ehrlich mit Wissenslücken umgehen Dem Reviewer die Arbeit leicht machen Clean Code Reviews (4- Augen Prinzip) IaC (mit TF) Bewusstsein für Safety- Issues (race conditions etc.) Lernbereitschaft zu neuen Techstacks Wartbarkeit, Stabilität, Kollaboration QS Techstack an den Anforderungen des Kunden ausrichten, up- to date bei neuen technische Entwicklungen CICD Risiko minimieren und kurze Feedback- Zyklen DevOps Big Picture, Wartbarkeit (Software bauen, die wir auch gerne betreiben würden), Craftmanship Hilfs- bereitschaft, wenn andere lernen wollen Tests Pair-/ Mob- Programming Ziel/Why: Maintainability In Situation des Nutzers / Kunden versetzen können Bereitschaft Doku zu lesen stackoverflow und chatGPT wissen nicht alles Prioritäten/ Bedürfnisse/ Erwartungen abwägen, um zielgerichtet ein Produkt zu erschaffen Verständnis wie WebApps funktionieren (Interaktion FE & BE) ohne Verständnis sollte man nichts bauen, wir können verstehen woher Fehler kommen Übergaben & Kommunikation, auch asynchron über Slack- Nachrichten, Tickets, Notizen etc. Security Grundverständnis Angriffe / Sicherheitslücken vermeiden, cosee gilt als Siegel für Qualität & Sicherheit Feedback annehmen Sonst ist Onboarding und Zusammenarbeit auf cosee- Niveau nicht möglich sich trauen Fragen zu stellen Observability (O11y) - von Anfang an mitdenken sinnvolle Betreibung Bei Abwesenheit können andere weitermachen Minimierung von undebugbaren Bugs sehen wir im Doing / Onboarding sehen wir schon im Vorstellungs- gespräch & im Onboarding sehen wir schon im Onboarding ob die Person nachfragt Person geht auf andere zu. ist an kollaborativer Arbeit interessiert & nimmt sich selbst nicht so wichtig mündliche Erklärungen (oder schriftliche Verlinkungen), sodass alle nötigen Infos verfügbar sind Reviews idealerweise gemeinsam machen den anderen mitdenken wir machen idealerweise Trunk Based Development Verantwortungs- gefühl & Bereitschaft, sich um Deployment etc. zu kümmern Verständnis & Bereitschaft + wird wirklich wie Code und nicht wie Konfiguration verwendet, verstehen was man managed Viele Kleine Ändeurngen statt wenige Große deployments wir arbeiten idealerweise synchron direkt mit Kunden reden Social Skills work ethic Coding standards / Skills Arbeitsweise Other Skills Wissenstransfer, gemeinsames Verständnis, von jemandem Lernen ist oft effektiver als z.B. nur Doku lesen, offene Kommunikation im Team, Vertrauen / psychologische S icherheit mit Personen satt über sie reden - durch direkte Kommunikation kommen alle relevanten Infos an, wir verstehen Kunde & Kunde versteht uns effektivere und effizientere Kommunikation im Team, Teambuilding, Fokus merken wir im Gespräch, Verständnis von flachen Hierarchien/Rolle n Lernen voneinander nachfragen wie bisher damit umgegangen wurde, in Zusammenarbeit: spricht Person das an / denkt darüber nach im Bewerbungsgespräch: wie jemand über Tests redet, im Review: sind Test vorhanden und wie wurden sie geschrieben (Inhalt & welche Testfälle abgedeckt) Wow- Effekt im Bewerbungs- gespräch: Unit Tests: Es gibt Unit Tests mit sinnvollen Asserts Integrationstests: Es gibt Integrationstests ;-) Vertrauen in Deployments, konkretisiert zu entwicklendes Feature (TDD) tiefgreifendes Verständnis für Lösungen und kontinuierliches Lernen ein Entwicklerleben lang im Bewerbungsgespräch: Interesse / Offenheit neue Technologien auszuprobieren + konkretes Ausprobieren, Lebenslauf, Flexibilität & Offenheit für Technologien in der Zusammenarbeit Offenheit für Fragen, keine Verurteilung bei Fragen / Unwissen Offenheit & Transparenz ggü. Fehlern & Bereitschaft zur Selbstreflektion Fehler werden zugegeben auch wenn wir wissen, dass Vertrauen erst gelernt werden muss (idealerweise schaffen wir diese Atmosphäre & sind Vorbild) Konstruktiv auf Fehler anderer reagieren Konstruktiv auf eigene Fehler reagieren Bessere Möglichkeit zum Lernen, Wohlbefinden, und Behebung des Fehlers merken wir in Zusammenarbeit: z.B. wie informiert und vorbereitet sind die Fragen ("habe schon XY gelesen und frage mich noch Z") voneinaner Lernen Offenheit für Feedback, konstruktiver Umgang, tatsächliche Verhaltensänderung merken wir schon im Bewerbungsgespr äch (Transparenz vs Durchhmogeln) im Bewerbungsge spräch gezielt Fragen dazu stellen Person denkt auch für Worst Case Szenarien vor (wie kann das kaputt gehen) im Bewerbungsgespr äch direkt nachfragen falls passend, sehen wir im Review hinterfragen, was man baut erkennen wir in der Zusammenarbeit -> auch fachliche Nachfragen, "wäre es für Nutzer nicht sinnvoller wenn wir ... bauen" gegebenes Problem -> kann man das nicht einfacher Lösen mit XY (?)
38. Leitet eine Stellenausschreibung aus euren Erkenntnissen ab.
39. 2 Stellenaus- schreibung
41. Macht den Lackmus-Test: „Würdet ihr euch bewerben?“
42. Jetzt müssen die Leute eure Stelle nur noch finden …
43. Was ihr kennen müsst: „virtual watering holes“.
45. 3 Interviews
46. Spielt kein Theater mit den Leuten!
47. We hire athletes, not position players! Susan Wojcicki, Google
49. ROLE CANVAS www.kateleto.com Kate Leto Purpose: Why does this role exist? ROLE NAME: VERSION: Accountabilities: What are the goals or outcomes the role will be working towards? Technical Skills: Roadmaps, JTBD, Design Sprints, OKRs. etc. Human Skills: Leadership, conflict resolution, influence, adaptability, etc.
50. 1 Scrum Master sicherstellen, dass das Individuum produktiv und wertschöpfend (zusammen-) arbeiten kann Weiter- entwicklung, Selbstreflektion & Initiative stärken Kommunikation - Transparent, zielgerichtet, offen (keine Angst vor Ehrlichkeit) aber trotzdem sensibel, redet mehr mit Menschen als über sie Scrum Muster erkennen (auf individueller, Team und Orga Ebene) Emotionale Intelligenz Überblick behalten miro jira Empathie Resilienz Active listening Konflikt Lösung Fokussierte und ertragreiche Kommunikation in und außerhalb von Meetings Baustellen in der Zusammenarbeit (Team & Orga) sichtbar machen & Hilfestellung beim Lösen geben Grundlegendes Discovery Wissen Organizational awareness (z.B. wirtschaftlich und sozial) wir regen Knowledge Sharing an, damit Wissensinseln aufgelöst werden Klarheit schaffend Coaching Haltung (ich bin verantwortlich für den Prozess) Personalentwicklu ng -> Strategien zu Weiterentwicklun g von Einzelpersonen Vertrauensperson (die bei menschlichen Schwierigkeiten unterstützt) Klarheit schaffen z.B. visualisieren, Beispiele Kanban Retro- Methoden Flipchart- Gestaltung (Systemisches) Coaching Moderations- Methoden Facilitation Skills Training Skills cosee- Way vermitteln intern und extern Collaboration (Vernetzung nutzen, Teamplayer) Critical Thinking (hinterfragen) Selbst- Organisation (eigenständig, strukturiert) Beziehungsaufbau und pflege sicherstellen, dass das Team produktiv und wertschöpfend (zusammen-) arbeiten kann sicherstellen, dass es einen (organisationalen) Rahmen gibt, der wertschöpfende Arbeit unterstüzt Hilfe zur Selbsthilfe lebendes Vorbild für Agilität (intern & extern) Konflikte aushalten, emotionale Abgrenzung Probleme aufzeigen und helfen, sie zu lösen Minimal viable process - Agile prozesse schaffen und bewahren, die die Zusammenarbeit fördern und nicht einschränken Zeitmanagement Agilität vermitteln intern und extern kühlen Kopf bewahren Konstruktiv Feedback geben und einholen sich durchsetzen, wenn nötig Mut (unangenehmes ansprechen, mutige Sprintziele) Leadership positive Perspektiven aufzeigen, Vorbild sein
51. the PMwheel — Page 1 Petra Wille, https://www.strongproductpeople.com/pmwheel 9 Account Management 6 10 Vertrieb 4 11 cosee Controlling 4 PO oder PM? Neugier 1 Siehe PMWheel links. Ordnung und Roadmap Inhaltliche Führung im Kundenprojekt (insb. durch Product Vision und Sprint- Ziele) Dem Team effektives Arbeiten ermöglichen (geteilt mit SM) GF vom Kunden Accounting & Controlling entlasten Sicherstellen, ein großartiges Produkt zu finden und zu bauen, das einen positiven Impact hat. Klarheit schaffen decision facilitation & making effective communication effective self- management schnelle Auffassungsgabe (Intellectual Horsepower) Emotionale Intelligenz Zug zum Tor erzeugen Reduce value risk Reduce business risk Ein Kundenengagement ist wirtschaftlich erfolgreich für cosee. Begeiste rungsfä hig Wertrisiko (Value Risk) und Geschäftswertrisiko (Business Viability Risk) reduzieren – für unsere Kunden und cosee. Problem erkennung und - lösung Zug zum Tor haben Mit Product- Discovery- Techniken das "richtige Produkt" finden. Erstgespräche und Discoverys organisieren Heißt auch: hunting & farming von neuen Engagements User Story Maps Durch Prognosen (Aufwand etc.) insbesondere den Kunden Steuerungsmöglic hkeiten schaffen. Risiken sichtbar machen. Vertrieb Zielstrebigkeit Flexibilität Bereitschaft zum Lernen Verständnis für Softwareentwick lung und Verteilte Systeme TBD: technical skills aus pmwheel destillieren
52. Scaling Lean & Agile Development Craig Larman, Bas Vodde
53. How will you know whether a new hire will fit in a team? Involve the team in the hiring; better yet, let the team do the interviewing and let them make the final decision. Scaling Lean & Agile Development
54. Circus Manager:
55. Circus Manager:
56. Circus Manager:
57. Circus Manager:
58. Circus Manager:
59. Circus Manager:
60. Circus Manager:
61. Peopleware Tom DeMarco, Timothy Lister
62. Lernt die Menschen anhand einer echten Aufgabe kennen.
63. How will you know whether a new hire will fit in a team? Involve the team in the hiring; better yet, let the team do the interviewing and let them make the final decision. Scaling Lean & Agile Development
64. Insbesondere So ft ware-Entwickler wollen sich neue Team-Mitglieder selbst aussuchen.
65. 🤔
66. Erinnerung: Es gibt mehr als „wir entscheiden“ und „sie entscheiden“.
67. https://management30.com/product/delegation-poker/
69. 4 Onboarding
70. Riskiert keinen harten Bruch nach dem Ende des eigentlichen Recruiting-Prozesses.
73. … individuals can perform up to 23 percent better a ft er consistently reflecting on their work … Kate Leto, Hiring Product Managers
74. • Insbesondere Entwickler wollen an Orten arbeiten, an denen andere Entwickler arbeiten. • Die Leute hassen es, wenn ihr Theater spielt. Lasst es! • Ihr könnt niemanden anziehen, eure Leute schon. • Legt euren Bedarf zusammen mit den Betro ff enen fest. Achtet auf die „Human Skills“. • Interviewt und entscheidet zusammen mit den Betro ff enen. • Sprecht über eine echte Aufgabe (mit Code). • Kümmert euch um ein ordentliches Onboarding. Spickzettel
75. At most companies , people spend 2 percent of their time recruiting and 75 percent managing their recruiting mistakes. Richard Fairbank, Capital One CEO
76. Wenn ihr nicht die richtigen Leute findet, könnt ihr Teams bei cosee mieten. 😉
77. konstantin.diener@cosee.biz | @onkelkodi Bildnachweise: Jongleur: https://www.shutterstock.com/g/Vladimir+Gjorgiev Nerd: https://www.shutterstock.com/g/ABCreative Gazellen: https://www.shutterstock.com/g/Vaclav+Sebek trinkende Gazellen: https://www.shutterstock.com/g/GunterNuyts Fragen? Konstantin Diener | cosee GmbH cosee.biz