Verstehen, warum Salesforce agile Prozesse eingeführt hat

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

• Erläutern, warum Salesforce dem agilen Ansatz folgt
  
• Auflisten einiger Vorteile des agilen Ansatzes
  
• Definieren von Scrum
  
• Erläutern, was "Definition of Done" ist
  
• Verstehen, warum agile Prozesse für Salesforce besser funktionieren
  

Stellen Sie sich vor, Sie gehen zur Dreamforce und müssen feststellen, dass Sie keine Keynotes, keine neuen Produkt- oder Serviceankündigungen und keine Innovationen oder produktionsreife Funktionen für das nächste Jahr haben.

Dies ist Salesforce im Jahr 2006 fast widerfahren, aber wir konnten dieses Szenario abwenden, indem wir einen neuen Workflow implementiert haben, der die Art und Weise, wie wir Produkte entwickeln und ausliefern, revolutioniert hat.

Seit 1999, dem Gründungsjahr von Salesforce, hat unsere Technology & Products-Abteilung (kurz T&P) wie am Schnürchen ausgeliefert. Die Kommunikation und Zusammenarbeit unter den T&P-Teams war immer reibungslos und einfach. Im Jahr 2006 jedoch sind wir explosionsartig gewachsen – wir hatten mehr Kunden, mehr Umsatz, mehr Produkte und ein größeres Unternehmen. Und wie bei jedem Wachstumsschub, lief es nicht ohne Schmerzen ab. 

Alles, was zuvor mit Leichtigkeit geschah, war jetzt nicht mehr so einfach. Infolgedessen ließ bei uns die Innovationsdynamik nach. 

Kommunikation, Zusammenarbeit und Management auszubauen und dabei gleichzeitig unsere Veröffentlichungstermine einzuhalten, war zu einer Herausforderung geworden. Es war klar, dass wir eine neue Herangehensweise mit Fokus auf einen reibungslosen Produktauslieferungsprozess brauchten – eine, die sicherstellen würde, dass es zu keinen Veröffentlichungsverzögerungen kommt. 

Also haben wir das getan, was wir am besten können: ins kalte Wasser springen und uns neu erfinden, respektive die Art und Weise, wie wir Lösungen ausliefern. Und dazu haben wir einen Satz von agilen Prinzipien und Vorgehensweisen eingeführt.

Warum der agile Ansatz?

Unsere Arbeit bei Salesforce ist größtenteils innovationsorientiert und iterativ. Das heißt, das Endergebnis ist nicht immer im Voraus bekannt und der Weg dorthin ist laufende Arbeit. Es ist immer ein neues Abenteuer! 

Das bedeutet jedoch nicht, dass alle Teams bei Salesforce agile Prozesse verwenden. Manche Teams gehen nach dem Wasserfallprinzip vor, einem Projektmanagementprozess, der wesentlich unflexibler ist. Welchen Prozess Sie wählen, hängt davon ab, was Sie bei Arbeitsbeginn wissen und was nicht.

Hier ein kurzer Überblick über Wasserfallmethoden:

• Alles wird im Voraus geplant.
  
• Die Anforderungen werden vor der Implementierung detailliert erfasst.
  
• Jeder Schritt muss abgeschlossen sein, bevor der nächste begonnen wird.
  
• Das Ergebnis wird am Anfang festgelegt.
  

Planen im Vergleich zu Anpassen

Halten Sie sich bei der Entscheidung, welcher Prozess für Sie am besten funktioniert, Folgendes vor Augen: Wenn Sie ein Bild malen und vorab festlegen, welche Farben und welches Motiv Sie verwenden, wie viel Zeit Sie mit dem Malen verbringen und wie das fertige Bild aussieht, haben Sie während des Malens wenig Spielraum für Änderungen. Was nicht heißen soll, dass dabei kein Picasso herauskommt. Ihr Prozess ist nur nicht darauf ausgelegt, neue Ideen und Meinungen einzubeziehen, die das endgültige Bild ändern können (zum Besseren natürlich). Hierbei handelt es sich um eine Wasserfallmethode.

Wenn Sie jedoch iterativ malen, werden Sie wahrscheinlich Änderungen auf Basis von frühzeitigem Feedback, neuen Ideen oder sogar neuen Erkenntnissen (diese Farben beißen sich!) vornehmen, und nicht in einer geplanten, inkrementellen Weise malen. Dies ist ein agilerer Ansatz. 

Hier sehen Sie eine bildliche Darstellung dieser zwei Malvorgänge: 

Das Bild basiert auf der Arbeit von Jeff Patton, verwendet mit freundlicher Genehmigung von jpattonassociates.com.

Arbeitskomplexität

Jetzt wissen Sie also, dass unterschiedliche Prozesse für unterschiedliche Arten von Arbeit besser sind. Wie bestimmen Sie aber, welcher Prozess für Sie und Ihr Team am besten ist?  

Stellen Sie sich bei der Auswahl eines Workflow-Prozesses folgende Fragen: 

• Wie viel wissen wir über das vorliegende Projekt?
  
• Wie klar sind die Zielsetzungen und Anforderungen des Projekts?
  
• Wie klar und gut definiert ist die Lösung?
  
• Welche Erfahrung haben das Team und die Beteiligten mit diesen Methodologien?
  
• Wie komplex ist die Arbeit?
  

Wann der Wasserfallprozess zu verwenden ist

Einfache Arbeit:

• Die Arbeit ist einfach und vorhersehbar.
  
• Jeder kann bestimmen, wie die Arbeit ausgeführt wird.
  

Komplizierte Arbeit:

• Die Arbeit ist vorhersehbar, erfordert aber Know-how.
  
• Die Arbeit kann automatisiert werden.
  

Wann der agile Prozess zu verwenden ist 

Komplexe Arbeit:

• Die Arbeit fußt auf stetiger Rückmeldung, Risikobereitschaft und Innovation.
  

• Sie möchten etwas ausprobieren, schauen, ob es funktioniert, und den Kurs ändern, wenn sich neue Erkenntnisse ergeben.
  
• Sie entwickeln neue Produkte, Software und Services und tun Dinge, die noch nie jemand zuvor versucht hat.
  

Skalierung von Salesforce auf agile Weise

Die Führungsriege von Salesforce hat damals ein Pilotprojekt begonnen, um agile Vorgehensweisen in verschiedenen Teams zu implementieren. Es gab etwas Gegenwind, aber die Führungskräfte von Salesforce hielten am Konzept fest, sodass das Technology & Products-Team von Salesforce 2006 zu einem agilen Entwicklungsteam umstrukturiert wurde.

Wie sah dies aus? Nun, wir haben Folgendes getan: 

1. Die Auslieferung neu gedacht
   
2. Standardisierte Prozesse implementiert
   
3. Schlanke Prinzipien eingeführt (darüber später mehr!)
   
4. Standardisiert, was "erledigte Arbeit" bedeutet
   

Unsere neue agile Denkweise 

Was ist dieser agile Prozess genau? Einfach ausgedrückt, ist "agil" ein Oberbegriff für verschiedene technische Vorgehensweisen, Prozesse, Frameworks, Prinzipien und Werte, die Flexibilität für Workflows und iterative Änderungen an Produkten verlangen.  

Es ist ein iterativer Arbeitsansatz, bei dem Teams Produkte von Projektbeginn an inkrementell entwickeln und nicht versuchen, das eine finale Produkt am Schluss zu liefern. Der agile Ansatz hilft nicht nur bei der internen Abstimmung von Teams und der Verbesserung der Qualität, er zwingt auch jeden, Fortschritt zu messen und zu verwalten, um Kunden schneller Mehrwert zu liefern. 

Bei Salesforce hat es perfekt funktioniert, da wir nach einer Lösung für unsere wachsenden Kommunikations- und Skalierungsprobleme gesucht haben.

Unser neuer agiler Prozess: Ein Blick aus der Vogelperspektive 

Einer der agilen Prozesse, die wir bei Salesforce implementiert haben, ist Scrum. Und zur Unterstützung dieser Prozesse wurden bestimmte Prinzipien eingeführt, die unsere heutige Arbeitsweise definieren.

Was ist Scrum?  

Scrum ist ein Prozess mit festgelegten Rollen, Besprechungen und Ergebnissen, der den Rahmen bietet, um unseren Kunden schneller Mehrwert mit hoher Qualität zu liefern.

Warum haben wir Scrum eingeführt? 

Scrum stellt uns ein flexibles Framework bereit, um herauszufinden, was mit unseren Produkten funktioniert und was nicht, und entsprechende Änderungen vorzunehmen. Mit Scrum hat jeder Eigenverantwortung und gemeinsame Erwartungen in Bezug auf die Arbeit, die vor ihm liegt. 

Wie sieht der Scrum-Prozess bei Salesforce aus? 

Nun, als wir ihn eingeführt haben, waren 150 Personen auf kleine, funktionsübergreifende Teams verteilt, die in kurzen Iterationen gearbeitet haben (wir nennen diese Sprints). Das Ziel war, die Auslieferung zu stabilisieren und unseren Prozess zu ordnen. Derzeit verwendet die Mehrheit der Salesforce-Cloudteams eine Variation von Scrum. 

Was sind schlanke Prinzipien?

Wir haben außerdem schlanke Prinzipien eingeführt. Dabei handelt es sich um sieben Aussagen, die unseren Workflow und Auslieferungsprozess beschreiben. Sie spiegeln unsere Ohana-Kultur wider und zeigen auf, wie Menschen am besten zusammenarbeiten, um unsere Erfolgsstruktur zu unterstützen. Wir werden später ausführlicher auf sie eingehen.

Die neue Definition von "erledigter Arbeit"

Nachdem wir jetzt eine neue Arbeitsweise hatten, konnten Teams ihren Prozess erfolgreich wiederholen, wenn sie Neues über ihren Workflow und das Produkt gelernt haben. Aber woran konnten wir ablesen, dass wir mit einer bestimmten Arbeit wirklich fertig waren?  

Ganz einfach. Wir haben eine Definition of Done (DoD) für unsere Technology & Products-Teams festgelegt, mit der jeder klar und deutlich erkennen kann, wann etwas – na ja – einfach fertig ist.

Stellen Sie sich folgendes Szenario vor: Sie müssen den Funktionsumfang eines Produkts um eine neue Funktion erweitern. Sie geben diese neue Aufgabe an Ihr Team weiter und weisen es an, die Funktion diesen Monat zu implementieren. Das Team erledigt dies und geht zu anderen Aufgaben über. Ein paar Monate später taucht die erledigte Arbeit mit neuen Problemen wieder auf. Vielleicht gab es Kundenbeschwerden, weil Integrationen nicht voll ausgetestet waren. Möglicherweise wurden Sicherheitsprobleme nicht angegangen oder die Leistung hat die Anforderungen nicht erfüllt. Die Schlussfolgerung: Die Arbeit war nicht wirklich abgeschlossen, jedenfalls nicht weit genug, um sie bereitzustellen.

Unsere Definition of Done ist ein Richtliniensatz, der alles vorgibt, was ein Team tun muss, bevor es die Arbeit als wirklich erledigt bezeichnen kann. Die Entwicklung eines solchen Standards ist entscheidend für die Aufrechterhaltung einer der Grundwerte von Salesforce: Vertrauen.

Fazit

Wir fragen uns ständig: "Tun wir das Richtige auf die richtige Weise?" Dies ist unsere Art, dafür zu sorgen, dass unsere Kunden bei allem, was wir tun, immer im Mittelpunkt stehen.  

Die Stringenz des Scrum-Prozesses zusammen mit unserer agilen und schlanken Denkweise bilden den Grundstein, um unsere Auslieferung zu verbessern und reibungslosere Veröffentlichungen zu gewährleisten. Dies ist von zentraler Bedeutung, da Salesforce drei Hauptversionen pro Jahr für seine Kunden veröffentlicht.