Heute ging es um eine konkrete SW-Lösung für das Projektmanagement: Juliane Höfle stellte Zcope vor.

Das Produkt der Massive Art GmbH ist webbasiert, hat ein paar innovative Features und soll agile PM Ansätze unterstützen. Bemerkenswert ist das durchgängige Tagging auch von Aufgabenpaketen und Aufgaben, sowie die Integration von Projektblog und Dokumentenmanagement. Mit entsprechenden Berechtigungen kann man „den Kunden ins Projekt holen“ und ihm Zugriff gewähren.

Auf den Klassiker Gantt-Chart wird verzichtet, dafür gibt es einen innovativen Bubble-View (Meilensteine, Anzahl zugeordneter Aufgaben und Grad ihrer Abarbeitung). Daneben gibt es noch viele „übliche“ PM-Funktionalitäten.

Stefan Hagen eröffnet die zweite Woche der Scrum-Konferenz mit einem Interview unter dem Motto klassisches vs. agiles Projektmanagement. Doch eigentlich ist dieser Titel falsch, denn Stefan plädiert dafür situations- und projektspezifisch vorzugehen:

Die Methode sollte sich nach dem jeweiligen Projekt richten und nicht umgekehrt.

Den ganzen Beitrag lesen…

In Beitrag #435 von der Scrum-Konferenz bin ich noch die Inhalte von Jutta Ecksteins Podcast schuldig geblieben:

Die Zeiten eines Outsourcing und Offshoring in der Software-Entwicklung aus reinen Kostengründen sind aus ihrer Sicht vorbei, denn Spezifikationsaufwand, kulturelle Unterschiede und die erforderliche Kommunikation bergen erhebliche Risiken. Wer rein aus Kostengründen outsourct, wird vom Ergebnis in der Regel enttäuscht sein, so ihr Fazit.

Gründe, die auch heute dafür sprechen sind Personal-/Skill-Mangel und marktliche Anforderungen, etwa bei der Erschließung neuer Märkte oder um Kundennähe zu gewährleisten.

Die Entscheidung für verteilte Teams in der Software-Entwicklung ist in der Regel aus einer Notwendigkeit heraus geboren und keine „Liebesentscheidung“.

Den ganzen Beitrag lesen…

Heute 15:00 Uhr auf Schloß Altenhain hat mein Namensvetter seine Vernissage.

Hier gibt es die ganze Geschichte dazu.

Heute ist Tag 4 der Konferenz und auf dem Programm steht Christoph Mathis über agile Engineering Techniken:

Scrum ist ein phantastisches PM-Framework, aber der Unterbau in Form von entsprechenden Engineering Techniken wird gerne vernachlässigt. Zu diesen Techniken zählen Continous Integration, Testgetriebene Entwicklung, permanentes Refactoring und Fair Programming.

Zur Architekturdefinition hat er ähnlich pragmatische Vorstellungen wie Stefan Roock.

Von den Entwicklungstechniken ist v.a. test-driven devlopment (TDD) einschließlich einer Refactoring Phase zur Säuberung des Codes sein Steckenpferd.

Team und Vertrauenskultur sind mit das Wichtigste. „Man muss die Leute lassen.“ Reflektion (Retrospektiven/Lessons Learned) ist wichtig. Agilität ist eine Haltung. Sie braucht Voraussetzungen in der Kultur, damit es funktionieren kann.

Nicht nur Softwareentwicklung, auch andere Dinge, wie Marketing, Innovationsmanagemt oder Portfoliomanagemetn können mit Scrum erfolgreich bewältigt werden.

Last but not least gibt er vier Empfehlungen:

Ask the Team

Inspect & Adapt (aus dem ständigen Testen lernen und die SW anpassen)

Tatsächlich liefern. Nach jedem Sprint fertige SW liefern.

Die Leute als Erwachsene behandeln. Das bewirkt Wunder.

Heute geht es auf der Scrum-Konferenz weiter mit einem Podcast mit Jutta Eckstein über agile SW-Entwicklung mit verteilten Teams. Für eine inhaltliche Besprechung muss ich auf die kommenden Tage vertrösten.

Mittlerweile kommen auch die ersten Diskussionen in Gang: z.B. zum Thema Architekturdokumentation oder zu Rollenkonflikten.

Und weil es zum Thema passt: Vielleicht ist es ja eh schon bald wieder mit Scrum vorbei: Auf AgileScout findet sich aktuel ein Posting: Is Scrum is Dying? Keep Scrum Alive!

Aha, ein Hype löst den nächsten ab: Kanban statt Scrum!

Ehrlich gesagt haben mich die Moden noch nie interessiert, aber das Rollen/Kommunikationsmodell und die Vorgehensweise inkl. ihrer Umsetzung in Artefakte in Scrum finde ich trotzdem spannend.

Jan Poczynek und Olaf Hinz ziehen einen amüsanten Vergleich zwischen Entwicklungen im Projektmanagement und Dosenfleisch:

Streng nach Modell geführte Projekte sind wie in die Dose gepresstes Fleisch: in Form gebracht, in Struktur gepresst und jeder eigenen Form beraubt!

Die Autoren plädieren für ein Projektmanagement jenseits von Konservenessen.

Mahlzeit!

An dieser Stelle ein Hinweis auf mein Beratungsansgebot:

Tag 2 mit einem Beitrag von Stefan Roock über das Spannungsfeld Architektur und Agilität:

• Was ist Architektur? – Sicherstellung von Änderungsfähigkeit (nach Tom DeMarco)
• Empfiehlt die Arbeit mit einer Architekturvision („technischer Kumpel der Produktvision“) >> vor dem Start der Entwicklungsarbeit
• In Scrum braucht das Team Architekturwissen, ggf. Integration von Architekten in die Teams
• Ein Architekt darf nicht „hierarisch“ eingebunden sein. Dies widerspricht dem agilen Manifest >> Rolle als Coach
• Untermauerung von Architekturvision mit Prototypen
• Die Architekturvision soll Änderungen unterstützen, dann müssen wir auch keine Angst vor Änderungen haben
• Die Architekturvision soll möglichst schlank sein, weil jede Vorgabe das Projekt weiter einschränkt
• Architekturaufgaben sind Sache des Teams und nicht des Product Owners
• Architektur kann ganz am Anfang mit der Entwicklung  eines „Tracer Bullet Features“ ohne großen Mehwert für den Product Owner getestet werden. Dieses Vorgehen ist einem anfänglichen Architektur-Sprint vorzuziehen. Solche Architektur-Sprints produzieren häufig nur Luftnummern.
• Architektur-Vermittlung funktioniert nur in Face-to-Face-Kommunikation
• Dokumentation, wo erforderlich, möglichst aus dem System heraus (damit sie auch mit dem System übereinstimmt und der Aufwand sich in Grenzen hält)
• …