Nina Wilhelm hat sich dazu Gedanken gemacht und uns die Vorschläge präsentiert. Um es kurz zu machen, wir sind begeistert. Trotzdem möchten wir von Euch auch ein paar Feedbacks haben. Also los, sagt uns ob Nina mit diesen Vorschlägen auch Euern Geschmack trifft und was wir sonst noch an der Seite verbessern könnten!

Home

Beitrag

Suche

Wer also wissen will wie das Buch entstanden ist, was darin enthalten ist und warum man es zwingend kaufen muss, sollte sich den Podcast 126 von Michael Greth zu Gemüte führen.

Genau da setzt das Seminar an. Es richtet sich an Entscheidungsträger, die den Nutzen von Enterprise 2.0-Konzepten für ihr Unternehmen/Team einschätzen sowie die wichtigsten Aufgaben bei der Einführung eines „Collaboration Workplaces“ kennen lernen wollen.

Die Inhalte des Seminars basieren auf den Ergebnissen des Forschungsprojektes IMPACT, das in Kooperation von Microsoft Deutschland, OSN und des Business 2.0 – Center for Innovations in Business Processes an der Universität St. Gallen durchgeführt wurde.

Alle Informationen zum Seminar finden Sie hier zum Durchklicken und zum Download.

Nach fast einem Jahr Arbeit ist es nun endlich soweit. Das Buch, das Reiner Ganser und ich geschrieben haben, ist im Handel verfügbar. Der Titel „Erfolgreiche Portalprojekte mit Microsoft SharePoint, Praxishandbuch für die erfolgreiche Steuerung von SharePoint-Projekten“ beschreibt sehr genau, was der Inhalt des Buches ist.

Das Ziel des Buches ist, unsere Erfahrung in den Bereichen

• Chancen und Herausforderungen erkennen und Projekte erfolgreich steuern
• Intranetportal- und Zusammenarbeitstechnologien für Projektmanager

herauszuarbeiten und mit Tipps und Erfahrungen zu versehen. Die Nutzung der Microsoft Office SharePoint-Technologien bietet neue Möglichkeiten für die Zusammenarbeit in Organisationen. Diese Tools wirken sich aber auch rückkoppelnd auf die Organisationsform und die Zusammenarbeit der Mitarbeiter aus. Dieses Buch soll die Eckpunkte und Chancen, aber auch die Gefahren zeigen, die ein SharePoint-Projekt mit sich bringt. Als Ziele einer SharePoint-Einführung werden meist auch Stichworte wie Zusammenarbeit, Kommunikation, Communitys, Knowledge Management, Wiki, Blog und weitere Web 2.0-Begriffe genannt. So verändern diese Projekte die Art der Zusammenarbeit nachhaltig und machen Platz für tiefgreifende Veränderungen im Unternehmen. Dies betrifft die Art, wie Menschen Informationen austauschen, mit Prozessen und Informationen umgehen und letztendlich, wie sie mit sich und anderen umgehen werden. Diese Punkte sind für den Erfolg von Portalprojekten von SharePoint von zentraler Bedeutung.

Das Buch ist bei MS Press erschienen. Es kann direkt dort oder bei Amazon erstanden werden.

Im Grunde genommen ist das Agile-Software Development Framework nichts anders als eine schlaue Art, Teams, Personen und deren Aufgaben zu organisieren. Es beinhaltet Elemente aus dem Projektmanagement, Team-Führung, Aufgabenmanagement und Psychologie. Agile verbindet diese Elemente zu einem Paket, welches die Ausführung und die Übersicht von komplexen Aufgaben stark vereinfacht.

Agile development process

Eines der grossen Vorteile von Agile ist, dass man dieses Framework völlig auf die eigenen Arbeitsgewohnheiten anpassen kann. Es ist unmöglich, Agile falsch anzuwenden. Man entscheidet wohl eher, wie oft und wie intensiv man die Agile Methodik anwenden will.
Es gibt vielleicht Methoden in Agile, die nicht auf Ihre Unternehmensphilosophie oder Arbeitsweise passen. So what? Man lässt sie einfach weg oder passt die Methoden an. Ein Beispiel: es gibt eine Methode um die Komplexität von Aufgaben zu bestimmen, die sich “Estimation poker” (Engl. Schätzungs-Poker) nennt. Estimation Poker ist eine spielerische Art, ein mehr oder weniger langweiliger Prozess interessant und spannend zu machen. Wie Estimation Poker funktioniert, werde ich unten noch erklären. Estimation Poker mag vielleicht nicht allen passen. Dann macht man die Schätzungen der Aufgaben einfach anders.

Elemente des Agile Framework

Epic: Epics sind längere, komplexe Aufgaben. Epics können kleine Projekte, Subprojekte oder Aufgaben sein, die mehrere Wochen benötigen um fertig gestellt zu werden. Zum Beispiel die Erstellung einer komplexen MOSS 2007 Farm-Architektur könnte man in die Kategorie Epic werfen.

User Stories: Innerhalb von Epics werden User Stories definiert. Diese User Stories sind gruppierte Aufgaben, die im Bezug zueinander stehen. In der Regel wird die Komplexität von User Stories bewertet. Man einigt sich auf eine Skala von Werten (meistens die Fibonacci Zahlenreihe) um der Komplexität einer Story eine Gewichtung zu geben. Die Komplexität (Story points) aller Userstories innerhalb eines Epics werden summiert und somit wird die Gesamtkomplexität des Epics ausgerechnet.
Die Evaluation einer neuen SSO Technologie kann man als User Story bezeichnen.

Tasks: User Stories werden in einzelne genau definierte Tasks (Aufgaben) unterteilt. Jede Aufgabe muss so klar definiert sein, dass einzelne Aufgaben innerhalb des Teams weitergegeben werden können. Für jede Aufgabe wird der Aufwand in Stunden geschätzt. Die Summe der Stunden aller Tasks ergeben die Anzahl Stunden für die User Story. Die Summe der Stunden aller User Stories ergibt die Anzahl Stunden eines Epics. Beispiel für einen Task: Die Dokumentation einer Applikation oder Teile der Applikation.

Scrum:  Scrumming ist wohl die Essenz des Agile-Frameworks. In den Scrums (deutsch: Gedränge) treffen sich Teammitglieder, Teams oder sogar das ganze Unternehmen für Planung, Kommunikation, Retrospectives (deutsch: Rückblicke), Zeitrapportierung, usw. Der Hauptunterschied zwischen Scrums und konventionellen Meetings besteht darin, dass der Informationsfluss viel strukturierter abläuft als in „normalen“ Meetings. Bei jeder Art von Scrum ist genau definiert, was der Informations-Input ist und was dabei heraus schauen soll. Im Scrum dreht sich grundsätzlich alles um den „Sprint“. In einem Daily Scrum werden täglich Informationen zum laufenden Sprint ausgetauscht. Man kann sogar so weit gehen, dass man stündlich Micro-Scrums abhält um hochkomplexe Aufgaben im Team zu bewältigen.

Sprint: Das Agile Gegenstück zum Scrum ist der Sprint. In einem Sprint geschieht die eigentliche Magie . Sprints sind zeitlich begrenzte Arbeitsphasen. In Sprints werden die geplanten Aufgaben erledigt. Teammittglieder suchen sich eine passende User Story für den Sprint aus und arbeiten die dazu gehörigen Aufgaben ab. Daily Scrums sind dazu da, den Fortschritt der Arbeit an den User Stories zu rapportieren oder an andere Teammitglieder weiterzugeben.

Burndown chart: Für jede Aufgabe wird der Aufwand in Anzahl Stunden geschätzt. Während des Sprints rapportiert die Person die verbrauchten Stunden für den Task. In einem Burndown Chart werden die geschätzten und effektiv verbrauchten Stunden für eine Aufgabe gegenüber gestellt. Anhand des Burndown-Charts kann man die Aufgabenerledigungs-Geschwindigkeit (Velocity) des ganzen Teams ablesen.

Sample burndown chart

Retrospective: Ist ein Sprint zu Ende, wird ein Retrospective-Meeting einberufen. In diesem Meeting hat man die Möglichkeit, Positives oder Negatives über den vergangenen Sprint auf den Tisch zu bringen und zu gewichten. Normalerweise laufen Retrospectives so ab: Jedes Teammitglied überlegt sich für „Stop doing“, „Keep on doing“ und „Start doing“ Items aus. Diese Items werden gesammelt und dann gewichtet. Normalerweise bekommt man pro Kategorie drei Stimmen. Für jene „Stop doing“ Items, welche nur eine Stimme kriegen werden Verbesserungs-Massnahmen diskutiert. Ergebnisse von Retrospectives werden immer an das Mittlere oder sogar höhere Kader kommuniziert.

Backlog: Eine Liste von User Stories sortiert nach Priorität und kategorisiert nach Projekt oder Projekt-Team. Im Backlog werden alle anfallenden Arbeiten für das Aktuelle Projekt (oder was auch immer) gesammelt und verwaltet. Jedes Entwickler Team, jede Abteilung und sogar das ganze Unternehmen hat seinen eigenen Backlog.

Estimation poker: Dies ist eine tolle Methode, eine trockene und eher mühselige Aufgabe in eine spannende und produktive Sitzung zu verwandeln. Es geht darum, im Team die Komplexität von User Stories zu bestimmen. Man nimmt eine User Story vom Backlog und diskutiert die Story im Team, bis alle ein gemeinsames Verständnis der Story haben. Danach denkt sich jedes Mitglied im Kopf eine Zahl aus, die seines Ermessens der Komplexität der User Story entspricht. Auf ein Zeichen hin zeigt jedes Teammitglied mittels Estimation Poker Karten oder Post-It Zettel die Zahl, die für die User Story angedacht wurde. Jene Zahl, die überwiegend erscheint, wird als Komplexität für die User Story angenommen. Weichen die Estimations zu sehr voneinander ab, kann man davon ausgehen, dass die User Story nicht ganz einheitlich verstanden wurde.

Sprint Demo: Für jeden Sprint werden Sprint-Ziele definiert. Die Arbeit, um diese Ziele zu erreichen, werden jeweils nach einem Sprint während einer Demo-Sitzung anderen Teams demonstriert. In diesen Demositzungen haben Teams aus anderen Abteilungen die Möglichkeit, in die Arbeit anderer Teams einzusehen und zu kommentieren und ggf. Synergien zu erzeugen. Sprint Demos sind in der Regel für alle Mitarbeiter des Unternehmens offen. Es empfiehlt sich jedoch, die Sprint Demo Sitzung in eine allgemeine und technische Demo aufzuspalten.

Scrum Wall: Die Scrum-Wall ist das Herzstück eines jeden Teams, welches mit dem Agile-Framework arbeitet. Die Scrum-Wall konsolidiert alle wichtigsten Informationen für den aktiven Sprint. Dank der Scrum Wall behalten alle mitglieder des Teams die Übersicht über die Laufenden, anstehenden und erledigten Aufgaben.

Sample scrum wall

Scrum Master: Der Scrum Master erledigt neben seinen Sprint-Aufgaben administrative Aufgaben um die Informationen vor, während und nach einem Sprint in die richtigen Kanäle fliessen zu lassen. Der Scrum Master koordiniert die Tasks, Scrums und Reporting der verbrauchten Stunden.

Product Owner: Der Product Owner ist mit anderen Worten der Kunde des Agile-Teams. Der Product Owner erstellt und priorisiert die User Stories und gibt dem Team vor, welche Aufgaben zu erledigen sind und warum.

Somit habe ich euch die wichtigsten Begriffe des Agile-Frameworks etwas näher gebracht. Wie oben schon erwähnt steht es jedem Team frei, auch nur wenige Elemente des Agile anzuwenden oder es auch völlig ganz wegzulassen. Jedoch gibt es heutzutage schon viele Software-Entwicklungs Unternehmen, die dieses Zusammenarbeits-Framework verwenden.
Man kann dieses Framework auch auf ganz andere Arbeiten anwenden. Wir haben dieses Framework sogar schon benutzt um ein komplexes Konzept zu schreiben. Stündlich haben wir ein Scrumming gemacht, weitere Aufgaben verteilt und die Arbeiten rapportiert.
Mit dieser Methode haben wir innerhalb eines Tages in einem Dreierteam ortsunabhänig ein sehr kompliziertes und umfangreiches Konzept geschrieben. Dies hat wunderbar geklappt und hat uns viel Zeit eingespart.

Falls ihr mehr über Agile und Scrum erfahren möchtet: Trainings, Ressourcen, Artikel und Zertifikate für Agile und Scrum findet man hier.

Auf jeden Fall: ich persönlich bin ein Fan dieses Frameworks, weil die Regeln einfach zu verstehen und anzupassen sind und man trotz den Regeln selbstständig und flexibel arbeiten kann.

Michael Greth hat über einen meiner Vorträge einen Podcast gemacht. Er hat den ersten Vortrag „The „fuzzy tail“ – wie entwickelt man ein Suchkonzept?“ komplett aufgenommen und gestern, ebenfalls komplett, bereitgestellt. Wer also Lust hat, den Vortrag noch einmal zu hören, kann das jetzt in Ruhe noch einmal tun.

Der Podcast ist via iTunes oder direkt auf SharePointPodcast.de zu beziehen.

So und hier ist es. Leider ein bisschen unscharf, aber man kann nicht alles haben!

Vielen Dank an Alle die in München an der SharePoint Konferenz waren. Ich hatte viele interessante und lustige Gespräche. Ein „merci“ aus der Schweiz. Bist zum nächsten Jahr.

PS: Das Bild in Originalauflösung liegt auf meinem SkyDrive.

Damit erweitert Google seine Collaboration-Palette um ein weiteres Puzzle-Teilchen. Alles sieht danach aus, dass Google irgendwann sein Gesamtwerk fertig hat. Bis jetzt aber kann Google noch nicht mit den wirklich ausgereiften Collaboration-Produkten mithalten; zu zerstückelt kommt das alles noch daher. Wir sind gespannt, wie sich die Goolge-Collaboration-Plattform weiter entwickelt.

1. Klingt gut, aber unsere interne Kommunikation funktioniert seit Jahren sehr gut.

2. Aha! Ein Dokumentenlenkungs- und Archivierungssystem wird bei uns auch gerade geplant. (Nach einer Demo von MySite)

3. Was soll dabei herauskommen, wenn unser Portier Einträge in ein Wiki macht? (Antwort auf ein cleveres MOSS Konzept von Jussi (eConcierge) und einen super Code dazu von Holger)

4. Wir, die Firma XY, sind in der Branche bekannt dafür, nicht jeden IT-Hype blindlings umzusetzen. (Nach einer Präsentation eines Slidedecks namens „the new way of work“ mit VoIP und Collaboration.)

5. In unserer Firma haben wir eine vierteljährlich erscheinende Mitarbeiterzeitung. Diese informiert über die wichtigsten und aktuellsten Vorgänge im Betrieb. Meist schreibt sogar unser Direktor das Editorial.

6. Wir haben ja schon ein schwarzes Brett im Eingangsbereich der Abteilung. (Nach dem Vorschlag, Holgers Blackboard Web Part beim Kunden zu aktivieren)

7. Bei uns sind die Führungskräfte der Abteilungen für die Informationsverteilung und Gesprächsorganisation zuständig.

8. Das Intranet würde so nur zum Medium für Kaffeetratsch und zu einer Tauschbörse für privaten Kram. (Nachdem ich mit meinem Gesprächspartner über eine Art Facebook auf SharePoint gesprochen habe. Zugegeben, was soll ich mit „super poke“ gegenüber meinem Manager?)

9. Unser aktuelle Umsatz- und Gewinnsteigerungen der letzten Jahre sind im Plan. Erzählen Sie uns also nicht wie „die Zukunft der Arbeit“ aussehen wird, das wissen wir selber besser. (Nach einer Präsentation eines Slidedecks namens „the new way of work“)

10. Klingt sehr spannend. Aber das brauchen wir alles nicht, da wir keine Info Worker sind, sondern in der Verwaltung tätig sind.

Vielleicht habe ich meine Botschaft nicht richtig rüber gebracht. Auf jeden Fall muss man sich bei solchen Antworten schon überlegen, wie man seriös aus der Diskussion rauskommt ohne alles noch einmal zu wiederholen.

Selber schon auf haarsträubende Antworten zum Thema „wir brauchen keine Collaboration“ gestossen? Postet sie hier…

PS: Hier eine inoffizielle Antwort die vielfach nur geflüstert wird:

Wir, die Mitarbeiter, sind stets bemüht, uns so wenig wie möglich zu engagieren, so wenig wie möglich aufzufallen und die zugewiesene Arbeit über den ganzen Tag zu strecken. SharePoint ist demnach für uns extrem kontraproduktiv und dringend zu vermeiden.

Tipp 1: Einwegkommunikation vermeiden
Eigentlich wissen wir es alle. Eine Strenge Kontrolle über das “Wer, Was und Wie” auf einem Intranet macht einfach keinen Sinn. Wenn man es den Benutzern einfach macht wird das Intranet auch genutzt. Aber wenn man im Intranet ausschliesslich Informationen lesen kann, hat es die Attraktivität einer Wetterprognose. Die liegt erstens immer falsch und zweitens möchte man dies den Herren Kachelmann und Bucheli auch einfach einmal sagen.
Und wenn wir schon dabei sind: Fragt die Leute nach ihrer Meinung! Stellt Q&A Seiten und Umfragen ins Intranet! Nutzt diese Inputs um das Intranet zu verbessern! Denn das Intranet ist immer ein „ongoing“ Projekt das nie aufhört. Wer etwa anderes behauptet liegt einfach nur falsch. Denn das Intranet spiegelt das Unternehmen und dessen Kultur. Wenn man die Benutzer “auf seiner Seite” hat ist eine erfolgreiches Intranet garantiert.

Tipp 2: Individualisierung
Eine typische Anforderung eines Portal Steering Komitees ist die einheitliche Homepage für alle. Eine einzige Homepage auf der alle Informationen des ganzen Unternehmens gleich sichtbar sind. Gleichzeitig kann man von dieser Seite nach überallhin navigieren. Die Idee ist zwar nicht schlecht, aber einfach gesagt: es funktioniert nicht. Gewisse Inhalte sind relevant für viele, aber nicht für alle. Zwingt dem Benutzer nicht eine unternehmensweite Webseite auf die er jedesmal wegklicken muss! Gebt dem Benutzer lieber eine Seite die er sich selber zusammen stellen kann. So ist er fokussiert auf das was ihn interessiert und nicht auf das was alle interessieren sollte.

Tipp 3: Businessapplikationen integrieren
Was nützt eine perfekte Intranet Plattform, wenn ich jeden Task, den ich während meiner Arbeit erledige, in einer anderen Applikation ausführen muss. Heute ist es möglich, mit einer robusten SOA Schicht gewisse Komponenten auf einem Portal zu integrieren. Stellt also sicher, dass die Intranet-Plattform mit dem Kern der Businessanwendungen integriert werden kann. Eine gut integrierte Businessapplikation erzeugt fast für alle Benutzergruppen einen Mehrwert. Sei es, dass die meisten Tasks gleich auf dem Intranet erledigt werden, oder dass dem Management in einer Dashboard Ansicht Daten zur Verfügung stehen. Nur so lässt sich die Vision einer 360 Grad Ansicht auf das Unternehmen verwirklichen.

Tipp 4: Verständnis für die Rolle des Web 2.0 im Unternehmen fördern
Bedenken, welche Unternehmen in diesem Zusammenhang hegen, gehen immer in die gleiche Richtung: Verlust der Produktivität. Das Web ist voll mit gegenteiligen Artikeln zu diesem Thema. Trotzdem diskutiere ich meist genau diese Themen während meiner Arbeit.
Hier noch einmal in der Kurzform: Arbeit und Geschäftserfolg hat etwas mit Vernetzung von Menschen zu tun. Ausser bei Henry Ford und dem Taylorismus. Aber wer Infoworker im Betrieb hat und an den Taylorismus glaubt hat auch kein Intranet. O.K. das dachte ich zumindest!

Tipp 5: Suche optimieren
Das Schlimmste was einem Benutzer passieren kann ist, dass er auf dem Intranet seine benötigte Information nicht findet. Ich weiss es aus eigener Erfahrung: eine gute Suche zu haben ist eine technische Herausforderung. Gewichtung der Resultate, Best Bets und so weiter. Es ist aber nicht nur eine Herausforderung für die Technik. Nein, auch die Autoren müssen mitarbeiten in dem sie ihre Artikel richtig schreiben, mit Metainformationen versehen und so weiter. Meistens sträubt sich aber dann ausgerechnet der Manager dieser Autoren gegen diesen Mehraufwand, weil er den Produktivitästverlust fürchtet (siehe Fehler bzw. Tipp 4). Somit sind wir in einem Kreis der Argumente angelangt. Und jedesmal, wirklich jedesmal, sagt dann einer der versammelten Manager plötzlich: “Hey bei Google geht es doch auch”. Und sofort beginnt der Portal Admin Gegenbeweise zu erbringen und so weiter. Nur: während dieser Zeit ist die Suche kein bisschen besser geworden.