Eigenverantwortung bei Easy Agile

Das Ziel von Easy Agile ist es, eine bessere Arbeitsweise zu finden. Im Jahr 2018 haben wir das bewusst anerkannt was uns hierher gebracht hat 👇🏼, bringt uns nicht dorthin 👉🏼. Mit anderen Worten, wir müssen uns ändern, um unsere Ziele zu erreichen. Die eigentliche Herausforderung besteht darin, proaktiv nach Veränderungen zu streben, anstatt dazu gezwungen zu werden.

„Wir glauben, dass es eine bessere Art zu arbeiten gibt“

Was hat uns hierher gebracht

Als Easy Agile (damals Arijea) 2016 auf den Markt kam, verbrachten Nick und ich ein ganzes Drittel unseres Tages damit, darüber zu diskutieren, was wir tun würden und wie wir es machen würden (was eine ziemlich gute Idee ist, wenn man nicht weiß, was man tut!). Es waren diese Gespräche, zusammen mit dem Lesen Schnell und langsam denken, Tiefgründige Arbeit und Kleine Riesen was die Grundlage für einige unserer Werte des Unternehmens und wie wir bei Easy Agile arbeiten. Wir reden immer noch viel, nicht ganz ein Drittel des Tages, aber es geht eher darum wie wir werden arbeiten, anstatt was wir werden daran arbeiten.

Eine kurze Geschichte: 2016 - 2018

In den ersten Jahren des Bestehens von Easy Agile ist viel passiert. Wir haben einige erfolgreiche Produkte entwickelt, sind zu Atlassian-Veranstaltungen um die Welt gereist und hatten generell eine Menge Spaß. Außerdem haben wir riesige Rückstände an Arbeiten aufgebaut, die wir niemals beginnen, geschweige denn beenden würden.

Damals war unsere Situation etwas anders als bei den meisten anderen Softwareunternehmen. Wir hatten mehr Produkte als Entwickler! Zu einem Zeitpunkt hatten wir 5 Produkte und einen Entwickler. Dies verbesserte sich auf 3 Entwickler und 2 Produkte, aber trotzdem schienen unsere internen Systeme und andere Arbeiten, die nicht mit dem Kunden zu tun hatten, nie in Gang zu kommen.

Diese frühen Jahre waren chaotisch, was ausschließlich meine Schuld war. Es war meine Zurückhaltung, das Programmieren aufzugeben, was dazu führte, dass ich mich im Gras verirrte, anstatt herauszuzoomen und zu versuchen, ein fantastisches Team zusammenzustellen. Wir stapften einfach weiter, schauten auf unsere Schuhe und ließen uns von kleinen Dingen ablenken, anstatt innezuhalten, nachzudenken und uns auf unser Kernziel festzulegen. Ich musste mein Verhalten ändern, um dem Team zu helfen, sich zu verbessern. Zum Glück fiel mir ein wirklich cooles Video ein, das irgendwann der Anstoß dafür sein sollte, dass ich meinen Fokus vom Code auf das Team verlagerte...

Ich habe dieses Video in den letzten Jahren unzählige Male gesehen. Jedes Mal, wenn ich das tue, fühle ich mich so glücklich, dass ich bei Atlassian gearbeitet habe und daran teilnehmen konnte Versenden und Innovationswochen. Ich empfehle Ihnen dringend, sich die Zeit zu nehmen, es sich anzusehen, falls Sie es noch nicht getan haben.

Die Bedeutung von Autonomie, Meister und Zweck

Die Ideen, die in diesem Video vorgestellt werden Autonomie, Meisterschaft und Zweck hat mich einfach dazu gebracht, darüber hinaus zu denken wie wir arbeiten daran, über die Gründe nachzudenken warum wir arbeiten. Natürlich ist das erste, was mir in den Sinn kommt, Geld. Es ist wichtig, genug Geld zu haben, um ein erfülltes Leben zu führen (und ich bin stolz darauf, sagen zu können, dass wir uns bei Easy Agile bemühen). Wie im obigen Video behandelt, ist mehr Geld jedoch nicht unbedingt ein guter Motivator. Es sind Autonomie, Beherrschung und Zielstrebigkeit, die das ermöglichen.

Während ich also einen Schritt zurücktrat, um eine bessere Arbeitsweise zu entwickeln, dachte ich mir, wir könnten genauso gut versuchen, Autonomie, Beherrschung und Zielstrebigkeit einzubauen, zusammen mit einer Vorschrift, die verhindert, dass sich unerwünschte Dinge einschleichen. Die Hauptschuldigen, die ich im Visier hatte, sind Bürokratie, Bürokratie, heilige Kühe, alte Systeme und Politik.

Wenn du dir die Mühe machst, ein großartiges Team talentierter Menschen aufzubauen, die sich Zeit nehmen, um für dich zu arbeiten, ist das Letzte, was du tun willst, ihnen mit sinnlosen Ritualen in die Quere zu kommen, die ihre Kreativität ersticken und ihre Zeit verschwenden!

Perspektive gewinnen durch Herauszoomen

Als Softwareunternehmen ist der Herzschlag von Easy Agile unser Softwareentwicklungsprozess. Heutzutage machen wir jedoch so viel mehr als nur Software zu entwickeln. Unser gesamtes Team kommuniziert täglich direkt mit unseren Kunden über den Kundensupport. Wir haben fantastische Vermarkter, Produktmanager und einen Datenanalysten. Wir brauchten eine Arbeitsweise, die über Rückstände und Schätzungen hinausgeht und alle zusammenbringt, um gemeinsam unsere Ziele zu erreichen.

Wir arbeiten am besten zusammen in funktionsübergreifenden Teams, also wollte ich das von Anfang an einbauen, anstatt Silos aufzubauen, während wir wachsen. Wir begannen damit, dass alle einen Backlog abarbeiteten und planten unsere gesamte Arbeit in Jira (einschließlich Sean, unserem ersten Mitarbeiter im Bereich Marketing). Wie Sie sich vorstellen können, skaliert dies jedoch nicht. Die Details, die bei unseren Planungssitzungen besprochen wurden, wurden für den Großteil des Teams irrelevant. Am Ende haben wir die meisten Details nur überflogen, wodurch Planung und Schätzung größtenteils irrelevant wurden.

Anfang 2019 habe ich es mir zur Aufgabe gemacht, ernsthaft nach einer besseren Arbeitsweise zu suchen. Also habe ich aufgehört zu programmieren (es war sowieso ein schrecklicher Gründercode). Seitdem haben wir unseren Entwicklungsprozess vier Mal überarbeitet. Wir haben sogar das Motto „Einen besseren Weg zur Arbeit finden“ zu unserem Motto gemacht.

Die Einzelheiten dieser Transformation würden den Rahmen dieses Blogposts sprengen. Sagen wir jedoch einfach, dass wir von einem chaotischen, nicht verwalteten Backlog zu einem weitaus organisierteren und durchdachteren Arbeitsansatz übergegangen sind. Die aktuelle Überarbeitung unseres Entwicklungsprozesses ermöglicht es uns, an (und) zu arbeiten Hundefutter) unsere Produkte und unsere internen Systeme gleichzeitig. Es passt sich uns an, wenn wir wachsen, fördert funktionsübergreifende Teams und verankert unsere Unternehmenswerte sowie Autonomie, Meisterschaft und Zielstrebigkeit für alle Teammitglieder.

Shape Up von Basecamp bildet die Grundlage unserer Arbeitsweise

Ich wurde zuerst auf Basecamps aufmerksam gemacht Form dich auf in einem Kommentar, den Nick zu einem Blogbeitrag gemacht hat, den ich geschrieben habe, um eine der oben genannten Überarbeitungen unseres Entwicklungsprozesses anzukündigen. Es war 4 Monate später, als ich ernsthaft mit der Suche nach einer besseren Arbeitsweise begonnen hatte, als ich mich daran erinnerte und als ich es noch einmal las, hatte ich das Gefühl, dass es vielleicht funktionieren könnte.

In Shape Up arbeitest du in 6-wöchige Zyklen was gerade lang genug ist, um etwas Konkretes zu tun, aber kurz genug, um nicht das Gefühl zu haben, dass die Frist zu weit entfernt ist. Darauf folgt ein zweiwöchiger „Cooldown“, bei dem jeder frei ist, Fehler zu beheben, etwas Neues auszuprobieren und sich für den nächsten sechswöchigen Zyklus zusammenzutun. Bei Easy Agile haben wir bereits in einem „Produktzyklus“ gearbeitet, in dem wir uns auf ein Produkt nach dem anderen konzentrierten, sodass diese Idee gut hineinpasste.

Sechs Wochen sind lang genug, um etwas Sinnvolles von Anfang bis Ende zu erstellen, und kurz genug, dass jeder von Anfang an spüren kann, dass die Frist abläuft, also nutzen sie die Zeit mit Bedacht. Die meisten unserer neuen Funktionen werden in einem sechswöchigen Zyklus entwickelt und veröffentlicht.

Shape Up schlägt weiter das Konzept der „Pitches“ und „Bets“ vor. Ein Pitch ist eine präzise Beschreibung eines Features oder einer Änderung, die groß genug ist, um bei erfolgreicher Umsetzung spürbare Auswirkungen auf das Unternehmen zu haben.

Shape Up verdankt seinen Namen dem „Formgebungsverfahren“, das bei der Formung einer Tonhöhe angewendet wird. Einen Pitch zu gestalten bedeutet, sich einfach die Zeit zu nehmen, sich auf das Problem zu konzentrieren und eine gute Lösung zu definieren. Sie werden ermutigt, Personen Ihres Vertrauens hinzuzuziehen, um den Umfang Ihres Pitches „einzugrenzen“, damit klar ist, was der Pitch bewirkt und was nicht. Das entspricht unseren Werten „Engage System 2“ und „Commit, as a team“.

Ich bin kein Wettfan, und da dieser Standpunkt in der Mannschaft ziemlich weit verbreitet zu sein schien, haben wir uns eine alternative Umgangssprache ausgedacht: Gelegenheit.

Was ist eine Gelegenheit?

Chancen bestätigen die Arbeit unserer Produktmanager. Es kann bis zu vier Wochen oder länger dauern, bis sie Gestalt annehmen, was im krassen Gegensatz zu anderen Arbeitsplätzen steht, in denen Produktmanager dafür verantwortlich sind, „das Biest zu füttern“ (Arbeit zu finden oder nachzuholen, um das Entwicklungsteam voll ausgelastet zu halten).

Die Chancen stehen entweder für 2 oder 4 Wochen Arbeit. Alles weniger und es lohnt sich wahrscheinlich nicht wirklich, oder es ist eine kleine Verbesserung, die von unserem Team für kleine Verbesserungen vorgenommen wird (dazu später mehr).

Unser Zyklus

Während der Zyklus von Shape Up insgesamt acht Wochen dauert, experimentieren wir derzeit mit einem sechswöchigen Zyklus. Wir haben vier Wochen Arbeit an Opportunities, gefolgt von einer Woche, in der wir auszahlen Technische Schulden, zum Markt und zur endgültigen Opportunity-Gestaltung. Wir runden das Ganze mit ein paar Dash Days ab (auch dazu später mehr).

1. Wie wir Chancen gestalten und auswählen

Die Gestaltung von Chancen liegt in erster Linie auf den Schultern unserer Produktmanager Teagan und Elizabeth. Jeder kann in Jira ein Opportunity-Ticket erstellen, aber damit müssen wir auch die volle Verantwortung dafür übernehmen, das Unternehmen durch die Entwicklung, das Testen und die Produktion zu begleiten und den Zustand und die Kennzahlen nach der Markteinführung zu überwachen. Aus diesem Grund empfehlen wir in der Regel, mit einem Produktmanager zusammenzuarbeiten, um das Ganze zu konkretisieren.

Der Prozess der Formgebung und des Zielfernrohrs wird in der Regel mit ein paar Mitarbeitern durchgeführt, die einen Überblick über alle beweglichen Teile geben können, die an dem, was Sie versuchen, beteiligt sind.

Derzeit versuchen wir, die Opportunities auszuwählen, die Easy Agile in die bestmögliche Position bringen, um unsere Ziele (auch bekannt als unsere vierteljährlichen und jährlichen OKRs) zu erreichen. Opportunities, die nicht im richtigen Umfang oder in der richtigen Form vorliegen, werden noch einmal von vorne beginnen, um sie in weiteren 6 Wochen erneut zu prüfen.

Wir untersuchen derzeit, wie wir den Opportunity-Auswahlprozess verbessern können. Das Wetttisch Das in Shape Up beschriebene Meeting ist eine Möglichkeit, auszuwählen, woran gearbeitet werden soll. Wir sind jedoch der Meinung, dass es einen besseren Weg gibt, den wir noch nicht genau kennen. Im Idealfall hilft uns jede Gelegenheit dabei, eines oder mehrere unserer Hauptziele zu erreichen. Wenn wir unsere OKRs in unsere Arbeitsplanung einbeziehen, haben sie das ganze Jahr über oberste Priorität.

2. Gelegenheit: Teambildung

Der autonome Teil unseres Entwicklungsprozesses ist besonders wichtig, wenn es um die Teambildung geht. Mit nur einer Ausnahme** werden alle Teams selbst ausgewählt und bestehen aus genau drei Mitgliedern des Entwicklungsteams (einem Senior-, Mittel- und Junior-Teammitglied) — etwas, das wir sind stellt immer noch aktiv ein für). Teammitglieder aus Produktmanagement, Datenanalyse und Marketing bilden gemeinsam wirklich funktionsübergreifende Teams. Das bedeutet, dass, wenn die Opportunity live geht, das gesamte erforderliche Marketingmaterial, die Dokumentation und andere nicht entwicklungsbezogene Arbeiten bereit sind, veröffentlicht zu werden, sodass wir zur Tech Debt/Go to Market/Shaping Week übergehen können.

Wir haben drei Teammitglieder pro Opportunity ausgewählt, da jedes Team so seine eigenen Pull-Requests selbst bearbeiten kann. Für unsere Pull-Requests sind mindestens zwei Genehmigungen erforderlich, um zusammengeführt zu werden. Drei Teammitglieder reduzieren die Störungen und den Kontextwechsel, die anderen Teams aufgezwungen werden.

**Ein kleines Team arbeitet an Bugs und kleinen Verbesserungen im Rahmen einer zweiwöchigen Opportunity, die immer ausgewählt wird. Die Teammitglieder dieses Teams arbeiten nach einer Rotation, sodass jeder seinen Versuch unternehmen kann.

3. Tech Debt/Go to Market/Shaping and Selection Week (ja — wir brauchen einen besseren Namen)

In der Woche nach Abschluss unserer vierwöchigen Opportunity-Arbeit nimmt sich das Entwicklungsteam eine Woche Zeit, um sich auf technische Probleme oder die Verbesserung der Entwicklungsumgebung zu konzentrieren. Wir nutzen diese Woche auch als Rollover-Puffer, um alle Arbeiten abzuschließen, die in den Opportunity-Wochen nicht abgeschlossen wurden. Wir versuchen, den Rollover auf ein absolutes Minimum zu beschränken.

Das Marketingteam wird alle Initiativen einführen, die es in den letzten vier Wochen entwickelt hat, um alle neuen Funktionen zu unterstützen, die ausgeliefert wurden.

Das Produktmanagement-Team wird mit der Gestaltung seiner Opportunities weitermachen und sie darauf vorbereiten, gemeinsam mit dem Team den nächsten Opportunity-Zyklus abzuarbeiten.

4. Dash Days

Dash Days (ehemals Inception Week) ist eine Zeit der Freiheit und Autonomie, in der Sie an einem Projekt Ihrer Wahl arbeiten können. Wenn es erfolgreich ist, wird es uns idealerweise zum Nachdenken anregen „Wie haben wir früher ohne das gelebt!?“. Sie sind im Wesentlichen eine Mischung aus ShipIt/ Innovation Weeks/ 20% Time, die ich bei Atlassian erlebt habe. Sie sind eine großartige Möglichkeit, der Kreativität unseres Teams freien Lauf zu lassen.

Einige aktuelle erfolgreiche Dash Days-Projekte.

1. EEinfache und agile Personas
2. Unser Dev Container vscode-Setup
3. „Mr. Tulip“ (unser Slack-Bot der fast alles macht)
4. Produktinterner NPS
5. Der Easy Agile Podcast
6. Unser Bereitstellungs-Dashboard (zeigt die Anzahl der Tage seit einer Cloud- oder On-Premise-Bereitstellung an)
7. Wir betreiben unsere Website mit Sanity.io CMS
8. ea-kit (unsere eigene Komponentenbibliothek)
9. Ein neues Modell zur zufälligen Abwanderung von Wäldern, um die Frustrationen unserer Kunden besser zu verstehen
10. Unser eigenes Logo-/Markendesign-Framework

Wie Sie sehen können, gibt es eine große Vielfalt an Dash Days-Projekten, die wir versendet haben. Der Versand ist jedoch keine Voraussetzung für Dash Days. Oft ist es am besten, sich etwas Zeit zu nehmen, um neue Ideen auszuprobieren oder einen Prototyp zu bauen, um ihn den Kunden vorzustellen.

Ein gutes Beispiel dafür ist eine Feature-Verfeinerung, die von Sam und Angad, zwei unserer neuesten Frontend-Entwickler, entwickelt wurde. Sie arbeiteten mit unserem Produktteam zusammen, um eine neue Methode zur Erstellung von Problemabhängigkeiten in Easy Agile-Programmen zu entwickeln. Ihre Definition von erledigt bestand nicht darin, es für die Produktion freizugeben, sondern es auf einen Testserver zu bringen, den wir für Kundeninterviews nutzten, die von unseren Produktmanagern Teagan und Elizabeth durchgeführt wurden. An den folgenden Dash Days nahmen Sam und Angad dieses Feedback entgegen, verfeinerten die Funktion mit Hilfe der Produktteams und schickten eine Version der Easy Agile Programs in die Cloud-Version. Bisher scheint der neue Ansatz zur Erstellung von Abhängigkeiten zehnmal beliebter zu sein! Erfolgreich!

Dash Days sind auch eine großartige Zeit für Teammitglieder, um ihr Lern- und Entwicklungsbudget in Höhe von 5000 USD zu nutzen, das jedes Teammitglied jedes Jahr erhält.

Eine neue Art zu arbeiten gestalten

Die Einführung eines Shape Up-Verfahrens hier bei Easy Agile hat es uns ermöglicht, bei der Arbeit, die wir übernehmen, an Konzentration und Sicherheit zu gewinnen. Es ermöglicht uns, langfristige Ziele zu verfolgen, ohne unflexible Roadmaps erstellen zu müssen. Unsere Produktmanager werden ermutigt, sich die Zeit zu nehmen, die sie benötigen, um sich zu konzentrieren und fantastische neue Lösungen für unsere Kunden zu entwickeln. Der sechswöchige Zyklus gibt uns die Flexibilität, auf externe Veränderungen zu reagieren oder neue Chancen zu nutzen, die sich ergeben, ohne dass die Pläne für den Rest des Jahres aus den Fugen geraten. Wir können die Erkenntnisse aus unseren vergangenen Gelegenheiten nutzen und sie in den Plan für das nächste einfließen lassen, wodurch unsere Erfolgschancen erhöht werden.

Die Entwicklungsteams von Easy Agile sind flexibel und entscheiden, mit wem sie zusammenarbeiten und woran sie arbeiten. Wir zahlen ständig technische Schulden ab und meiden Bürokratie, veraltete Systeme und heilige Kühe. Wir arbeiten in funktionsübergreifenden und flexiblen Teams.

Wir konnten Shape Up übernehmen und Dinge wie Dash Days und unsere Unternehmenswerte einbauen. Wir lieben es, dass die Art und Weise, wie wir arbeiten, es uns ermöglicht (und uns ermutigt), alle 6 Wochen innezuhalten, durchzuatmen und unserer Kreativität freien Lauf zu lassen. Die Tech Debt Week und die Dash Days sind auch eine großartige Möglichkeit, die Konzentration unseres Entwicklungsteams auf ihre Hauptprojekte zu erhöhen, indem kleine Aufgaben, die sie unterbrechen und ablenken, verschoben werden.

Wir glauben, dass ein stetiger, das Leben inklusiver und ausgewogener Ansatz, bei dem wir jeden Tag unser ganzes Ich zur Arbeit bringen, besser ist, als sich auszubrennen und unrealistische Termine einzuhalten.

Und schließlich, während wir wachsen, wissen wir, dass das System, auf dem Easy Agile läuft Testament ändern Sie sich weiter, um uns zu helfen, eine bessere Arbeitsweise zu finden.

Psychologische Sicherheit ist der Schlüssel zu leistungsstarken Teams. Aber wie entsteht sie?

Agilität ist die Reaktion auf eine komplizierte Situation, in der Unbekanntes das Bekannte außer Kraft setzt. In einem leistungsstarken Team haben alle Mitglieder ihre Meinung zu Wort und es gibt mehrere Entscheidungsträger. Psychologische Sicherheit ist die Überzeugung, dass der Arbeitsplatz sicher ist, um Ideen, Bedenken oder sogar Misserfolge zu äußern.

Aber wo passt Freundlichkeit rein?

Freundlichkeit ist die Grundlage für psychologische Sicherheit.

Freundlichkeit ist in jeder der ersten drei Phasen von unerlässlich Dr. Timothy R. Clark Das Modell der psychologischen Sicherheit in 4 Stufen.

Stufe 1: Inklusion und Sicherheit

Menschen sehnen sich danach, akzeptiert zu werden, bevor sie gehört werden müssen. Als Führungskraft können Sie Inklusion schaffen, indem Sie Freundlichkeit zeigen, sensibel und neugierig auf das Leben eines Mitarbeiters sind. Ein guter Ausgangspunkt ist; wie war dein Wochenende? Wie geht es der Familie diese Woche? Stehen irgendwelche aufregenden Feierlichkeiten an? Du scheinst heute etwas ruhig zu sein, ist alles in Ordnung?

Stufe 2: Sicherheit der Lernenden

Menschen müssen Fragen stellen, Feedback geben und erhalten und Fehler machen, während sie sich sicher fühlen. Freundlichkeit zu zeigen, schafft das Vertrauen dazu.

Stufe 3: Sicherheit der Mitwirkenden

Menschen müssen sich sicher fühlen, um als Teammitglieder teilnehmen zu können. Ein Bekenntnis zur Freundlichkeit sorgt für einen besseren Informationsfluss, bessere Verbindungen bei der Arbeit und eine verstärkte Zusammenarbeit.

Menschen gedeihen in Umgebungen mit psychologischer Sicherheit. Angst löst den Instinkt der Selbstzensur aus und hält uns zurück. Wenn die Umwelt die psychologische Sicherheit fördert, nehmen Selbstvertrauen, Engagement und Leistungsfähigkeit zu.

3 Tipps für die Implementierung von Freundlichkeit in Ihrem Team noch heute

Tipp 1: Modellieren Sie selbst Freundlichkeit. Egal, welche Rolle Sie spielen, Freundlichkeit ist ansteckend. Wenn Sie anfangen, sich freundlich zu verhalten, wird sich das bald auf Ihr gesamtes Team ausbreiten. Du kannst freundlich dienen, indem du zuhörst, mit Vergebung arbeitest, eine helfende Hand anbietest, Sorge zeigst oder wichtige Ereignisse im Leben eines Kollegen feierst.

Um den Tag der zufälligen guten Taten zu feiern und unseren Unternehmenswert Give Back zu leben, spendete unser Team an Kind Hearts Illawarra.

Tipp 2: Integrieren Sie Freundlichkeit in die Zeremonien Ihres Teams. Jedes Teammitglied kann beim morgendlichen Zusammensitzen eine Sache sagen, für die es dankbar ist. Bei jeder Zeremonie kann Platz gelassen werden, um sich bei einem anderen Teammitglied zu bedanken. Bei Easy Agile setzen wir dies in die Praxis um, indem wir alle ermutigen, jeden Tag eine „gute Sache“ mit anderen zu teilen.

Tipp 3: Implementieren Gut, danke in deiner Firma Slack. Die Good Thnx Foundation stellt eine Verbindung zwischen Menschen und Unternehmen, die spenden wollen, und Wohltätigkeitsorganisationen her. Während sich unser Team gegenseitig „dankt“, erhält der Empfänger 50$, um an eine Wohltätigkeitsorganisation seiner Wahl zu spenden. Unser Beitrag über Good Thanx für das Geschäftsjahr 21 betrug 15.201$.

Einfach ausgedrückt, seien Sie noch heute nett; es ist kostenlos und ermöglicht leistungsstarke agile Teams!

Bei Easy Agile orientieren wir uns (natürlich) an agilen Prinzipien und bemühen uns, Softwareentwicklungsteams dabei zu unterstützen, agile Methoden in die Praxis umzusetzen. Da jedoch jeden Tag so viel zu erledigen ist, ist es leicht, die Kernprinzipien der agiles Manifest.

Sie denken wahrscheinlich, dass Sie die agilen Prinzipien schon einmal gelesen haben und sie jetzt in die Praxis umsetzen... den ganzen Tag, jeden Tag. Warum müssen wir sie noch einmal überdenken?

Sie müssen die Prinzipien nicht auswendig lernen. Sie sind viel mehr ein Leitfaden als ein Routineprozess. Aber wenn Sie die agilen Prinzipien mit Ihren täglichen agilen Praktiken abgleichen, wird bestätigt, dass Sie sie in die Tat umsetzen. Dies hilft Ihnen auch dabei, Bereiche zu identifizieren, in denen Verbesserungen möglich sind. 🙌

Die anhaltende Relevanz der Prinzipien des agilen Manifests

Das agile Manifest konzentriert sich auf:

• Kontinuierliche Verbesserung durch Reaktion auf Feedback und Änderungen
• Es ermöglicht Softwareentwicklern und funktionsübergreifenden Teams, sich so zu organisieren, dass Zusammenarbeit und Interaktion gefördert werden
• Kunden in den Entwicklungsprozess einbeziehen und auf ihr Feedback reagieren

Das Manifest skizziert 12 agile Prinzipien, die das A und O der agilen Softwareentwicklung sind. Wir möchten diesen agilen Prinzipien einen praktischen Kontext bieten und werden sie daher in drei Kategorien unterteilen: Entwicklung funktionierender Software durch Organisation, Unterstützung der Teams bei der Zusammenarbeit und Taktiken zur Kundenzufriedenheit.

Organisieren Sie sich, damit Sie funktionierende Software erstellen können

Die ersten agilen Prinzipien, die wir besprechen werden, drehen sich um das Konzept einer funktionierenden Software — ein Produkt, das Ihre Kunden so früh wie möglich im Softwareentwicklungsprozess verwenden können. Sie passen es an, sobald Sie Feedback darüber erhalten, was gut funktioniert und was verbessert werden könnte. Dies steht im Gegensatz zu einem Wasserfall von der Methodik bis zur Entwicklung, bei der es sich um einen lineareren Ansatz handelt, der in der Regel keine iterativen Aktualisierungen zulässt.

Ein Ziel ist es, funktionierende Software zu entwickeln, die kontinuierlich aktualisiert werden kann. Aber das ist leichter gesagt als getan ohne die Hilfe von speziell entwickelten Tools wie Jira, dessen Ziel es ist, agilen Teams bei der Verwaltung ihres gewählten agilen Frameworks zu helfen, sei es Kanban oder Gedränge. (Sie können unseren Leitfaden zu den Unterschieden zwischen lesen Kanban und Scrum... oder wie man sie zusammen benutzt. 💪)

Schauen wir uns nun an, welche der 12 agilen Prinzipien in diese Kategorie fallen — #3, #7 und #8 — und wie Jira dabei hilft, ein Framework zu implementieren, das diesen Prinzipien entspricht.

Agiles Prinzip #3

„Stellen Sie häufig funktionierende Software bereit, von ein paar Wochen bis zu ein paar Monaten, wobei Sie den kürzeren Zeitrahmen bevorzugen.“

Atlassian (die Macher von Jira) fasst zusammen die Verkörperung dieses Prinzips perfekt in seiner Definition eines Sprints: „Ein Sprint ist ein kurzer, zeitlich begrenzter Zeitraum, in dem ein Scrum-Team daran arbeitet, eine bestimmte Menge an Arbeit zu erledigen.“

Agile Sprints laufen zwar über einen kurzen Zeitraum, aber ihre reibungslose Ausführung erfordert für Produktbesitzer und Softwareentwickler viel Arbeit. Zum Glück bietet Jira Möglichkeiten, diese Arbeit zu rationalisieren — sieh dir unseren Leitfaden an Teile deines Sprints automatisieren.

Agiles Prinzip #7

„Funktionierende Software ist das wichtigste Maß für Fortschritt.“

Mit Sprints können Sie sicherstellen, dass Ihr Team schrittweise funktionierende Software bereitstellt. Wenn ein Sprint gut genug geplant ist, kann er als Stopp für die Veröffentlichung Ihrer nächsten Reihe von Features und Funktionen für Ihre Endbenutzer dienen.

Agiles Prinzip #8

„Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Nutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.“

Agile Frameworks wie Scrum können dabei helfen zu messen, ob ein Team ein konsistentes Tempo einhält. Innerhalb von Sprints kann der Aufwand auf verschiedene Arten gemessen werden, wie agile Storypoints. Wenn Sprints abgeschlossen sind, erstellt Jira automatisch einen visuellen Bericht darüber, wie viele Storypoints ein Team in seinem Team von Sprint zu Sprint abschließt Geschwindigkeitstabelle.

Zeit für Teamzusammenarbeit

Du bist ein agiles Team, das funktionierende Software bereitstellt und ein Super-Tool wie Jira nutzt, um deine Arbeit zu planen und deine Fortschritte zu verfolgen. Aber du brauchst eine menschliche Berührung, um wirklich agilen Werten zu folgen. Bitte begrüßen Sie die agilen Prinzipien #4, #6, #11, #5 und #12 auf der Bühne.

Agiles Prinzip #4

„Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.“

Tägliche Stand-up-Meetings sind eine Manifestation dieses Prinzips. In diesem Meeting ging jedes Teammitglied auf drei Themen ein: (1) woran sie gestern gearbeitet haben; (2) woran sie heute arbeiten; und (3) was sie daran hindert, heute Fortschritte zu erzielen.

Agiles Prinzip #6

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu vermitteln, ist ein persönliches Gespräch.“

Ob in einem persönlichen Meeting oder in einem Remote-Meeting, die Vermittlung von Informationen ist schwierig — aber (puh) wir haben das bereits mit Methoden wie täglichen Sprints und Geschwindigkeitsdiagrammen angegangen, um Informationen zwischen den Teammitgliedern auszutauschen und den Teamfortschritt visuell zu überprüfen. Und schon bald werden Sie andere Möglichkeiten sehen, wie agile Softwareentwicklungsteams sich organisieren und miteinander kommunizieren.

Agiles Prinzip #11

„Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren.“

Nun, zunächst, was genau ist ein sich selbst organisierendes Team? Es bedarf keiner Anleitung oder eines Mikromanagements von außen, um herauszufinden, woran gearbeitet werden muss und wie diese Arbeit definiert und priorisiert wird. Diese Teams finden heraus, wie sie ihre Arbeit planen, iterieren, um diese Arbeit zu erledigen, und arbeiten dann gemeinsam daran, wie sie sich kontinuierlich verbessern können. Das agile Scrum-Zeremonien — Stand Up, Sprint Planning, Sprint Review und Retrospektive — sind ein praktisches Beispiel dafür.

Agiles Prinzip #5

„Baue Projekte rund um motivierte Menschen auf. Bieten Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie die Arbeit erledigen.“

Ok, nach diesem Prinzip sind wir aus dem Ruder gelaufen — aber aus gutem Grund. Das Befolgen des Prinzips #11 ist sinnvoll, da gute, selbstorganisierte Teams von Natur aus motiviert sind. Sie arbeiten zusammen, um herauszufinden, wie die Arbeit erledigt werden kann, und um sich gegenseitig zu helfen, wenn jemand nicht weiterkommt. Nichtsdestotrotz ist es wichtig, dass definierte Rollen in einem agilen Team, wie ein Scrum Master, der Teammitglieder motivieren und ihnen Feedback geben kann.

Agiles Prinzip #12

„In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt dann sein Verhalten entsprechend an.“

Dieses Prinzip beschreibt perfekt eine Rückblick — eine Teambesprechung, um über deinen letzten Sprint oder deine letzte Iteration nachzudenken und zu besprechen, wie du dich für den nächsten Sprint verbessern kannst. Indem du diese Fragen beantwortest: (1) Was lief gut? ; (2) Was hätte besser laufen können? ; und (3) Was können wir anpassen, um uns beim nächsten Mal zu verbessern? Ihr Team arbeitet zusammen und interagiert, um effektiver zu werden.

Kundenzufriedenheit erreichen

Nicht zuletzt gehören zu den agilen Prinzipien auch Kundenbedürfnisse. Wer ist Ihr Kunde? Was sind ihre Bedürfnisse? Wie reagieren Sie auf ihr Feedback, um sicherzustellen, dass Sie ein funktionierendes Produkt anbieten, das sie lieben? Geben Sie die Prinzipien #1, #2, #9 und #10 ein.

Agiles Prinzip #1

„Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.“

Es stellt sich heraus, dass Sie wissen müssen, wer Ihr Kunde ist, um Ihren Kunden zufrieden zu stellen. 😉 Das erfordert Arbeit. Eine bewährte Methode, um herauszufinden, wer Ihre Kunden sind, besteht darin, Kundenpersönlichkeiten. Dabei handelt es sich um fiktive Profile Ihrer Kunden, die Dinge wie ihre Verhaltensmuster, ihre gemeinsamen Probleme und das Aussehen ihrer allgemeinen demografischen Informationen dokumentieren.

Agiles Prinzip #2

„Wir begrüßen die sich ändernden Anforderungen, auch in der späten Entwicklungsphase. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“

Anforderungen können nur wirksam geändert werden, wenn sie definiert und den Stakeholdern zur Rückmeldung zur Verfügung gestellt werden. Selbst wenn dieses Feedback spät in einem Entwicklungszyklus zu Veränderungen führt, ist das in Ordnung! (Wahrscheinlich erhalten Sie auch Feedback zu der funktionierenden Software, die Sie bereits geliefert haben. 😎) Tools wie ein Produkt-Roadmap oder ein User-Story-Map die visuelle Ansicht Ihres Produkt-Backlogs bieten Ihren Kunden und Stakeholdern eine Plattform, auf der sie Feedback geben können.

Agiles Prinzip #9

„Kontinuierliches Augenmerk auf technische Exzellenz und gutes Design erhöht die Agilität.“

Ein Wort: Rückblick.

Ok, noch zwei Worte: Sprint Review.

Im Zusammenhang mit Prinzip #9 sind die Retrospektive und das Sprint-Review zwei agile Zeremonien, mit denen Sie die Qualität und das Design Ihrer Software kontinuierlich anpassen können, um die Bedürfnisse Ihrer Kunden bestmöglich zu erfüllen.

Agiles Prinzip #10

„Einfachheit — die Kunst, die Menge der nicht geleisteten Arbeit zu maximieren — ist unerlässlich.“

Stellen Sie sich vor, Sie hätten Ansichten Ihrer Kundenprofile (Personas), eine visuelle Abbildung ihrer Reise durch Ihr Produkt (User Story Map) und eine priorisierte Ansicht Ihres Plans zur Auslieferung Ihres Produkts (Roadmap). Was für eine Zeit, um am Leben zu sein! Wenn Sie alle drei Dinge tun, hat Ihr Team wahrscheinlich ziemlich gute Einblicke in die Frage, ob Sie die richtige Arbeit erledigen oder nicht. 💪

Die 12 agilen Prinzipien in die Tat umsetzen

Jetzt verstehst du, wie die agilen Prinzipien in agile Frameworks umgewandelt wurden und wie Tools wie Jira agilen Teams helfen können, mit diesen Frameworks zu arbeiten. Wir haben auch drei effektive Möglichkeiten erwähnt, um diese Prinzipien in die Tat umzusetzen, und unsere Produkte machen es einfach.

• Einfacher agiler Teamrhythmus unterstützt agile Teams von der Planung bis zur Überprüfung mit Funktionen, die User Story Mapping, Backlog-Refinement, Sprint- und Versionsplanung sowie Team-Retrospektiven unterstützen.
• Einfache Agile Personas für Jira bietet Teams einen kundenorientierten Ansatz zur Verfeinerung von Backlogs.
• Einfache Agile Roadmaps für Jira bietet Teams und Stakeholdern visuelle Einblicke in die Vision und den Plan für ein Produkt.
• Einfache agile Programme ist eine komplette PI-Planungslösung, die eine skalierte teamübergreifende Planung und Ausführung einfach macht.

Schauen Sie sich alle unsere agilen Lösungen an in Der Marktplatz von Atlassian!