Schneller zur besseren Webseite mit einer Business Analyse

Für unseren größten Kunden die heco gmbh haben wir eine Business Analyse durchgeführt, um vor der anstehenden Neuentwicklung die richtigen Entscheidungen treffen zu können. Wie wichtig die Informationen über Markt, Mitbewerber, Anwender und Kunden sind und welche Schlussfolgerungen sich daraus ziehen lassen, zeige ich in diesem Video:

Während dies bei „normalen“ (im Sinne von offline bzw. intern) Software-Projekten schon eher Usus ist, kann man davon bei Web-Projekten  noch lange nicht sprechen. Meiner Erfahrung nach spielen hier Aussehen und „etwas auf die Leinwand bringen“ die erste Geige. Eine schier riesige Zahl an Feature-Wünschen, die man auf anderen Seiten gesehen hat, lässt die Stakeholder träumen.
 

Der Langsamste, der sein Ziel nicht aus den Augen verliert, geht noch immer geschwinder, als jener, der ohne Ziel umherirrt. – Lessing

 

Aus unserer Sicht ist es elementar sich die Zeit zu nehmen, um sich als Dienstleister in die Domäne des Kunden einzuarbeiten. Denn viele hoch priorisierte Wünsche sind eher nice-to-have Anforderungen. Oder schlimmer: Das „Warum“ ist gar nicht geklärt und das Produkt bzw. die Webseite wird am eigentlichen Zweck vorbei entwickelt. Da wird dann auch mal der Wunsch nach einem News-System laut, obwohl im Jahr nur 1-2 Neuigkeiten auf der Webseite eingepflegt werden sollen. Dabei wäre es unter Umständen geradezu eine Revolution in der Branche, würde man im Gegensatz zu den Mitbewerbern Echtzeitbestände und -preise auf der Webseite anbieten.

Um richtig priorisieren und die Technologie auswählen zu können, ist deshalb ein solides Know How der Domäne des Kunden notwendig, denn sonst verbaut man sich schnell Möglichkeiten, die dann teuer und langwierig umgebaut werden müssen. Setze ich beispielsweise auf SignalR, so kann ich jedem Besucher, der ein bestimmtes Produkt geöffnet hat, Änderungen am Bestand aktiv mitteilen. Auf der anderen Seite muss ich mir nicht unnötig Komplexität ins Projekt holen, wenn der Bestand von vor 2 Stunden völlig ausreichend ist. Oder wenn der Besucher gar nicht in der Lage ist bestimmt Funktionen zu bedienen (ja, das gibt es durchaus => kenne deine Anwender).

Viel Spaß mit dem Video, auch wenn es etwas lang wurde. Daran merkt man aber schon wie weitreichend das Thema ist. Schreibt mir in die Kommentare, ob ihr auch schon zu solchen Projekten gestoßen seid, bei denen das fehlende Domänenwissen zu Entwicklungsproblemen führte.

Werbung

Anwender durch zielgerichtete Release Notes in die Produktentwicklung integrieren

In diesem Video zeige ich eine von vielen maßgeschneiderten Funktionen unseres Release Prozesses. Das Ziel dabei war es die Anwender noch mehr in die Produktentwicklung einzubinden.

Die langfristige Vision: Anwender bringen selbst die Anforderungen ein. Wie das genau gemeint ist und wie wir das umgesetzt haben, seht ihr im Video. Unter anderem kommen YouTrack und TeamCity zum Einsatz.

 

Über ein Rake-Skript, welches auf ein bereits existierendes YouTrack-Gem zurückgreift, sprechen wir die Rest-API an. Vielen Dank an Alexander Groß von GROSSWEBER für die Hilfe bei der Umsetzung unserer Vision.

	require 'youtrack'
	require 'ostruct'
	module Build
	class YouTrack
	class View
	attr_reader :issues, :by_department, :by_relevance
	def initialize(issues)
	@issues = issues
	@by_department = department(issues)
	@by_relevance = relevance(issues)
	end
	private
	def department(issues)
	create_view(issues, proc { |issue| issue.departments })
	end
	def relevance(issues)
	create_view(issues, proc { |issue| issue.relevant_to })
	end
	def create_view(issues, group_by)
	view = issues.inject({}) do |memo, issue|
	group_by.call(issue).each do |rel|
	previous_value = memo.fetch(rel, [])
	new_value = previous_value << issue
	memo[rel] = new_value.sort_by(&:issue_id)
	end
	memo
	end
	Hash[view.sort]
	end
	end
	class << self
	NOT_FOUND = proc { { 'value' => nil } }
	def fixed_issues(from, to)
	resource = client.issues
	maybe_patch_unreleased_methods(resource)
	query = query(from, to)
	puts "Getting issue list from YouTrack using query: #{query}"
	issues = resource.list(filter: query, max: 1000)
	issues = force_list(issues)
	transformed = transform(issues)
	View.new(transformed)
	end
	private
	def client
	@client ||= Youtrack::Client.new do |c|
	c.url = 'your-url'
	c.login = 'your-user'
	c.password = 'your-pw'
	c.connect!
	end
	end
	def maybe_patch_unreleased_methods(issues)
	return if issues.respond_to?(:list)
	warn 'Patching #list method'
	# Get a list of issues for a search query.
	#
	# attributes
	# filter string A query to search for issues.
	# with string List of fields that should be included in the result.
	# max integer Maximum number of issues to get. If not provided, only 10 issues will be returned by default.
	# after integer A number of issues to skip before getting a list of issues.
	#
	def issues.list(attributes = {})
	attributes[:max] ||= 10
	get("issue?#{URI.encode_www_form(attributes)}")
	end
	end
	def query(from, to)
	"project: HECO_comWORK Fixed in build: #{from} .. #{to} Department: -KEINE #{excluded_subsystems}"
	end
	def excluded_subsystems
	spec = ENV['RELEASE_NOTES_EXCLUDE_SUBSYSTEMS']
	return unless spec
	spec = spec.split(',')
	return if spec.empty?
	"Subsystem: #{spec.map { |s| "-{#{s}}" }.join(' ')}"
	end
	def force_list(issues)
	issues = issues.to_hash['issueCompacts']['issue'] rescue []
	([] << issues).flatten(1)
	end
	def transform(issues)
	issues.map do |x|
	field = x['field']
	project = field.find { |f| f['name'] == 'projectShortName' }['value']
	number = field.find { |f| f['name'] == 'numberInProject' }['value']
	issue_id = "#{project}-#{number}"
	subsystem = subsystem(field)
	summary = field.find { |f| f['name'] == 'summary' }['value']
	info = field.find(NOT_FOUND) { |f| f['name'] == 'Release Infotext' }['value']
	departments = arrayify(field, 'Department')
	relevant_to = arrayify(field, 'Relevant to')
	OpenStruct.new(issue_id: issue_id,
	subsystem: subsystem,
	summary: summary,
	info: info,
	departments: departments,
	relevant_to: relevant_to)
	end
	end
	def subsystem(field)
	value = field.find { |f| f['name'] == 'Subsystem' }['value']
	return nil if value == 'No Subsystem'
	value
	end
	def arrayify(field, key)
	value = field.find(NOT_FOUND) { |f| f['name'] == key }['value']
	return [] if value.nil?
	([value]).flatten.sort
	end
	end
	end
	end

view raw youtrack.rb hosted with ❤ by GitHub

Wer weitere Einblicke in unseren Prozess bekommen möchte, der kann mir dazu einen Kommentar hinterlassen.

	require 'youtrack'
	require 'ostruct'
	module Build
	class YouTrack
	class View
	attr_reader :issues, :by_department, :by_relevance
	def initialize(issues)
	@issues = issues
	@by_department = department(issues)
	@by_relevance = relevance(issues)
	end
	private
	def department(issues)
	create_view(issues, proc { |issue| issue.departments })
	end
	def relevance(issues)
	create_view(issues, proc { |issue| issue.relevant_to })
	end
	def create_view(issues, group_by)
	view = issues.inject({}) do |memo, issue|
	group_by.call(issue).each do |rel|
	previous_value = memo.fetch(rel, [])
	new_value = previous_value << issue
	memo[rel] = new_value.sort_by(&:issue_id)
	end
	memo
	end
	Hash[view.sort]
	end
	end
	class << self
	NOT_FOUND = proc { { 'value' => nil } }
	def fixed_issues(from, to)
	resource = client.issues
	maybe_patch_unreleased_methods(resource)
	query = query(from, to)
	puts "Getting issue list from YouTrack using query: #{query}"
	issues = resource.list(filter: query, max: 1000)
	issues = force_list(issues)
	transformed = transform(issues)
	View.new(transformed)
	end
	private
	def client
	@client ||= Youtrack::Client.new do |c|
	c.url = 'your-url'
	c.login = 'your-user'
	c.password = 'your-pw'
	c.connect!
	end
	end
	def maybe_patch_unreleased_methods(issues)
	return if issues.respond_to?(:list)
	warn 'Patching #list method'
	# Get a list of issues for a search query.
	#
	# attributes
	# filter string A query to search for issues.
	# with string List of fields that should be included in the result.
	# max integer Maximum number of issues to get. If not provided, only 10 issues will be returned by default.
	# after integer A number of issues to skip before getting a list of issues.
	#
	def issues.list(attributes = {})
	attributes[:max] ||= 10
	get("issue?#{URI.encode_www_form(attributes)}")
	end
	end
	def query(from, to)
	"project: HECO_comWORK Fixed in build: #{from} .. #{to} Department: -KEINE #{excluded_subsystems}"
	end
	def excluded_subsystems
	spec = ENV['RELEASE_NOTES_EXCLUDE_SUBSYSTEMS']
	return unless spec
	spec = spec.split(',')
	return if spec.empty?
	"Subsystem: #{spec.map { |s| "-{#{s}}" }.join(' ')}"
	end
	def force_list(issues)
	issues = issues.to_hash['issueCompacts']['issue'] rescue []
	([] << issues).flatten(1)
	end
	def transform(issues)
	issues.map do |x|
	field = x['field']
	project = field.find { |f| f['name'] == 'projectShortName' }['value']
	number = field.find { |f| f['name'] == 'numberInProject' }['value']
	issue_id = "#{project}–#{number}"
	subsystem = subsystem(field)
	summary = field.find { |f| f['name'] == 'summary' }['value']
	info = field.find(NOT_FOUND) { |f| f['name'] == 'Release Infotext' }['value']
	departments = arrayify(field, 'Department')
	relevant_to = arrayify(field, 'Relevant to')
	OpenStruct.new(issue_id: issue_id,
	subsystem: subsystem,
	summary: summary,
	info: info,
	departments: departments,
	relevant_to: relevant_to)
	end
	end
	def subsystem(field)
	value = field.find { |f| f['name'] == 'Subsystem' }['value']
	return nil if value == 'No Subsystem'
	value
	end
	def arrayify(field, key)
	value = field.find(NOT_FOUND) { |f| f['name'] == key }['value']
	return [] if value.nil?
	([value]).flatten.sort
	end
	end
	end
	end

view raw

youtrack.rb

hosted with ❤ by GitHub

	require 'youtrack'
	require 'ostruct'
	module Build
	class YouTrack
	class View
	attr_reader :issues, :by_department, :by_relevance
	def initialize(issues)
	@issues = issues
	@by_department = department(issues)
	@by_relevance = relevance(issues)
	end
	private
	def department(issues)
	create_view(issues, proc { |issue| issue.departments })
	end
	def relevance(issues)
	create_view(issues, proc { |issue| issue.relevant_to })
	end
	def create_view(issues, group_by)
	view = issues.inject({}) do |memo, issue|
	group_by.call(issue).each do |rel|
	previous_value = memo.fetch(rel, [])
	new_value = previous_value << issue
	memo[rel] = new_value.sort_by(&:issue_id)
	end
	memo
	end
	Hash[view.sort]
	end
	end
	class << self
	NOT_FOUND = proc { { 'value' => nil } }
	def fixed_issues(from, to)
	resource = client.issues
	maybe_patch_unreleased_methods(resource)
	query = query(from, to)
	puts "Getting issue list from YouTrack using query: #{query}"
	issues = resource.list(filter: query, max: 1000)
	issues = force_list(issues)
	transformed = transform(issues)
	View.new(transformed)
	end
	private
	def client
	@client ||= Youtrack::Client.new do |c|
	c.url = 'your-url'
	c.login = 'your-user'
	c.password = 'your-pw'
	c.connect!
	end
	end
	def maybe_patch_unreleased_methods(issues)
	return if issues.respond_to?(:list)
	warn 'Patching #list method'
	# Get a list of issues for a search query.
	#
	# attributes
	# filter string A query to search for issues.
	# with string List of fields that should be included in the result.
	# max integer Maximum number of issues to get. If not provided, only 10 issues will be returned by default.
	# after integer A number of issues to skip before getting a list of issues.
	#
	def issues.list(attributes = {})
	attributes[:max] ||= 10
	get("issue?#{URI.encode_www_form(attributes)}")
	end
	end
	def query(from, to)
	"project: HECO_comWORK Fixed in build: #{from} .. #{to} Department: -KEINE #{excluded_subsystems}"
	end
	def excluded_subsystems
	spec = ENV['RELEASE_NOTES_EXCLUDE_SUBSYSTEMS']
	return unless spec
	spec = spec.split(',')
	return if spec.empty?
	"Subsystem: #{spec.map { |s| "-{#{s}}" }.join(' ')}"
	end
	def force_list(issues)
	issues = issues.to_hash['issueCompacts']['issue'] rescue []
	([] << issues).flatten(1)
	end
	def transform(issues)
	issues.map do |x|
	field = x['field']
	project = field.find { |f| f['name'] == 'projectShortName' }['value']
	number = field.find { |f| f['name'] == 'numberInProject' }['value']
	issue_id = "#{project}–#{number}"
	subsystem = subsystem(field)
	summary = field.find { |f| f['name'] == 'summary' }['value']
	info = field.find(NOT_FOUND) { |f| f['name'] == 'Release Infotext' }['value']
	departments = arrayify(field, 'Department')
	relevant_to = arrayify(field, 'Relevant to')
	OpenStruct.new(issue_id: issue_id,
	subsystem: subsystem,
	summary: summary,
	info: info,
	departments: departments,
	relevant_to: relevant_to)
	end
	end
	def subsystem(field)
	value = field.find { |f| f['name'] == 'Subsystem' }['value']
	return nil if value == 'No Subsystem'
	value
	end
	def arrayify(field, key)
	value = field.find(NOT_FOUND) { |f| f['name'] == key }['value']
	return [] if value.nil?
	([value]).flatten.sort
	end
	end
	end
	end

view raw

youtrack.rb

hosted with ❤ by GitHub

Product Owner optimiert eure Engpässe

Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

• Hier geht es zu Teil 1: Ab in den Tunnel mit den Entwicklern
• Hier geht es zu Teil 3: Vice versa (noch in Arbeit)

Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).

An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.

Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.

 

Vorbereitung ist alles

Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?

 

Evolvierbarkeit

Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.

 

Schnelles Feedback

Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.

 

Leerlauf vermeiden

Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.

 

Fazit

Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.

Product Owner lasst eure Entwickler den Tunnel

Das ist Teil 1 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

• Hier geht es zu Teil 2: Product Owner optimiert eure Engpässe
• Hier geht es zu Teil 3: Vice versa (noch in Arbeit)

 

Ideal zeigt der Firm ‘The Social Network’ welche Umgebung Entwickler benötigen: Den sogenannten “Tunnel”.

 

Gemeint ist damit die Möglichkeit konzentriert ohne Unterbrechung an dem (Software-)Produkt arbeiten zu können. Wenngleich agile Methoden wie Scrum und Kanban sehr stark Interaktion und Kommunikation (vgl. Agiles Manifest) fördern, fällt mir immer wieder auf, dass zwar nicht insgesamt zu viel, dafür aber zu häufig miteinander gesprochen wird. Statt dedizierte Gesprächstermine zu nutzen, ruft der Product Owner teilweise mehrfach am Tag den Entwicklern an, um sich z.B. Feedback zu Ideen oder neuen User Stories zu holen.

Das wirkt dann natürlich sehr flexibel im Sinne von frei von Bürokratie und klingt auf Anhieb sehr “kommunikativ”, jedoch sehe ich auch die Nachteile, die nach meiner Ansicht stark überwiegen: Der Entwickler wird kontinuierlich aus dem Tunnel gerissen. Gerade in kleinen und mittelständischen Unternehmen (KMUs) ist die Begründung die, dass genau die statischen Reglements von Konzernen vermieden werden wollen oder aber dass ohnehin nur wenige Entwickler zur Verfügung stehen, um den PO gedanklich zu unterstützen. Das sind alles nachvollziehbare Gründe, jedoch spricht aus meiner Sicht nichts dagegen zu sagen: Wir reservieren täglich von 16.30-17 Uhr dediziert Zeit für den Product Owner und seine Fragen weg. In Scrum gibt es sogar ein dediziertes Meeting während der Iteration dafür: Das Backlog Grooming. Dieses kann im Übrigen auch mehrfach während eines Sprints angesetzt werden.

Wie viel Zeit kleine Ablenkungen kosten, belegen neben Studien (von denen ich an dieser Stelle keine heraussuchen will) auch die eigenen Erfahrungen. E-Mail Eingang, Messenger Nachricht oder nur schnell im Internet was nachgeschaut und schon ist man aus dem Fokus und dem Gedankengang draußen. Das ist unabhängig vom Entwicklerberuf, das ist einfach menschlich. Je nachdem welche Studie gerade wieder veröffentlicht wird, lese ich Zeitangaben zw. 10 und 30 Minuten, die benötigt werden, um wieder an der gleichen Stelle mit der gleichen Konzentration weiterzuarbeiten.

Der geneigte Product Owner kann das einfach nachvollziehen, indem er sich an seine Schulzeit erinnert. Wenn er als Schüler eine mathematische Aufgabe rechnen muss, deren Lösung durch verschiedene Rechenschritte und Umformungen sich auf über 2 DIN A4 Seiten erstreckt und er Mitten drin von einem Mitschüler 5 Minuten mit einem völlig anderen Thema abgelenkt wird, dann muss er nach dem Gespräch erst nochmal seinen Gedankengang verfolgen, um die Rechnung weiterführen zu können.

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Welche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

• Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
• Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

• Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
• Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
• Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
• Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
• Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
• Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
• Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
• Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

4 Akronyme für Scrum

Diese 4 Akronyme sind hilfreiche Eselbrücken in Scrum.

 

MoSCoW

• M – Must have this requirement to meet the business needs
• S –  Should have this requirement if possible, but project success does not rely on it
• C –  Could have this requirement if it does not affect anything else in the project
• W – Would like to have this requirement later, but it won’t be delivered this time

 

Mit der MoSCoW Methode werden die Stories im Product Backlog in 4 grobe Priorisierungen aufgeteilt. Das ist v.a. bei der Initialisierung des Product Backlog und bei der Release Planung hilfreich.

Sind beispielsweise alle Product Backlog Items aus dem Bereich Must Have implementiert, könnte ggf. das Produkt einen so hohen Business Value haben, dass ein öffentlicher Release möglich ist.

Bedenkt aber, dass es sich nur um eine erste grobe Einteilung handelt und trotzdem jedes Item früher oder später eine eindeutige Priorisierung erhalten muss.

 

 

 

Deep

• D – Detailed Appropriately
• E – Estimated
• E – Emergent
• P – Prioritized

 

Das Deep Akronym ist im Kontext des Product Backlog und welche Merkmale dieses aufweisen sollte hilfreich. Die Begriffe sprechen für sich.

 

 

 

Invest

• I – Independent
• N – Negotiable and Negotiated
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

 

Mit dem Invest Akronym wird festgehalten, wann User Stories “wohlgeformt” sind. Denkt daran, dass eine User Story ein “Versprechen für eine Konversation” darstellen soll.

 

SMART

• S –  Specific
• M – Measurable
• A – Achievable
• R – Relevant
• T – Time-boxed

SMART als Akronym gibt es in vielen Kontexten, unter anderem bei Mitarbeitergesprächen. Dabei macht es immer eine Aussage darüber, wie Ziele formuliert sein sollen. Wenn es bei Scrum also um Ziele geht, z.B. dem Sprint Goal, dann findet man in diesem Akronym Hilfe.

 

Fallbeispiel: Verantwortungsbereiche definieren

 

Ich habe den Artikel ‘Deutsche Chefs informieren Mitarbeiter ungenügend’ als Anlass genommen, um an einem Fallbeispiel für eine IT Abteilung in einem mittelständischen Betrieb (rein fiktiv natürlich) eine mögliche Definition der Verantwortungsbereiche zu erstellen. Natürlich ist das hier sehr reduziert und weniger formell, aber es soll nur als Anregung dienen.

Unternehmensziele:

Innovationsgetriebene Prozessentwicklung und –optimierung zur Steigerung des Marktanteils und der Kostenreduzierung, um die Wirtschaftlichkeit in der aktuellen Marktlage zu gewährleisten.

Admin1:

Der erste und wichtigste Schwerpunkt ist das Business Service Management (BSM). Also die Schnittstelle zw. IT und Fachabteilung bzw. das Ausrichten der IT Dienste an den Geschäftsprozessen. Hier arbeitet er vor allem dem Geschäftsführer (Product Owner) und den Entwicklern zu, indem er Prozesse dokumentiert und modelliert. Deshalb muss er bei allen Gesprächen mit der Fachabteilung anwesend sein. Das ermöglicht eine schnellere und bessere Implementierung der Prozesse als Programm-Features; der Business Value der Anwendung steigt.

Der zweite Bereich betrifft die die strategische Ausrichtung der Administration samt Innovationsmanagement. Ziel ist es das IT Service Management damit weiter zu verbessern.

Beispiele:

Beispiel 1: Pflege eines Wikis zur Dokumentation, sowie Modellierung in Form von erweiterten Ereignisgesteuerten Prozessketten (eEPK). Concept Maps dienen zur Erfassung der Problemdomäne.

Beispiel 2: Wechsel von den klassischen Terminaldiensten zu Remote-App, sodass das Arbeiten in den Verkaufsbüros (v.a. mit mehreren Bildschirmen) annähernd an die Qualität heran kommt, wie sie intern vorzufinden ist.

Admin2:

Primär im Support angesiedelt, handelt er das komplette Tagesgeschäft ab, sodass Admin1 sich auf seine Aufgaben konzentrieren kann. Darüber hinaus dokumentiert er die täglichen Aufgaben (Tickets) und führt Listen zur Qualitätskontrolle (Qualitätsmanagement), sodass Admin1 ggf. Adaptionen in die Wege leiten kann, die den IT Betrieb für die Anwender optimieren.

Beispiele:

Beispiel 1: In einer Liste mit Ausfällen werden ausnahmslos alle Systemausfälle dokumentiert. Neben dem betroffenen System und dem jeweiligen Server (ein Server kann mehrere Systeme zur Verfügung stellen), sind auch Ausfalldauer, -grund und daraus resultierende Konsequenzen festzuhalten.

Beispiel 2: In einer Liste mit den regelmäßigen Aufgaben, die am Ende/Anfang jeden Monats anfallen, wird dokumentiert, was genau zu tun ist und wann die Aufgabe das letzte Mal bearbeitet wurde. Neben Ausfalltests und Backup-Prüfungen, kann dies auch kleinere Aufgaben umfassen, wie beispielsweise die manuelle Aktualisierung der Infoterminals oder das Aushängen der neuen Dokumentationen in den Serverräumen (beispielsweise Notfallpläne).

 

Web-Developer:

Sein Aufgabengebiet ist zweigeteilt; neben der eigentlichen Weiterentwicklung der Webseite übernimmt er zum großen Teil die strategische Planung. Übertragen auf die eingangs erwähnte Administration übernimmt er demzufolge beide Funktionen. Mit den Möglichkeiten und v.a. der Wichtigkeit des Webs, steigt auch die Notwendigkeit den Kunden eine hochwertige Plattform für ihre Einkäufe zur Verfügung zu stellen. De facto kann sich heute niemand mehr leisten auf das Web ab Absatzmarkt zu verzichten.

Beispiele:

Beispiel 1: Er evaluiert die eingesetzte Plattform Typo3, d.h. inwieweit trifft diese Plattform die Bedürfnisse des Business. Bietet sie entsprechende Möglichkeiten zur Qualitätssteigerung anhand von Unit Tests (JavaScript und PHP). Stehen Werkzeuge zur Verfügung für das Application Lifecycle Management. Gibt es schnellere und sicherere Datenbanken als MySQL.

Beispiel 2: Er migriert die Extensions einer alten Typo3 Version auf die Basis der neuen Version.

 

ERP-Developer1:

Seine Tätigkeit ist vorwiegend die Entwicklung, d.h. sonstige Aufgaben werden so weit als möglich von ihm abgeschottet, damit das ERP kontinuierlich mit den Anforderungen der Fachabteilung Schritt halten kann. Allerdings ist wie bei allen gewachsenen Systemen auch bestehender Code zu migrieren, d.h. parallel zur Neuentwicklung muss auch Legacy Code angepackt werden. In dem Kontext gilt es zu eruieren, welche neue Technologie hierfür am besten geeignet ist. Geeignet bedeutet hierbei v.a. skalierbar, erweiterbar und mit möglichst langläufiger Herstellerunterstützung. Außerdem ist eine enge Kooperation mit der Fachabteilung notwendig und ein betriebswirtschaftliches Verständnis, sodass vom Entwickler selbst auch Verbesserungsvorschläge kommen können.

Beispiele:

Beispiel 1: Das alte CRM Modul soll neu aufgelegt werden. Die Fachabteilung denkt primär an eine neu Oberfläche und die Optimierung der vorhandenen Daten, z.B. Bildung von Kundengruppen und Validierung der Personendaten. Darüber hinaus können aber von Entwicklerseite Social CRM Funktionen vorgeschlagen werden. Außerdem ist zu klären, ob und wo das Modul in den restlichen Geschäftsprozessen (z.B. Auftragsverwaltung) zu integrieren ist.

Beispiel 2: Zur Optimierung der Lagerhaltung und somit zum Einsparen der Kosten soll ein Bestellvorschlagswesen programmiert werden, sodass die EK-Abteilung auf der einen Seite Deckungslücken und auf der anderen Seite zu hohe Bestände vermeiden kann. Alternativ kann auch der Aufwand bei gleichbleibendem Umsatz anhand des Pareto-Prinzips optimiert werden.

Die Sache mit den Entscheidern – Lean Management

Im ersten Teil habe ich mich mit Pair Programming beschäftigt. Auf dem .NET Open Space Süd kam natürlich auch das Dauerbrennerthema agiles Projektmanagement auf. Deshalb geht es in diesem Artikel genau darum, d.h. nicht um Scrum als eine Ausprägung davon, sondern um die Konzepte dahinter und wie sich diese den verantwortlichen Stellen verkaufen lassen.

Persönlich denke ich, dass sich die Ideen dahinter auch zum großen Teil umsetzen lassen, ohne dass der Prozess vollständig implementiert werden muss. Das könnte die Basis für eine offene Diskussion sein, denn viele Projektmanager (PMs) winken bereits ab, wenn sie Begriffe wie Agilität und Scrum hören.

Fangen wir doch mit dem Work In Progress (WIP) an: Statt an 10 Projekten gleichzeitig zu arbeiten, die erst nach 10 Monaten einsatzbereit sind, ist es betriebswirtschaftlich gesehen immer sinnvoller, ein Projekt nach dem anderen zu realisieren. Bündelt man die Arbeitskraft, wäre je ein Projekt nach einem Monat fertig (vereinfachte Rechnung…), sodass beispielsweise 3 Module nach 3 Monaten effektiv eingesetzt werden und Kosten eingespart bzw. Gewinne maximiert werden könnten. Diese Argumentation dürfte einfach zu gewinnen sein, wenn denn der PM rudimentäre Kenntnisse im Projektmanagement besitzt.

Bei der Projektplanung wird nicht über die innere Qualität diskutiert, d.h. Debatten wie ‘dann machen Sie es erst einmal Quick and Dirty, damit wir Zeit sparen’ entfallen. Mit der Fachabteilung wird lediglich der Umfang verhandelt, sprich wenn Zeit eingespart werden soll, dann nicht durch schlechteren Code, sondern durch weniger Features. Diese Diskussion könnte schon schwieriger zu gewinnen sein. Wenn der PM über längere Berufserfahrung verfügt, dürfte eine ehrliche Betrachtung der Vergangenheitswerte ihn aber ebenfalls zur Einsicht bringen. In jedem Fall – auch unabhängig von der Praxiserfahrung – können hier Beispiele aus dem privaten Leben fruchten: Wenn das Auto nur provisorisch repariert wird, dann folgt das böse Erwachen meistens früher als später.

Regelmäßige Meetings (alle 1-2 Wochen) ergeben sich allein schon aus der schnellen Entwicklung der geschäftlichen Prozesse. Wer aber auch hier Überzeugungsarbeit leisten muss, der könnte sich von dem PM bzw. der Fachabteilung das Spiel Tic Tac Toe erläutern lassen. Mir scheint es unrealistisch, selbst bei diesem einfachen Szenario, dass immer an alles gedacht wird. Was passiert, wenn ein Spieler gewonnen hat? Soll automatisch ein neues Spiel gestartet werden, soll eine Gewinnmeldung ausgegeben werden, etc.. Hierzu gibt es einen Artikel in der dotnet pro, in welchem besagtes Spiel auseinander genommen und aus diesem Kontext heraus beleuchtet wird. Viele der Fragen tauchen erst im Verlauf der Entwicklung auf, sodass ein großes Meeting, in welchem alles besprochen werden kann, zw. unrealistisch bis unmöglich schwankt.

Planungssicherheit ist ein Schlagwort, welches im Kontext des Wasserfallmodells völlig fehl am Platze ist. Welches Projekt, das auf 2, 5 oder 10 Jahre angelegt war, konnte tatsächlich die Rahmenplanung (Kosten, Zeit) einhalten. Die Zahl dürfte gegen 0 gehen. Vergangenheitsbetrachtungen dürften hier auch schnell Aufschluss geben. Es existieren keine Referenzprojekte? In der Tagesschau hört man wöchentlich von solchen, sei es nun der Bau eines neuen Flughafens oder die Einführung eines Mautsystems. Durch die kurzen Iterationen erreicht man schnell (meistens innerhalb von 8-12 Wochen) einen guten Eindruck dafür, was innerhalb von 2 Wochen erreichbar ist. Was scheint nun plausibler? Eine Planung, die auf Vergangenheitswerten beruht und die vom Kleinen ins Große rechnet oder der umgekehrte Weg, bei welchem 2 Jahre angesetzt werden und dann muss das Projekt abgeschlossen sein? Lieber den Spatz in der Hand oder die Taube auf dem Dach?

Zusammenfassend lässt sich sagen, dass es vielleicht langfristig mehr von Erfolg gekrönt ist, wenn sukzessive einzelne Punkte aus dem agilen Projektmanagement integriert werden, ohne diese vor dem PM als agil zu deklarieren. Wenn dann sowieso bereits zu 50% nach der entsprechenden Ideologie gehandelt wird, wäre ein Scrum Buch vielleicht das passende Geburtstagsgeschenk für den PM. Beim Lesen sollte es ihm/ihr dann wie Schuppen aus den Haaren fallen. Idealerweise hält der PM dann eure Idee noch für seine eigene…

Die Sache mit den Entscheidern – Pair Programming

Vergangenes Wochenende war wieder .NET Open Space Süd in Karlsruhe. Es zeichnete sich das gleiche Bild ab wie bereits in Leipzig 2011: Ein steigender Teil der Entwickler ist unzufrieden. Als Hauptursache meine ich folgende Punkte identifiziert zu haben:

• Innovationen werden durch den CIO/CTO gänzlich abgelehnt
• Neue Wege werden von der GL nur halb mitgegangen, solange sie noch “angenehm” zu gehen sind
• Frische Ansätze werden vorsätzlich sabotiert, z.T. durch das Team

Dementsprechend trifft das dann die sogenannten “schöpferischen Zerstörer” (Buchreferenz fehlt mir aktuell), d.h. kreative, innovative Menschen, die den Status Quo und all seine negativen Mitbringsel aufbrechen wollen.

Betrachtet man die letzten Jahre, so hat sich vieles getan. Zum einen im Prozess- und Projektmanagement, als auch in den dazu passenden Werkzeugen. Zu nennen wäre die Ausrichtung am Lean Management, z.B. in Form von Scrum, oder Continuous Integration (bzw. Continuous Deployment) durch einen Build Server. Clean Code – heutzutage in aller Munde – besagt nicht viel mehr, als dass man sich ständig weiterbilden und Softwareentwicklung als Handwerkskunst verstehen muss.

Stand heute stehen viele Vorgesetzte respektive Entscheider – sei es nun der IT Abteilungsleiter oder Geschäftsführer -  dieser Bewegung entweder skeptisch oder gänzlich ablehnend gegenüber. Warum auch CIOs eine derartige Haltung einnehmen, ist für mich bis dato nicht nachzuvollziehen. Schließlich sind die Stellenanforderungen an diese Position primär Kreativität, innovatives und prozessorientiertes Denken, sowie ausgeprägtes Business Alignment.

Deshalb möchte ich in den nächsten Wochen hin und wieder Punkte aufgreifen, welche typischerweise von Entscheidern mit in der Regel altbackenen Argumenten abgelehnt werden. Heute befasse ich mich mit Pair Programming:

Hier ist natürlich als Gegenargument zu hören, dass es betriebswirtschaftlich keinen Sinn macht, wenn zwei Personen an der gleichen Aufgabe arbeiten. Genauer gesagt würde ja nur einer arbeiten und der andere schaut dabei zu. Aber gerade Pair Programming ist ein Musterbeispiel dafür, wie falsch solche Aussagen von entsprechenden Stellen sein können!

Inselwissen ist sicherlich in jeder Firma ein Problem – teilweise vielleicht so groß, dass die Geschäftsleitung gar keine Vorstellung davon hat! Wenn immer zwei Personen an einem Stück Code schreiben, ist dem von Anfang an Einhalt geboten. Wird beim Pair Programming auch noch regelmäßig durchgewechselt, was sich für Teams ab einer Größe von 4 Personen immer anbietet, so ergeben sich weitere Synergieeffekte, da z.B. das Gesamtverständnis für das System gefördert und Doppelentwicklungen vermieden werden.

Als nächster Punkt wäre anzumerken, dass dadurch quasi eine kostenfreie Schulung stattfindet. Nach meiner Erfahrung bietet selbst der einfachste Code Gelegenheit für neues Detailwissen. Als Beispiel diene das Schlüsselwort checked für die Addition zweier Integer-Werte. Darüber hinaus hat jeder Developer sein Spezialgebiet, in welchem er dem Kollegen Wissen vermitteln kann.

Und noch ein Argument darf aus betriebswirtschaftlicher Sicht nicht fehlen: Der Code wird “besser”, d.h. Arbeitszeit für Refactoring, Neuprogrammierung und Nachbesserung wird eingespart. Fehler die früh aufgedeckt werden, sparen bare Münze! Ein toller Spruch hierzu kam am Open Space ebenfalls: Für das Programmieren wird eine Gehirnhälfte im Menschen beansprucht, d.h. wenn zwei Entwickler am selben Problem arbeiten, hat man ein vollständiges Gehirn, welches sich dem Problem annimmt.