Freigrenze vs. Freibetrag

Heute bin ich von meinem Steuerberater auf die wichtige Unterscheidung zw. Freigrenze und Freibetrag aufmerksam gemacht worden, was ich bis dato synonym verwendet habe.

Dazu ein Beispiel:

• 40€ sind die jeweilige Grenze
• Der Kauf übersteigt die Grenze um 1€, sprich die Gesamtkosten belaufen sich auf 41€

Freigrenze

Im Fall der Freigrenze muss bei Übersteigung des Grenzbetrags die volle Summe versteuert werden, d.h. die vollen 41€ sind steuerpflichtig.

Freibetrag

Im Fall des Freibetrags muss lediglich der die Grenze übersteigende Betrag versteuert werden, d.h. 1€.

Bei Streuartikeln (bis 10€ netto) und Sachzuwendungen an Geschäftsfreunde (35€ pro Jahr und Person) bzw. Sachzuwendungen an Arbeitnehmer (44€ pro Mitarbeiter und Monat | nicht auf Folgemonat übertragbar) handelt es sich um Freigrenzen. Leider sind im betrieblichen Umfeld die meisten Grenzen Freigrenzen.

Ein Freibetrag wäre z.B. der sogenannte Rabattfreibetrag, bei dem der Arbeitgeber seinen Angestellten Rabatte auf die eigenen Waren oder Dienstleistungen gewährt.

Werbung

Beispiele für Zielvereinbarungen

Allgemeines

Dieser Beitrag soll als kleine Hilfestellung für all diejenigen dienen, die sich mit der Findung von guten Zielen schwertun. Wer wie wir darauf hinarbeitet, dass die Mitarbeiter sich aus der Unternehmensstrategie die individuellen Ziele selbst ableiten und der Vorgesetzte nur noch unterstützende Funktion (z.B. Bereitstellen von Resourcen) ausüben muss, der wird zuerst viel kommunizieren und beraten müssen.

Während die eine Seite erfolgreicher Zielvereinbarungen die Verlagerung der Zieldefinition auf den Mitarbeiter selbst ist, ist die andere das Sichtbarmachen der operativen und strategischen Unternehmensziele. Damit einher geht natürlich das kontinuierliche Gespräch über die gemeinsame Unternehmenskultur. Beispielsweise wird es schwierig über monetäre Ergebnisziele zu sprechen, wenn die Kennzahlen nicht transparent zur Verfügung gestellt und erklärt werden. Nicht jeder Chef ist davon begeistert, wenn die Angestellten die genauen Margen von Aufträgen kennen.

• Der Kern guter Ziele sind die S.M.A.R.T. Kriterien, auf die an dieser Stelle nicht weiter eingegangen werden soll.
• Die Ziele drüfen sich nicht gegenseitig beeinträchtigen. Stattdessen sollen sie sich vielmehr gegenseitig beflügeln.
• Die Erreichung des Ziels soll immer einen direkten oder indirekten Benefit für das Unternehmen haben (Stichwort Return on Invest).

 

Auf den Punkt gebracht: Die Mitarbeiter müssen um die Unternehmsziele wissen und diese mittragen. Ein gemeinsames Verständnis der Modalitäten und eine dazu passende Informationstransparenz sind ebenso elementar wie das Mitwirkenwollen des Einzelnen.

 

Beispiele für individuelle Ziele

• Community Auftritte
  • Bis 31.12.18 hält der Mitarbeiter in den User Groups Berlin, Dresden, Leipzig, Chemnitz, Karlsruhe und Luzern Vorträge
• Fachartikel
  • Bis 31.12.18 publiziert der Mitarbeiter 3 Fachartikel in Fachzeitschriften (z.B. in der dotnetpro)
• Öffentliche Auftritte auf Konferenzen
  • Bis 31.12.18 hält der Mitarbeiter auf mind. 3 unterschiedlichen, kommerziellen Konferenzen Talks oder Trainings (z.B. DWX, Karlsruher Entwicklertage etc.)
• Kommerzielle Workshops
  • Bis 31.12.18 generiert der Mitarbeiter durch Workshops einen Gesamtumsatz von mind. 20.000€
• Fakturierung
  • Bis 31.12.18 fakturiert der Mitarbeiter durch Consulting mind. 800 Stunden.
• Zertifizierung
  • Bis 31.12.18 erlangt der Mitarbeiter die Zertifizierung entweder als Microsoft Certified Trainer oder MCSD App Builder
    • https://www.microsoft.com/en-us/learning/mcsd-app-builder-certification.aspx
    • https://www.microsoft.com/de-de/learning/mct-certification.aspx

Einfachere Reisekostenabrechnungen für alle

Optimierung unserer Prozesse ist bei uns schon fast eine Leidenschaft, daher evaluieren wir regelmäßig neue Tools. Eines davon ist Einfach Reisekosten.

Unsere Anforderungen waren klar umrissen:

• Skalierung auch mit 30 Mitarbeitern möglich
• Reduzierung der benötigten Zeit pro Consultant auf 30 Minuten pro Monat
• Reduzierung der Durchlaufzeit im Rechnungswesen
• Auswertungen zur Kalkulation unserer Preise möglich
• Einheiltung der immer aktuellen gesetzlichen Regelungen
• Nice-to-Have: Integration in Debitoor (*)

*) Zu unserer Buchhaltungssoftware Debitoor kann ich gerne einen Artikel verfassen, wenn Interesse besteht. Schreibt mir einfach einen Kommentar.

Nach mehreren Tests, unter anderem dank des schnellen und freundlichen Supports, welcher uns einen Demo Team Account zur Verfügung gestellt hat, haben wir jetzt das Abo gebucht. Besonders gefällt uns, dass Entfernungen anhand von Google Maps automatisch berechnet werden und längere Projekte, in denen immer die gleichen Fahrten anfallen, mit wenigen Schritten erfasst werden können. Das Synchronisieren in Debitoor und die korrekte Zuordnung gemäß DATEV-Kostenrahmen funktioniert problemlos. Selbst so seltene Vorgänge wie das Erfassen von W-LAN Kosten, SIM-Karten, Vignetten, Fähren u.v.m. lassen sich damit abbilden. Durch die genaue Zeiterfassung werden die jährlich aktualisierte Pauschalen automatisch erfasst. Eine Reduktion durch Eingabe der gestellten Verpflegung z.B. von Frühstück im Hotel rundet das Ganze ab. Die Administration der Mitarbeiter scheint auf den ersten Blick auch keine Wünsche offen zu lassen.

Schwächen sehen wir aktuell noch im Zusammenspiel mit Debitoor. So findet kein Abruf des Kundenstamms statt, um den Kunden bzw. das Projekt in der Abrechnung per Auswahl erfassen zu können. Die PDF mit der Abrechnung würden wir darüber hinaus gerne customizen. Preislich wäre ein Rabatt mit steigender Mitarbeiterzahl wünschenswert.

Gerne ziehe ich Vorschläge vom Leser in Betracht. Postet diese in die Kommentare.

ebuero leider nicht für alle geeignet

Kürzlich haben wir für uns den Dienst von ebuero evaluiert. Danke an dieser Stelle an Hans-Peter Schelian und Thomas Bandt für die Empfehlung.

Das Ziel war es, dass unsere Kunden 24/7 365 Tage im Jahr immer jemanden erreichen können – wohlgemerkt einen Menschen! Das muss nicht zwingend jemand sein, der sofort weiterhelfen kann, aber es sollte damit gewährleistet sein, dass der Anrufer darauf vertrauen konnte, dass sich um sein Anliegen asap gekümmert wird.

Mir hat besonders gefallen, dass unser Kunden immer Telefonistinnen aus der gleichen „Sekretärinnen-Gruppe“ bekommen hätten, sprich 3-4 Mitarbeiter von ebuero wären immer für unsere Anrufer zuständig gewesen. Dass diese bereits alle fließend Englisch sprechen, war ein weiterer  Pluspunkt. Gegen einen Aufpreis wären Muttersprachler möglich. Die Preise waren für mein Empfinden durchaus akzeptabel.

Leider konnten einige unsere must-have Anforderungen nicht erfüllt werden:

• Freigabe von Nummernblöcken in der VIP-Liste: Leider müssen Nummern einzeln eingetragen werden. Bereiche der Form +49-721-1234-XXX, wie sie für größere Kunden notwendig sind, werden nicht unterstützt. Speziell hierfür fehlt mir das Verständnis, wieso das nicht möglich ist. Während des Schreibens fällt mir auf, dass es interessant zu wissen wäre, ob CSV-Dateien hochgeladen werden können. So ließe sich diese Einschränkung vielleicht umgehen.
• Benutzerbezogene Benachrichtigungen sind nicht möglich, d.h. die Notifikation über einen Anruf geht an genau eine anzugebende E-Mail-Adresse. Eine Zuordnung zu der Person, die vom Kunden versucht wurde anzurufen, gibt es nicht. Eine Anpassung der E-Mail, um per Regeln in unserem Exchange die automatische Weiterleitung zu gewährleisten, ist ebenfalls nicht möglich.
• Das direkte, automatisierte Weiterleiten der VIP Anrufer ist nicht möglich, sprich in jedem Fall landet der Kunde erst im virtuellen Sekreteriat.
• Das Kalender-Sharing Feature, um der Sekretärin Zugriff auf die Termine von uns zu geben, um dem Kunden zu erwartende Rückrufzeiten zu nennen, unterliegt Einschränkungen, die ich hier nicht weiter aufzählen will.

 

Wenn ein Leser uns einen alternativen Dienst empfehlen kann, wäre ich dankbar. Gerne dürfen auch die Nutzer von ebuero hier Verbesserungsvorschläge in die Kommentare posten, da ich den Artikel meinem Ansprechpartner in der Hoffnung zusenden werde, dass diese Punkte noch verbessert werden.

Train the Trainer

Kürzlich haben wir für unsere Trainer in der co-IT.eu nach Workshops gesucht, um diesen neue Werkzeuge zur Optimierung ihrer Seminare an die Hand zu geben. Die ein oder andere Stellschraube lässt sich bekanntlich immer noch drehen, um das Wissen noch effizienter zu vermitteln. Dabei stellt das Fachliche nicht die Herausforderung dar, vielmehr ist es eine Kunst komplexes Wissen möglichst einfach zu vermitteln, sodass der Teilnehmer das Neue im Alltag auch reproduzieren kann.

Daher waren wir v.a. an Erkenntnissen aus Lernpsychologie und der Pädagogik interessiert. Wie funktioniert das Gedächtnis, wie erzeuge ich Bilder oder erzähle ich meinen Themenstoff als Story (Storytelling). Darüber hinaus waren uns Themen wie Auftreten, Charisma, Schlagfertigkeit oder aber Kritikfähigkeit wichtig, da diese den fruchtbaren Boden für Wissensvermittlung darstellen.

In einer Workshopprofil Präsentationstechniken haben wir brainstormartig alles notiert, was wir in irgendeiner Form gerne in dem Workshop sehen und hören wollten. Zu dem Zeitpunkt war bereits klar: Wir werden jährlich ein solches Training absolvieren. Demzufolge war nicht das Ziel möglichst viel in kurzer Zeit abzudecken, sondern dedizierte zusammenhängende Themen in einer notwendigen Tiefe. Mit der Wunschliste und der Bitte um eine Konzeptausarbeitung schrieb ich dann mehrere Unternehmen an. Natürlich nicht ohne über Facebook und Twitter nach Empfehlungen zu fragen. Danke Daniel an dieser Stelle für deine Rückmeldung.

Folgende Unternehmen haben wir kontaktiert:

• Tobias Beck
• IKT
• Beyer & Wilmer
• Hargarten & Etzel
• Thomas Skipwith
• Pöhm Seminarfactory
• Rhetorikhelden

Mit jedem der Unternehmen habe ich telefoniert, um die Konstellation und den Rahmen sauber abzustecken. Nachdem aufgrund terminlicher Konflikte zwei Anbieter weggefallen waren, haben wir demokratisch in der Gruppe der Teilnehmer die persönlichen Rankings erfasst. Weil ohnehin alle die Rhetorikhelden auf Platz 1 gelistet hatten, war die Sache schnell geklärt.

Der Beitrag soll dem Leser ein paar Anlaufstellen vermitteln und mit der oben verlinkten Wunschliste einen schnelleren Einstieg ermöglichen.

Session Die 4 tierischen Menschentypen

Eine spannende Session mit dem Namen „Die 4 tierischen Menschentypen“ gab es dieses Jahr beim Developer Open Space. Das Video habe ich euch in meinem YouTube Kanal zur Disposition gestellt.

Leider bin ich ein wenig zu spät eingestiegen, sodass ein Teil der Einführung fehlt. Macht nichts, denn hier hat Tobias Beck das toll erklärt.

Feedback ist wie immer willkommen. Wenn euch das Video gefällt, dann teilt/liked diesen Beitrag. Wer noch den Link zum Online Self Test möchte, kann mir das in die Kommentare schreiben. Den Blog von Gregor gibt es hier.

Session Unternehmenswerte

Auf das Thema Unternehmenswerte konnte ich schon aus vielen Blickwinkeln schauen: Ob als Mitarbeiter, als Geschäftsführers, als Selbstständiger oder Dienstleister. Umso mehr hat es mich gefreut, dass Daniel Marbach dazu eine Session vorgeschlagen hat. Teilnehmer gab es reichlich. Ich hätte mir zwar  gewünscht, dass mehr aktive Teilnehmer ihre Meinung bei der nach dem Fishbowl-Konzept geführten Diskussion geäußert hätten, aber insgesamt war es eine wirklich gelungene Session. Die Aufnahme hat ein wenig mit Schwächen bei Bild und Ton zu kämpfen, aber unser Schüler Tim hat sein Bestes gegeben, um in der Nachbearbeitung die nötige Qualität rauszuholen.

Das Video darf man gerne als Einladung zur Diskussion verstehen. Deshalb halte ich hier die Punkte fest, die mir im Kopf geblieben sind:

Duzen/Siezen: Ein diskussionswürdiger Punkt, bei dem die Meinungen sicherlich auseinandergehen. In jedem Fall springen immer mehr Unternehmen auf den „Du-Zug“ auf. Klar ist aber auch: Die Anrede muss zur Unternehmenskultur passen. Ein Beispiel aus meinem Alltag sei genannt: Wenn unser Tim, Schüler, kürzlich erst 18 geworden, mit mir arbeitet, dann würde durch das Siezen aus meiner Sicht eine Hürde aufgebaut werden, die ihn bei der Arbeit weniger kreativ und in Bezug auf seine Lösungsansätze weniger „probierfreudig“ machen würde. Die Angst Fehler zu machen und sich an die Vorgaben des Chefs halten zu müssen, wird durch das Duzen einfach gemindert.

Kommunikationsnähe: Kommunikation findet bekanntlich zum Großteil nonverbal statt. Deshalb ist es umso wichtiger, eine möglichst hohe „Kommunikationsnähe“ zu erreichen. Sei es durch regelmäßige Treffen vor Ort (bei verteilten Mitarbeitern) oder durch Videokonferenzen. Chats und E-Mails sollten mehr durch die vorher genannten Punkte ersetzt werden. Für mich wird dabei einfach mehr Menschlichkeit vermittelt, die auch größere Meinungsunterschiede überwinden lässt.

Rituale: Halte ich ebenfalls für sehr effektiv. Seien es nun das Kickern oder Schachspielen in der Mittagspause, das Feierabend-Darts, das TGIF-Bierchen oder das Daily (als Videokonferenz!): Alles trägt zur besseren Kultur bei. Daniel hat mir einmal erzählt, dass bei Particular Videogespräche häufig mit einem „Kaffee-Gespräch“ über das allgemeine Befinden beginnen, bevor über Geschäftliches gesprochen wird.

Loben: Das ist nun mein persönliches Steckenpferd, wobei ich mit meiner Meinung vermutlich eine Minderheit vertrete. Ich halte Lob für Gift. Ein paar Argumente könnt ihr dazu im Video hören. Auf Twitter wurde dazu auch noch etwas gesagt. Dieser Link wurde in dem Kontext empfohlen. Weitere Informationen gibt es hier.

Persönlichkeitsanalyse: Das finde ganz spannend. Mehrere Firmen haben schon Persönlichkeitsanalysen für ihre Mitarbeiter durchführen und diese dazu schulen lassen, um Konfliktpotential zu erkennen und jedem Werkzeuge an die Hand zu geben, sich auf den Kollegen/die Kollegin einzustellen. Im Nachhinein hat mir noch ein Teilnehmer erzählt, dass bei ihnen die Projektgruppen nach dem Ergebnis zusammengestellt wurden. Alle, bei denen dies umgesetzt wurde, haben sich dazu positiv geäußert.

Wenn euch der Artikel geholfen hat, dann liked oder teilt ihn und hinterlasst einen Kommentar

Hinweis: Das Beitragsbild hat mir Andreas Richter zur Verfügung gestellt.

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

Business Analysten entwickeln fachliche Lösungen, Entwickler technische! Oder?

Die Grenze zwischen den Rollen im Entwicklungsprozess sind fließend. In meinem vorherigen Beitrag habe ich erläutert, wen ich mit welche Rolle betrauen würde und wie sich dadurch die Produktentwicklung um das 100-fache beschleunigen lässt.

Wer kann sich wie an der Lösung beteiligen?

In diesem Beitrag möchte ich meine Sicht darauf geben, bis zu welcher Stelle der Product Owner gefragt ist und wann die Arbeit des Entwicklers beginnt. Dazu greife ich das Beispiel aus diesem Video auf:

 5*3 = 15

Stellen wir uns den Entwickler als Schüler in einer Matheklasse vor, die Multiplizieren lernen sollen. Der Business Analyst (BA) ist dabei der Lehrer, welcher den Schülern erklärt wie die Multiplikation funktioniert. Lediglich das Ergebnis zu nennen kann bei sehr trivialen Prozessen möglich sein. Da die wenigsten Prozesse in Unternehmen trivial sind, gehen wir davon aus, dass wir einer Erklärung bedürfen. Und genau an dieser Stelle scheiden sich häufig die Geister: In welche Tiefe muss der BA in das Problem einstigen und wie weit ins Detail bei dem Lösungsansatz gehen?

Klar ist: Der Lösungsansatz muss vom BA kommen, denn nur er weiß, wie er den Prozess gerne hätte bzw. wie er korrekt ist. Im obigen Beispiel muss der Lehrer den Schülern sagen, dass sich eine Multiplikation in eine Summe umformen lässt. Das kennen die Schüler bereits. Der Lehrer würde ihnen also sagen:

5*3 = 5+5+5 = 15

Leider ist das falsch. Nicht das Ergebnis, aber der Rechenweg.

5*3 = 5+5+5 = 15

Denn der korrekte Rechenweg lautet:

5*3 = 3+3+3+3+3 = 15

Leider reicht es bei Prozessen nur selten, wenn lediglich das Ergebnis korrekt ist, denn die Zwischenergebnisse können auch weiterverwendet werden. Außerdem ist nicht gesagt, dass für alle möglichen Werte das Ergebnis immer stimmt.

Wir waren uns einig, dass der Rechenweg vom BA kommen muss. Macht es dann Sinn, dass der Entwickler diesen validieren und ggf. zig Testrechnungen durchführen muss, um die Richtigkeit zu gewährleisten? Würden das die Schüler der imaginären Schulklasse machen? Können diese überhaupt alle etwaige Abzweigungen/Konstellationen kennen. Was wäre, wenn wir von irrationalen Zahlen sprechen würden? Die sind den Schülern noch gar nicht bekannt. Aber wie sollten sie dann eine Testrechnung mit selbigen machen? Wenn als nächstes auf dem Lehrplan die Division stünde, welche in eine Multiplikation umgeformt werden kann, wären die Schüler dann in der Lage den Rechenweg dahingehend zu validieren, dass er später auch bei Divisionen funktioniert?

Ich bin der Meinung, dass dem nicht so ist und daher der BA sich entsprechend darum kümmern muss. Dagegen spricht ebenfalls, dass es im Sender-Empfänger-Modell immer zu Problemen kommen kann. Wenn ich beim Schach von einem Spielfeld rede, meine ich dann das gesamte Brett oder eines der 64 Felder? Je früher es dabei zu Missverständnissen kommt, desto weiter bewegt man sich von der Lösung weg. Denn wenn der BA nur kontrolliert, ob das Ergebnis 15 ist, dann könnte im Untergrund auch einfach 5+10 gerechnet worden sein.

Selbst kleine Ungenauigkeiten können in der Praxis grobe Probleme machen. Ob ich einen Rabatt entweder auf jede einzelne Position einer Rechnung anwende und dann summiere oder ob ich den Rabatt auf gesamte Rechnung anwende und dann auf die einzelnen Positionen verteile, ist ein großer Unterschied. In bestimmten Fällen können so Rundungsfehler entstehen, die am Schluss das Ergebnis verändern. Wenn ich zuerst 10% abziehe und dann wieder 10% dazu rechne, dann kommt eben nicht der ursprüngliche Betrag heraus.

Mit diesen Details müssen sich aus meiner Sicht die Business Analysten beschäftigen. In technische Lösungen einzusteigen, verlangt niemand. Genauso wenig erwarte ich, dass alles immer zu 100% durchdacht werden kann. Ich schließe auch nicht aus, dass die Entwickler Vorschläge für bessere Lösungen geben. Aber wenn es um die fachliche Problemanalyse und das Entwickeln eines Lösungsansatzes geht, dann ist das die Kernaufgabe der BAs.

Wie seht ihr das? Sind bei euch die Aufgaben klar getrennt? Funktioniert das bei euch? Oder übernehmen bei euch die Entwickler die Rolle Business Analysten?

Wie mittelständische Unternehmen ihre Produktentwicklung um das 100-fache beschleunigen

Vorweg: Die Zahl 100 ist frei erfunden, aber jetzt, wo du schon mal da bist, kannst du trotzdem weiterlesen und am Ende gerne einen Kommentar hinterlassen.

Rollen bei der Softwareentwicklung

Während Konzerne ganze Teams von Business Analysten mit entsprechendem akademischem Background haben, sind kleine und mittelständische Unternehmen (KMUs) weniger breit aufgestellt. Das trifft genauso auf die Größe des Entwicklerteams zu: Dedizierte Software-Architekten und Development Leads gibt es nur selten. Das rechte Bild zeigt einige der Rollen im Entwicklungsprozess von Software (aus diesem hervorragenden Video von Pluralsight entnommen). Deshalb gilt es zu analysieren, wer im Unternehmen welche Kompetenzen besitzt und wo es zu Engpässen kommt. Die Grenzen der Rollenübergänge sind aufgrund der fehlenden dedizierten Rollenbesetzung fließend und werden deshalb häufig von mehreren Personen übernommen.

Das trifft speziell auf die Rolle des Business Analysten zu. Während Wikipedia eine lange Liste von Aufgaben für diesen definiert, will ich meine Sicht – oder besser meine Vision – darlegen, auf welchen Personenkreis die Aufgaben in KMUs aufgeteilt werden müssen. Denn wenn diese Rolle im Unternehmen sinnvoll implementiert wird, ergibt sich ein gewaltiges Optimierungspotential. Generell muss das aber unternehmensspezifisch nach Kompetenzen und Verfügbarkeiten der Mitarbeiter geregelt werden. Diese gilt es kontinuierlich weiterzuentwickeln.

Zukunft des Anwenders

Fachexperten (in der Grafik Subject Matter Expert genannt) sind die eigentlichen Anwender des jeweiligen Geschäftsprozesses. Will man also wissen, wie das Versenden eines Packstückes abläuft und wo es dabei zu Problemen kommt, dann wäre der Lagerist der richtige Ansprechpartner. Deshalb sollte er es auch sein, der den Prozess im Unternehmenswiki festhält. Ein Wiki deshalb, weil es sich einfach nutzen lässt und einige wenige Regeln genügen, um es erfolgreich mit Inhalten zu füllen. Außerdem ist es die Grundlage, um neben dem Prozess Know How weiteres Inselwissen zu erfassen.

Zukunft des Product Owners

Die Koordination, den Überblick über Domänengrenzen hinweg, die Konsolidierung der Informationen und das Überführen von Anwenderwünschen siedle ich beim Produktverantwortlichen (Product Owner bei Scrum) an. Mit steigender Kompetenz und mit steigendem Wissen der Anwender können selbige immer mehr Verantwortung und Aufgaben übernehmen, z.B. das Formulieren der eigenen Wünsche in das Issue Tracking System (Backlog in Scrum). Der Product Owner wird dann stärker zum Koordinator, der das Big Picture und die Vision vorantreibt, der eher in Innovationen statt Evolutionen denkt und der Anforderungen (Achtung: Wunsch != Anforderung) noch besser herausarbeitet. In dem Zuge sind Akzeptanzkriterien zu nennen. Eines könnte lauten:

Wenn eine Rechnung abgeschlossen wird,

• dann lässt sie sich nicht mehr verändern
• dann wird sie automatisch an die Rechnungsabteilung geschickt
• dann wird die Marge es Auftrags berechnet

Zukunft des Entwicklers

Und zu guter Letzt kommen wir noch auf den Entwickler zu sprechen: Je weniger er in die Ausarbeitung von Anforderungen, fachlichen Lösungsansätzen und Modellierungen stecken muss, desto mehr Zeit kann er in gute Softwarearchitektur stecken. Und eine gute Architektur ist der Schlüssel für gute, adaptive und skalierbare Produkte. Die Grenze, wo die Aufgaben des Product Owners aufhören und die des Entwickler anfangen, ziehe ich an der Stelle, wo es einer entsprechenden Ausbildung bedarf – und sei es nur 1. Semester Informatik im Rahmen des BWL-Studiums. Ob der Datentyp Integer werden soll oder ob eine Enum die bessere Wahl für eine Auswahlliste ist, das entscheidet der Entwickler. Bei Fragen nach gültigen Wertebereichen, z.B. ob als Gewicht für einen Artikel 0 Kg zulässig sind, das kann der Produktverantwortliche mit steigender Kompetenz früher oder später gleich mitgeben. Hier bedarf es aber immer der sorgfältigen Prüfung des Entwicklers, dem sich solche Fragen naturgemäß eher erschließen. Hingegen ist der Product Owner immer für das Entwerfen der fachlichen Lösungsansätze verantwortlich, denn nur er hat den Überblick über den Geschäftsprozess und wie dieser mit anderen Prozessen interagiert. Für ein konkretes Beispiel kannst du diesen Beitrag lesen.

Fazit/Vision

Anwender sollte man in den Produktentwicklungsprozess einbinden. Mit steigender Erfahrung können sie mehr Aufgaben übernehmen und helfen, die Entwicklung zu beschleunigen und das Produkt noch besser zu machen. Transparenz, größere Akzeptanz, besseres Verständnis und die Reduzierung von Inselwissen sind nur einige wichtige Nebeneffekte. Ein Feature, sei es noch so gut, welches aufgrund von Ablehnung nicht genutzt wird, ist wertlos. Ein Prozess, egal wie gut durchdacht er ist, um den aber herumgearbeitet wird, produziert mehr Probleme als dass er löst.

Im Gegenzug kann der Produktverantwortliche mehr Zeit in Innovationen und bessere Anforderungen stecken, die zu besserer Softwarearchitektur und niedrigeren Entwicklungskosten führen. Das Ergebnis ist eine schnellere Entwicklung eines passgenaueren Produkts mit weniger Fehlern und höherer Qualität.

Der Entwickler wiederrum kann sich auf eine solide Infrastruktur konzentrieren, die zum Einen schnelle und einfache Anpassungen ermöglicht, zum Anderen entsteht Zeit für das Automatisieren von regelmäßigen Abläufen. Durch automatisierte Tests (durch gute Akzeptanzkriterien) lässt sich das Gros der Arbeit der Tester übernehmen (siehe Rolle in der Grafik oben). Ein Continuous Deployment System macht händisches Deployment überflüssig. Trainings reduzieren sich auf ein Minimum, weil die Fachabteilung von Anfang an in die Prozessumsetzung eingebunden wurde.

Wie haltet ihr das bei euch? Schreibt mir eure Erfahrungen in die Kommentare. Wie weit die Transformation bei heco fortgeschritten ist, erzähle ich in diesem Beitrag (Link folgt noch).

Wenn es ein bisschen mehr sein darf – Zusatzleistungen für IT-ler

Die Karrierebibel nennt in ihrem Beitrag die Top 10 Benefits der Arbeitgeber. Erwartungsgemäß sind flexible Arbeitszeiten und Home Office ganz oben. Der Firmenwagen rangiert hingegen nur noch auf Platz 6.

Neben diesen – in der Regel bekannten und häufig angebotenen – Zusatzleistungen würde ich gerne wissen, was euch abseits vom Mainstream reizen würde. Dazu ein paar Gedanken meinerseits:

• Eine Putzfrau für die eigene Wohnung
• 2 extra Urlaubstage nach 10-jähriger Firmenzugehörigkeit (z.B. 32 statt 30)
• Zusatzkrankenversicherung (z.B. für Heilpraktiker, Zähne oder Brillen)
• Freistellung und Übernahme der Kosten für eure Fachvorträge, Community Touren oder Vorlesungen (sprich ihr betätigt euch nebenher als Referent und die Firma unterstützt euch voll dabei)
• Regelmäßige Firmenausflüge (z.B. mal an den Bodensee)
• Jahresticket für den Nahverkehr (dann kann es freitags direkt zum TGIF-Bierchen gehen)
• Provision bei Vermittlung von Kunden oder neuen Mitarbeitern (bringt allen etwas)
• Übernahme der Kosten fürs Fitnessstudio
• Home Office Ausstattung (abseits vom Mainstream z.B. höhenverstellbare Schreibtische oder W-LAN Router)
• Kindle / Tablet
• Unterstützung beim Hobby (beim Marathon-Läufer z.B. Laufschuhe, Startgebühr und Shirt)
• Kostenfreie Getränke
• Tischkicker
• Mitnahme von Urlaub ins Folgejahr
• Auszahlung Urlaubstage

Ich bin gespannt, was euch einfällt. In ein paar Tagen will ich mit den Vorschlägen eine Umfrage über Facebook / Twitter starten, um zu schauen, welche davon vielleicht bei uns zum Einsatz kommen sollten.

In meinem vorherigen Beitrag habe ich zur Diskussion über die Anforderungen an ein modernes Büro angeregt.

Was IT-ler von einem modernen Büro erwarten

Welche Anforderungen habt ihr als IT-ler an eure Büros?

Schreibt mir in die Kommentare was immer euch wichtig ist. Besonders interessiert mich wie wichtig die Location für euch ist.

• Wollt ihr z.B. keinesfalls in einem Großraumbüro arbeiten?
• Ist euch eine gute S-Bahn-Anbindung wichtig?
• Sollten feste Parkplätze bereitgestellt werden, damit ihr euch die morgendliche Suche spart?
• Sind dedizierte Rückzugsräume wichtig?
• Muss es Mitten in der City sein, damit ihr direkt nach der Arbeit z.B. ins Fitnessstudio oder in der Mittagspause zum Veganer um die Ecke gehen könnt?
• Was sind akzeptable Fahrzeiten zum Büro? 15 Minuten ja, 30 Minuten nein?
• Wäre euch der Stadtrand lieber, sodass ihr etwas Grün vor dem Fenster habt? Eventuell mit Balkon?
• Oder eher ein nahe gelegener Vorort, wohin es sich bequem mit dem Auto (ohne zig Ampeln) fahren lässt?
• Ist eine Einbauküche Pflicht?
• Wäre eine Dusche hilfreich, damit ihr morgens zum Büro joggen oder mit dem Fahrrad fahren könnt?
• Wie sehr beeinflusst die Location eure Entscheidung bei der Arbeitgeberwahl?

Das meinen vier IT-ler aus Karlsruhe:

• Also ich würde Arbeitgeber im Umkreis von 15 Minuten vom Stadtzentrum gut finden. Die Location fließt zu 1/3 in meine Auswahl ein.

• Ich denke die Örtlichkeit ist schon recht wichtig. Eine weite Fahrstrecke will keiner auf sich nehmen, da muss es schon ein Bomben-Job sein, dass man länger als 30min Fahrzeit in Kauf nimmt. Ich weiß wovon ich rede ich fahre momentan jeden morgen 35 Minuten nach Walldorf. Job und Team passen aber, von daher mache ich es auch. Außerdem müssen sich auch die Spritkosten rechnen. Ist also schon eine Überlegung. Ich würde kein Office zu weit in der Pampa suchen.

• Mit viel Raum zum Atmen, Großraum Büros aber überall auch Rückzugsmöglichkeiten zum Tele/Skype. Ich kann dir nur sagen, dass es im agilen Umfeld mega wichtig ist, wenn es keine Wände zwischen Teamkollegen und dem Teamspace gibt.

• ich mag es auch gerne außerhalb, wenn man gut mit dem Auto hinkommt, auf dem Weg nicht im Stau steht und einen Parkplatz bekommt. Der Stau lässt sich ja durch Gleitzeit umgehen[…]. Für mich wäre z.B. ein Büro in der Innenstadt ohne Parkplatz eher ein NoGo.

Im nächsten Beitrag werde ich nach den Benefits fragen, die euch ein Arbeitgeber bieten muss. Was haltet ihr z.B. von 2 extra Urlaubstagen nach 10 Jahren Firmenzugehörigkeit? Oder einer vom Arbeitgeber gesponserten Putzfrau? Hier könnt ihr eure Meinung posten.

WordPress, TYPO3 CMS, TYPO3 NEOS – Anforderungen an ein gutes Content Management System

Die Anforderungsanalyse ist das A und O in Entscheidungsprozessen über Software-Systeme. In einem Praxisbeispiel zeige ich euch unser Ergebnis bei der Auswahl des neuen Content Management Systems. Dabei erkläre ich, was funktionale und nicht-funktionale Anforderungen sind, mit welchen Prioritäten wir diese unterscheiden und nenne Do’s & Don’ts von evaluierbaren Anforderungen.

Durch Klicken auf das Bild geht es zum YouTube Video

Webseiten Baukästen können teuer werden

Oder doch nicht? Das könnt ihr erst bewerten, wenn ihr ein Mindestmaß an Hirnschmalz reingesteckt habt. Gerade kleine und mittelständische Unternehmen (KMUs), die vielleicht auch nur wenige Produkte im Portfolio haben, gehen zu schnell an die Umsetzung und verbrennen dadurch mehr Geld als notwendig. In dem Video gebe anhand eines Praxisbeispieles ein paar Fragen mit, die ihr euch stellen könnt. Das sind z.B.

• Anbindung bestehender Systeme (ERP zur Bestandsanzeige)
• Mehrsprachigkeit
• Tracking
• Google-Optimierung
• Online Shopping
• Kundengruppen / Personas
• Inhaltstypen (Text, Bild, Tabellen, Videos, interaktive Elemente)
• Redakteure bzw. wer pflegt die Inhalte
• Wie oft ändern sich die Inhalte
• Mobile-Optimierung
• und einige mehr

Das Video soll euch nur ein paar anfängliche Ideen geben. Es gibt noch viele weitere Punkte und am Ende steht eine Anforderungsanalyse wie >hier< (Link folgt später).

Durch Klicken auf das Bild geht es zum Video

Ist guter Programmcode noch wirtschaftlich

Eine Session am vergangenen .NET Open Space behandelte das Thema Wirtschaftlichkeit. Konkret stellte der Session Hoster an die Teilnehmer die Frage:

Ist es für euch wichtiger die Implementierung technisch möglichst elegant zu machen oder steht die Wirtschaftlichkeit an erster Stelle?

Ich sehe darin 3 mögliche Antworten:

• Gerade durch die technische Eleganz steigt die Wirtschaftlichkeit, z.B. weil das Produkt bessere Performance als Konkurrenzprodukte hat.
• Beides steht im Einklang. Würde für die Implementierung nicht die notwendige Sorgfalt aufgewendet werden, müsste das Produkt früher oder später recycelt und gänzlich neu entwickelt werden.
• Die Wirtschaftlichkeit in Form von Manntagen zum Zwecke einer „besseren“ Umsetzung wird vermindert.

Speziell zu letztem Punkt habe ich eine ganz eigene Einstellung, zu welchem ich gerne eure Meinung hören würde. Meines Erachtens gilt es nämlich zuerst ganz andere Stellen im Produktenwicklungsprozess zu optimieren. Hierzu einige Beispiele aus meiner Praxiserfahrung:

• Es werden Anforderungen aufgenommen, welche keinen Nutzen bringen. Diesen kommt man recht einfach auf die Schliche, indem man dem Verantwortlichen 5x die Frage ‚Warum‘ stellt. Ich schätze, dass zw. 5-10% der Anforderungen, die von den Fachabteilungen eingebracht und umgesetzt werden, keinen praktischen Nutzen erfüllen.
• Die Priorisierung von Feature-Wünschen ist nicht gemäß deren Business Values. Wenn nicht die Dinge zuerst implementiert werden, die den höchsten Nutzen bringen und dabei das niedrigste Risiko und den geringsten Aufwand aufweisen, dann leidet die Wirtschaftlichkeit (Ausnahme: Bei einem neuen Produkte sollten die mit dem höchsten Risiko zuerst umgesetzt werden).
• Es werden mehr neue Anforderungen aufgenommen, als umgesetzt werden können. Wenn in einem Jahr 200 Einträge im Issue Tracking System aufschlagen, aber nur 100 umgesetzt werden können, dann wurde definitiv Geld in Form von Arbeitszeit verbraten.
• Es wird nicht die notwendige Sorgfalt in die Ausarbeitung von Anforderungen gesteckt. In einem Pluralsight Video bin ich kürzlich auf die Aussage gestoßen, dass 50-70% der Entwicklungskosten auf schlechte/falsche Anforderungen zurückzuführen sind.
• Bei manchen Anforderungen kann erheblich viel Entwicklungszeit eingespart werden, wenn bestimmte Aspekte, auf die auch der Anwender verzichten kann, weggelassen werden. Hierbei sind die Entwickler gefragt, nachzuhaken, ob sich das Feature eventuell an der ein oder anderen Stelle reduzieren lässt.
• Kommunikation: Der Wert einer guten Kommunikation lässt nicht beziffern.
• Automatisierte Prozesse für sich wiederholende Aufgaben, z.B. Continuous Deployment. Das spart täglich Geld!

Das sind nur ein paar Punkte, bei denen ich als erstes Hand anlegen würde! Wie seht ihr das?

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.

Schlanke Prozesse sind gute Prozesse oder warum wir Kanban einführen

In unserer IT Administration führen wir regelmäßige Retrospektiven durch. Das ermöglichte es uns Kategorien von Problem zu identifizieren, wie sie auf dem Bild zu sehen sind.

• Weniger wichtige Aufgaben wurden zuerst erledigt (Priorisierung)
• Vermeintlich kurze Projekte haben sich stark in die Länge gezogen
• Aufgaben wurden nicht vollständig erledigt
• Zuständigkeiten / Ansprechpartner waren nicht klar
• Aktuelle Projektstände waren nicht transparent
• Aufgaben blieben bei Externen hängen bzw. blockierten uns
• Engpässe / Verzögerungen machten uns das Leben schwer
• Planung war schwierig
• Häufiges “auf einen Stand bringen” und mehrfaches Besprechen gleicher Punkte

Die Systemadministration ist von Natur aus ein stark vom Tagesgeschäft abhängiges Umfeld mit viel Klein-Klein-Arbeit. Der Anwender ruft an, meldet PC Probleme (Spezifisches hört man selten), der Kollege unterbricht seine eigentliche Tätigkeit wie z.B. die Vorbereitung einer größeren Umstellung und kümmert sich um die Nöten des besorgten Anrufers. Kaum zurück und wieder in die Umstellung vertieft, kommt eine E-Mail, dass die Druckertoner leer sind. Erneut gilt es die aktuelle Arbeit zu unterbrechen.

Darüber hinaus laufen natürlich immer Projekte mit anderen Abteilungen oder Externen (Telekommunikationsanbieter, Dienstleister, etc.), die voran getrieben werden müssen. Selbst der Entwickler-Kollege aus der selben Abteilung ruft an und möchte einen neuen Testserver aufgesetzt bekommen – am besten vorgestern versteht sich.

Kurzum: Ein reges Tagesgeschäft parallel zu großen Projekten und das alles im Umfeld von unterschiedlichen Stakeholdern. So wie es auch in Marketingabteilungen oder Zentralen der Fall ist.

Nüchtern betrachtet handelt es sich um eine Warteschlangensystem. Da Menschen nicht gut darin sind viele Dinge parallel zu machen, vermuten wir hierin eine der Ursachen: Zu viele Dinge werden gleichzeitig erledigt. Außerdem stehen wir Dritten skeptisch gegenüber, welche uns rein gefühlsmäßig ausbremsen. Bei den Telekommunikationsanbietern können wir indes von einer Tatsache sprechen…Darüber hinaus meinen wir diverse weitere Hindernisse erkannt zu haben, die den Arbeitsfluss immer wieder stören.

Um weil wir uns gerne verbessern möchten, eine zu große Umstellung auf einmal eher scheuen und der Evidenz der Vermutung den Vortritt geben möchten, haben wir uns entschieden Kanban einzuführen. Auf einen Nenner gebracht liegen dem 3 Prinzipien und 5 Praktiken zu Grunde.

Prinzipien:

• Starte mit dem, was du jetzt machst
• Verfolge inkrementelle, evolutionäre Veränderungen
• Respektiere initiale Prozesse, Rollen, Verantwortlichkeiten und Job-Titel

Praktiken:

• Mache Arbeit sichtbar
• Limitiere den WIP
• Manage den Arbeitsfluss
• Mach Prozess-Regeln explizit
• Führe gemeinschaftliche Verbesserungen durch (basierend auf Modellen)

Alle Regeln werden penibel eingehalten, jedoch ist die erste Regel alle Regeln abzuschaffen, die nicht mehr funktionieren.

Über die ersten Ergebnisse werde ich demnächst berichten. Falls jemand schon gute Erfahrungen primär im Administrationsumfeld gemacht hat, dann würde ich mich über Input freuen. Gerne auch aus der Softwareentwicklung.

Es gibt keine passive Kaizen-Kultur

Es braucht keine Retrospektiven und dedizierte Kaizen Phasen; schließlich hat das vorher auch alles geklappt und die Verbesserungen haben sich genauso eingestellt.

Aussagen wie diese hört jeder Change Agent früher oder später. Ich will gar nicht abstreiten, dass in jedem Unternehmen mehr oder weniger kontinuierlich optimiert wird. Jedoch geht durch das passive Verhalten viel Potential verloren. Das kann jeder ganz einfach kontrollieren. Der geneigte Leser soll dazu für einen kurzen Zeitraum – beispielsweise 2 Monate – jede Idee protokollieren, welche von Kollegen mit “das müssen wir mal machen” oder “das sollten wir demnächst angehen” kommentiert wird. Im Anschluss ist zu prüfen, was tatsächlich umgesetzt wurde. Ich wäre überrascht, wenn bereits 5% fertig sind. Wohlgemerkt fertig umgesetzt, nicht nur angefangen und wieder liegen gelassen. Ganz im Sinne von stop starting, start finishing. Bereits die Definition von Kaizen drückt das aus:

“Kaizen […] bezeichnet ein methodisches Konzept, in deren Zentrum das Streben nach kontinuierlicher und unendlicher Verbesserung steht.” – Wikipedia

Es handelt sich um ein methodisches Konzept. Eine Methode ist ein systematisches Verfahren. Laissez faire im Kontext von Verbesserungen kann aber nicht systematisch sein. Passive Kaizen-Kultur ist also ein Widerspruch.

Ein klarer Indikator für ungenutztes Potential, ist das wiederholte Auftreten des gleichen Problems. Der erste Gedanke, der einem dann kommt, ist: Mist, das wollten wir doch mal machen (siehe Aussage oben). Das können häufig kleine Dinge wie eine fehlende Fahrzeugpoolverwaltung oder eine Verwaltung für die ohnehin nicht gerade reichlichen Besprechungsräume sein. Aber auch komplexere Themen wie die hohe Informationsflut im Zeitalter der Wissensarbeit. Schon mal über eine SharePoint Dokumentenbibliothek oder ein Wikisystem nachgedacht? Und wenn ja, auch realisiert?

Unabhängig von den Implementations-Phasen solcher Ideen/Lösungen, gehören zu einer soliden Kaizen-Kultur auch Retrospektiven. Selbstverständlich werden hier wieder Stimmen laut, die behaupten, dass ich mir doch keine Zeit reservieren muss, in welcher ich reflektiere und nach Verbesserungsmöglichkeiten suche. Das ist leider eine ähnliche Floskel wie:

Wir brauchen keine Mitarbeitergespräche. Wir reden regelmäßig miteinander.

Wer sich aber mit den Themen intensiv beschäftigt und ganz darauf einlässt, stellt einen großen Unterschied fest. Persönlich habe ich sogar den Eindruck, dass durch kurze, oberflächliche Problemanalyse Lösungen entwickelt werden, die das Symptom kaschieren, nicht aber aber die Ursache beheben. Als Change Agent hat sich in dem Fall die sokratische Methode bewährt. Stelle solange W-Fragen (Warum, Wer, Was) bis – wie Goethe sagt – des Pudels Kern gefunden ist.

Der Leser kann sich dazu kurz in Erinnerung rufen wie es bei der Zulassungsstelle bei einer Ummeldung abläuft. An dem einen Schalter beantragt man die Anmeldung. Mit dem Papier geht man an den Schalter neben an. Natürlich muss dort wieder angestanden werden. Nach einer meist längeren Wartezeit wird dort das alte Schild vernichtet und das neue ausgegeben. Damit läuft man wieder an den ersten Schalter und nach noch längerer Wartezeit erhält man dann endlich die Papiere.

Wenn ich jetzt danach frage, wie sich der Prozess optimieren lässt, dann kommt ohne lange Überlegung die Antwort: Na indem am Schalter schneller gearbeitet oder mehr Personal eingestellt wird. Überstunden wären ebenfalls möglich. Das sind zwar alles Optionen, allerdings lange nicht die besten, da diese nur sehr beschränkt skalieren und teuer sind. Vielleicht ist das der Grund, warum bis heute die meisten Kfz Halter sich einen halben Tag Urlaub für das Ummelden nehmen müssen. Eine mathematisch nachweislich bessere Antwort gibt es hier.

Fazit

Keine Frage: Es braucht kleine, kontinuierliche Verbesserungen, damit die Unternehmen diese verdauen können. Evolution statt Revolution (manchmal auch letzteres!). Aber Evolution im Schneckentempo gleicht eher einem Rückschritt, weil die anderen schneller voran kommen. Wer jeden Tag 30 Minuten ins Fitnessstudio geht und sonntags ruht, hat am Ende der Woche auch 3 Stunden trainiert. Und genauso wie Trainings als feste Termine eingeplant werden müssen, bedarf es auch fester Zeiten für Retrospektiven und die Umsetzung der daraus resultierenden Ergebnisse.

Und wenn der Leser immer noch motiviert ist, dann kann er gerne einen Kommentar hinterlassen, ob in seinem Unternehmen bereits Kaizen an der Tagesordnung ist oder nicht und warum respektive warum nicht.

Aus der Praxis – Wie sich unser Unternehmen durch Social Media verändert hat

Social Media ist nur ein Trend

Ich bin vor einigen Monaten aus unserer Social Media Gruppe (meine früheren Berichte zu unserer Arbeit) ausgetreten. Nicht weil ich darin keinen Sinn mehr gesehen oder weil ich nichts mehr hätte beisteuern können. Vielmehr liegen meine Stärken mehr darin Ideen zu entwickeln und einzuführen, als diese bis zum Schluss zu begleiten. Schluss bedeutet hierbei bis die letzten Kollegen „überzeugt“ wurden. Die Autorinnen Rising Linda und Mary Lynn sprechen in ihrem tollen Buch Fearless Change von sogenannten “Innovators” und “Early Adopters”  (einen Einführungs-Podcast dazu gibt es hier). Mit Laggers werden übrigens Persönlichkeitstypen bezeichnet, die nicht zu überzeugen sind. Dazwischen reihen sich die Early Majority und Late Majority ein.

Nachdem vor kurzem die Gruppe überein kam sich aufzulösen, sprach mich eine Kollegin an. Sie ist der Meinung, dass viele Ideen respektive Ansätze dabei sind, bei denen es sich lohnt diese weiterzuführen. Zum Beispiel unsere Textwerkstätten. Sie wollte wissen, wie ich über die Entscheidung denke und ob ich einen Vorschlag hätte, um die Gruppe neu auszurichten. Vor allem da sich die bisherigen Ergebnisse sehen lassen konnten und sie die Art der interdisziplinären Kollaboration im Vergleich zur (homogenen) Abteilungsarbeit spannend fand.

Nun wird der ein oder andere Leser vermutlich denken: Das war doch klar. Social Media und Unternehmen passen nicht zusammen. Das ist ein vorübergehender Trend, den jeder früher oder später abhaken muss!

Halte an deinen Zielen fest, bleibe dabei aber flexibel

Mein Sicht darauf war dann doch eine andere, was ich meiner Kollegin wie folgt erklärt habe: Das Ende der Social Media Gruppe ist lediglich dem Namen und der Beschränkung auf eine festgelegte Personengruppe geschuldet. Die Idee dahinter hat längst bei uns Wurzeln geschlagen. Denn inzwischen machen wir unternehmensweite Open Spaces, bei denen die “Lehrer” und “Schüler” Rollen kontinuierlich wechseln und die Agenda von allen Mitarbeitern mitbestimmt wird. Am Vormittag erzählt noch der Kollege aus Berlin umfassend über ein neues Produkt und die Kollegin aus Nürnberg hört zu, am Nachmittag werden die Rollen getauscht und die Kollegin referiert über Werkstoffe und deren Einsatzszenarien.

Die Meetings unserer Marketing- & Einkaufs-Abteilung sind inzwischen für alle geöffnet. Durch gezielte Einladungen abteilungsfremder Kollegen soll das gefördert werden. Themen- und Projektvorschläge werden in den Wochen zuvor von allen Mitarbeitern im Wiki zusammengetragen. Jedem „Stakeholder“ ist freigestellt Input zu liefern.

Ein weiteres Beispiel ist unser Arbeitsplatztausch, bei dem jeder Mitarbeiter mindestens 1x jährlich in eine andere Abteilung wechselt, um über den eigenen Tellerrand hinaus zu schauen. Und natürlich schreibt der Kollege seinen Erfahrungsbericht in unseren Corporate Blog. Stephan ist übrigens kein Mitglied der Social Media Gruppe! Damit ist er einer von vielen, die bereits gebloggt haben.

Mir fallen auf Anhieb noch viele weitere Ausprägungen ein, doch unser Erfolg zeigt sich meiner Meinung nach am besten darin, dass ich kürzlich beim Vorbeigehen nicht umhin kam zu hören, wie der Einkaufsleiter in Nöttingen am Telefon einer Kollegin aus Frankfurt wie selbstverständlich mitteilte: “Das kannst du alles im Wiki nachlesen und dann ggf. ergänzen”. Dass der Einkaufsleiter noch ein paar Wochen zuvor seine Mitarbeiterin – selbige ist Teil der Social Media Gruppe und daher bestens geschult im Umgang mit dem Wiki – gefragt hat wie der Inhalt einzupflegen ist, brachte mich dann doch zum Schmunzeln. Mit einem Video zur Integration der Wiki-Inhalte in unser Warenwirtschaftssystem habe ich die Vernetzung bei uns bereits illustriert.

Neben einigen weiteren Beispielen wies ich meine Kollegin noch darauf hin, dass sie selbst erst kürzlich gegenüber dem Vorgesetzten den Wunsch geäußert hat in ihrer Abteilung regelmäßige Retrospektiven zur Verbesserung der Prozesse umzusetzen. Ebenfalls ein Ansatz, den wir bei der Social Media Gruppe einsetzten.

Quelle: http://pixabay.com/de/baum-struktur-netzwerke-internet-200795/

Fazit:

Nur diejenigen, die Social Media nicht auf Werkzeuge wie Facebook und Twitter reduzieren, sondern die Ansätze und Gedanken dahinter verstehen, können das der Sache inhärente Potential nutzen. Die Schulungs-Agenda sollte eben nicht mehr nur vom Abteilungsleiter definiert oder Geschäftsprozesse durch die Geschäftsleitung festgelegt werden. Stattdessen muss sich eine Kultur etablieren, bei der die Fähigkeiten aller genutzt werden und das Wissen der Masse kontinuierlich geteilt wird. Dadurch entsteht eine Lernkultur, bei der Informationen nach Belieben beigesteuert und herausgezogen werden können. Social Media ist insofern auch keine neue Idee, jedoch sind inzwischen viele digitale – teils populäre, teils weniger bekannte – Werkzeuge auf dem Markt. Mit dem inzwischen signifikanten und noch weiter steigenden Anteil der sogenannten Wissensarbeit ist nicht mehr die Frage, ob man auf den Zug aufspringen sollte. Die Herausforderung liegt darin die passenden Werkzeuge zu evaluieren und eine entsprechende Unternehmenskultur zu etablieren. Denn wer nicht mit der Zeit geht, geht mit der Zeit.

Wie stehts bei euch um Change Management, Social Media und Innovationen? Welche Werkzeuge nutzt ihr? Seid ihr schon auf einem guten Weg oder springt ihr gar nicht auf den Zug auf?

Programmieren – aber bitte nur von 8-17 Uhr

Zu meinem letzten Blogbeitrag Was ist denn bitte ein C# Experte gab es auf Twitter noch eine Diskussion darüber, ob der Job eines Entwicklers ein 8-17 Uhr Beruf ist. Dieser Beitrag soll eher dem Gespräch dienen, weil Twitter dazu nicht geeignet ist. Ich kann mir vorstellen, dass es hierzu bei 5 Personen 6 Meinungen geben wird. Konsequenterweise wird es deshalb in Betrieben auch häufig zu Problemen kommen, wenn völlig unterschiedliche Meinungen und Ansätze herrschen. Ich sage dazu:

Entwickeln ist keine 8-17 Uhr Tätigkeit.

Was ich aber damit meine: Es sollte keine feste Grenzen geben, da ich als Entwickler nicht auf Knopfdruck kreativ sein kann. Ein Maler kann genauso wenig immer von Montags bis Freitags von 8-17 Uhr Bilder kreieren. Ich treffe damit keinerlei Aussage darüber, ob mehr als 8 Stunden gearbeitet werden sollen. Oder weniger. Vielmehr glaube ich:

Nur Ergebnisse sind entscheidend, nicht die aufgebrachte Zeit

In dem Sinne: Work smart, not hard. Ich bin auf eure Meinungen gespannt!

Tipps zum Customer Relationship Management in kleinen und mittleren Unternehmen

Mit folgendem Webcast möchte ich kleine und mittlere Unternehmen (KMU) einen groben Überblick geben, was es bei der Auswahl von Customer Relationship Management (CRM) Systemen zu beachten gilt. In 20 Minuten mache ich eine kurze Analyse und erkläre den unterschied von funktionalen und nicht-funktionalen Anforderungen. Dabei ist es wichtig zu wissen, dass die nicht-funktionalen zwar nicht sichtbar sind, aber durchaus teuer werden können. Am Schluss nenne ich dann einige Produkte, die sich primär in interne und externe Lösungen (Stichwort Cloud) kategorisieren lassen. Bei der Auswahl wird dann der Rückschluss auf die Anforderungsanalyse gezogen.

 

Hier geht es zum Video. Wer sich fragt, welches Programm ich zur Aufbereitung verwende. Es handelt sich um den MindManager der Firma MindJet.

Hier sind noch weiterführende Informationen:

• Ein sehr guter und verständlicher Artikel für den ersten Überblick
• Informationsportal mit mehreren Ressourcen
• Kurzer Beitrag über ‘Gibt es überhaupt Sicherheit in der Cloud’
• Ein Begriff, der im CRM Kontext bekannt sein sollte: Closed-Loop-Marketing

Was ist denn bitte ein C# Experte?

Die Bezeichnungen Senior Developer, Solution Architect und wie sie alle heißen sollen andeuten, dass es sich um jemanden mit Erfahrung handelt. In dem ein oder anderen Bewerbungsschreiben lese ich dann auch gerne “Experte”. Für mich sind das aber – und ich denke der Leser stimmt mir zu – alles relative Aussagen. Vor allem in Anbetracht der Produkt- und Themenvielfalt in der Programmierung.

Sicherlich kennt (wohlgemerkt: kennt, nicht kann) kein .NET Experte alle Programmiersprachen. Dann brechen wir das weiter runter. Sicherlich kennt kein C# Experte alle .NET Klassen. Ok, dann brechen wir es nochmal weiter runter. Sicherlich kennt kein C# BCL Experte die ganzen Facetten der Klasse String (Anmerkung: Wenn ein Leser dies anzweifelt, dann möge er sich diesen Artikel zu Gemüte führen).

Von daher tue ich mich logischerweise schwer, wenn ich von solchen Jobtiteln lese. Nichtsdestotrotz habe ich eine unsere Stellenausschreibungen genauso tituliert. Damit wollte ich ausdrücken, dass wir nach Kandidaten suchen, die sich schon längere Zeit mit der Materie beschäftigen. Ein wenig präziser schreibe ich: “Mindestens 5-jährige Berufserfahrung”. Erfahrung bedeutet nicht gleich tiefgreifende Kompetenz oder überragendes Know How. Ich hoffe der geneigte Leser stimmt mir zu. Aber für ein ganz grobes Profil und die Vermeidung völlig ungeeigneter Bewerbungen (wenn denn überhaupt so viele da wären…) muss das reichen.

Jetzt stellt sich mir die Frage wie sich ein sagen wir mal ausbaufähiges Fundament feststellen lässt. Krisztina nennt in ihrem Blogbeitrag ‘Are you nerd enough to code with us’ z.B. Clean Code, SOLID, TDD, etc.. Klar ist, dass mit den eigenen Ansprüchen vorsichtig umgegangen werden sollte. 100%ige Profiltreffer oder Kandidaten, die uns stark ähneln, gibt es nicht. Ganz abgesehen davon gingen bei einer homogenen Abteilung die Benefits des Melting Pots verloren. Den Mehrgewinn durch Vielfalt. Was suche ich also? Ich versuche es beispielhaft an der deutschen Sprache festzumachen: Wer unserer Sprache mächtig ist (Grammatik, Rechtschreibung, Umfang), der wäre für mich ein geeigneter Kandidat, wenn es darum ginge unseren schönen badischen Dialekt zu erlernen.

Und dabei setzt nun meine eigentliche Frage an: Woran mache ich es fest, dass jemand besagtes solides Fundament beherrscht. Im übertragenen Sinne die deutsche Sprache. Letzteres ist übrigens genauso schwierig zu prüfen, wie ersteres. Hier ein paar Beispiele, die ich zur Diskussion stelle:

• Ist das Schlüsselwort ‘yield’ bekannt?
• Worauf soll ich achten, wenn ich Programmcode gemäß dem Don’t Repeat Yourself-Prinzip analysiere
• Wozu dient das MVVM Entwurfsmuster im Kontext von WPF

Klar ist, dass die Fragen zum Themenschwerpunkt des Bewerbers passen sollten. Jemand, der bisher nur Backend-Code geschrieben hat, kennt sich verständlicherweise nicht mit WPF und MVVM aus. Nach 5 Jahren Entwicklung sollte aber jeder Entwickler (sogar PHP Developer ) das DRY-Prinzip kennen.

Was meint ihr? Wie lotet ihr das aus? Habt ihr auch die Situation, bei der ihr denkt: Also die Bewerbung hat überhaupt nicht gepasst? Eione kleine Bitte noch: Fachkräftemangel ist ein Thema für sich. Darum geht es mir in diesem Artikel nicht. Wer sich dafür interessiert, findet dieses Video vielleicht interessant.

Regelwerk und Beispiele für die eigene Retrospektive

Bei uns führt jeder IT-ler täglich seine eigene Retrospektive durch. Für neue Mitarbeiter will ich in diesem Blogbeitrag festhalten, was wir darunter verstehen. Statt die Information in unserem internen Wiki zu persistieren, wollte ich sie öffentlich machen, damit gegebenenfalls Andere davon profitieren können. Eine letzte Anmerkung für Außenstehende: Natürlich führen wir zusätzlich noch Team bzw. Sprint Retrospektiven durch, die sich zum Teil erheblich unterscheiden.

 

Regelwerk

• Die Retrospektive ist ein Werkzeug aus unserem Werkzeugkasten zur kontinuierlichen Verbesserung
• Eine Retrospektive ist eine Reflexion, bei der der Tag nochmal in Gedanken durchgegangen wird. Eine feste Dauer gibt es nicht, da jeder Tag anders ist. Aber um eine Orientierungshilfe zu nennen: 10-30 Minuten.
• Idealerweise wird die Retrospektive immer am Ende eines Tages gemacht, weil die Erinnerungen noch frisch sind. Eine feste Vorgabe gibt es jedoch nicht. Es ist genauso möglich täglich mehrmals Notizen festzuhalten oder frisch ausgeruht am Morgen des Folgetages zu reflektieren.

Was ist festzuhalten?

• Sowohl das Gute, als auch den Verbesserungsbedarf. Jedoch nicht nur das Problem an sich, sondern möglichst gleich eine entsprechende Lösung.
• Wenn ich selbst etwas Neues probiert habe und es gut funktioniert hat, dann könnte eine Schlussfolgerung lauten, die Vorgehensweise meinen Kollegen zu empfehlen. Eine weitere könnte lauten, dass es sich lohnt noch mehr Zeit in die Optimierung bzw. das Testen zu stecken, um noch mehr herauskitzeln zu können
• Bei negativen Punkten ist zu unterscheiden, ob es sich um regelmäßig benutze Ansätze respektive auftretende Verhaltensweise handelt oder ob es ein einmaliges Problem war
• Wenn es regelmäßig auftritt, sollte es in jedem Fall festgehalten und über eine Lösung nachgedacht werden. Im Zweifel kann es in die Team Retrospektive eingebracht werden, um Hilfestellung zu bekommen. Oder es könnte sich um das Verhalten des Kollegen handeln, welches negative Konsequenzen für die eigene Arbeit mitbringt. Dann könnte eine Schlussfolgerung sein dies zunächst unter 4 Augen zu klären.
• Bei einmalig aufgetretenen Problemen sollte jeder selbst entscheiden, ob es sich ein Eintrag lohnt. Bei einem menschlichen Fehler, der einmalig und unter einer einmaligen Konstellation auftrat, ist das vermutlich wenig zielführend. Allerdings hängt es auch ein wenig von den Konsequenzen ab. Vergesse ich beispielsweise beim Gehen das Abschließen und Sichern des Firmengebäudes, so kann ich – oder eben nicht – selbiges notieren und z.B. darüber nachdenken eine kleine Checkliste am Monitor zu befestigen. Auf der könnte übrigens dann auch stehen, dass die abendliche Retrospektive durchzuführen ist.

Beispiele

• Vergesse ich als Schüler, der ich ca. 1x in der Woche bei einem Betrieb jobbe, mehrfach meine meine Retrospektive durchzuführen oder mir meine Arbeitszeit per Unterschrift bestätigen zu lassen, dann kann ich mir die oben erwähnte Checkliste an meinem Arbeitsplatz (am besten auf Augenhöhe) befestigen.
• Verstoße ich als Entwickler gegen das Don’t Repeat Yourself-Prinzip, dann notiere ich das. Stelle ich nach einem Monat fest, dass das häufig vorkommt, überlege ich mir, woran es liegt. Arbeite ich z.B. viel mit Copy & Paste, so könnte ich z.B. für 1-2 Wochen in meiner IDE die Tastenkombination STRG+C umstellen.
• Vergesse ich als Administrator regelmäßig E-Mails an Externe, weil der Empfänger sich nicht von alleine meldet, so kann ich mir in Outlook auf die gesendete E-Mail einen Reminder setzen.
• Verbringe ich als Vorgesetzter den Großteil meiner Zeit in Meetings, so sollte ich selbige vielleicht analysieren. Unproduktive Meetings lassen sich mit einfachen Mitteln deutlich verbessern (vgl. meinen Artikel Wir arbeiten timeboxed). Eine weitere Möglichkeit ist es alle Meetings auf einen Tag zu legen oder an bestimmten Tagen / zu bestimmten Uhrzeiten gar keine Meetings anzusetzen.

Aus unserer täglichen Retrospektive berichte ich hier. Natürlich ist die Retrospektive ein sehr weites Feld und das oben genannte Regelwerk nur ein Tropfen auf den heißen Stein. Aber für den Einstieg reicht uns das. Der Rest kommt über Gespräche darüber und beim täglichen Reflektieren.

Wie hält es der Leser? Sind Retrospektiven bei euch in der Firma fest im Prozess etabliert? Nur bei Scrum oder auch in Eigenregie? Wollen die Kollegen sich überhaupt weiterentwickeln?

Aus der täglichen Retrospektive #3

Unsere Retrospektiven gehen weiter und die Teammitglieder entwickeln meiner Einschätzung nach ein immer besseres Gespür für Impediments. Das ist für mich als Scrum Master besonders erfreulich. Ich habe mir wieder einmal etwas herausgegriffen, von dem ich denke, dass es dem Leser helfen kann.

Es hat sich herausgestellt, dass ein wichtiger Prozess bisher nicht explizit gemacht wurde: Der Go Live.

Das führte unter anderem dazu, dass das Update erst mit mehreren Tagen Verzögerung und teilweise sogar mit Änderungen aus dem neuen Sprint durchgeführt wurde. Darüber hinaus war nicht gewährleistet, dass mit der Codebasis auch die Datenbasis aktualisiert wurde. Deshalb haben wir uns zusammengesetzt, den Prozess besprochen und diesen im Wiki festgehalten.

Darin wird klar zw. Daten- und Code- Go Live unterschieden. Damit einhergehen auch unterschiedliche Termine und Verantwortliche. Interessanterweise wurde in der Diskussion deutlich, dass der Prozess noch detailliert visualisiert und kommuniziert werden muss. In Kanban ist das fest als Regel aufgelistet:

                  Visualize Your Workflow

Einen Einblick in unser Wiki und den Prozess werde ich demnächst in Form eines Screencasts auf YouTube und auf meinen Blog stellen. Als Abonnent kriegt ihr das automatisch mit.

Mit welchem Tool verfasst bzw. persistiert ihr eure Regeln? Wer macht das? Wird das kontinuierlich erweitert oder war das nicht mehr notwendig? Ist es euch auch schon öfters passiert, dass ihr feststellen musstet, dass Regeln nicht explizit gemacht und dadurch Probleme verursacht wurden? Gerne könnt ihr mir einen Kommentar schreiben.

Aus der täglichen Retrospektive #2

Aufgrund von unterschiedlichen Browserversionen und Extensions oder wegen gecachten Inhalten kam es bei der Abnahme von User Stories bei uns häufig zu Problemen. Beispielsweise wurden alte Styles oder falsche Bilder geladen. Eine weitere Störquelle waren Fehler in Fremdsprachen oder in besonderen Daten-Konstellationen (sehr lange Breadcrumb, tiefe Hierarchien).

Daraus zogen wir zwei Konsequenzen:

• Alle Tester und der PO bekamen die PortableApps.com Plattform, in welcher Firefox und Chrome mit einheitlichen Extensions und Konfigurationen installiert sind. Zwei Konfigurationen bewirken unter anderem, dass nichts gecacht wird und nach dem Schließen des Browsers alle Daten entfernt werden. Außerdem ist das NoTracking-Kennzeichen aktiviert. Per copy & paste kann ein weiterer Tester schnell “die Testumgebung” erhalten.
• Darüber hinaus legten wir für besagte Konstellationen Lesezeichen in den Leisten an und dokumentierten den Soll-Stand. Im Unternehmenswiki ist der formale Abnahmeablauf festgehalten.

Aus der täglichen Retrospektive #1

Die optimale Lösung ist, wenn das komplette Scrum Team in einem Raum sitzen kann. Leider sitzen unser Kollege Freddi aus dem Marketing und unser Webentwickler Martin, beide Teil des Teams, in unterschiedlichen Gebäuden. Das steht natürlich im Impediment Backlog, lässt sich aktuell aber nicht lösen. Kürzlich kam es deshalb zu E-Mail/Telefon Ping Pong und einem enormen Zeitaufwand einer vermeintlich einfachen User Story. Weil die finale visuelle Lösung noch nicht fest in der User Story definiert werden konnte, mussten verschiedene Oberflächen-Elemente ausprobiert werden. Deshalb erläuterte Freddi Martin einen Ansatz, Martin setzte ihn um, rollte ihn auf die Preview Stage aus und Freddie schaute sich die Lösung an. Danach begann das Spielchen erneut.

Als Konsequenz zogen wir zwei Schlüsse:

• Bei solchen User Stories setzen sich Freddi und Martin zusammen an den PC und bearbeiten die Oberfläche zusammen
• Martin zeigt bei diesem “Pair Programming” Freddi, wie er selbst Kleinigkeiten in der UI mit einer entsprechenden Browser Extension ändern kann. Zum Beispiel Rahmendicke, Hintergrundfarbe, Schriftgröße, etc..

Was wollt ihr über Coding Dojos wissen?

Ich schreibe aktuell an einem Artikel zu dem Thema. Für mich sind Coding Dojos ein effektives Mittel um aktiv die kontinuierliche Verbesserung voranzutreiben. Das ist mir sehr wichtig, denn es geht viel Potential verloren, indem Wissensmanagement nur passiv abläuft. Wer sich z.B. den eigenen Code von vor 3 Jahren anschaut, wird hoffentlich feststellen, dass er heute besser entwickelt. Dieser Prozess vollzog sich quasi nebenbei. Meine Intension ist deshalb aktiv Werkzeuge zu testen und nutzen, um Verbesserungen forcierter anzugehen.

Coding Dojos sind in dem Kontext ein erprobtes Mittel. Weitere habe ich in diesem Artikel bzw. in der unten stehenden Grafik aufgelistet:

 

 

Den geneigten Leser würde ich bitten mir auf Twitter, Facebook oder am besten hier in die Kommentare mitzuteilen, welche Erfahrungen er mit Coding Dojos gemacht hat, wo Probleme liegen, was Erfolge waren und was er gerne in einem Artikel dazu lesen würde. Zur Anregung kann diese kleine MindMap dienen:

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.

Wie besetze ich die Rolle des Product Owners

Prinzipiell ist es nie leicht die Rollen in Scrum adäquat zu besetzen. Der Product Owner (PO) ist dabei keine Ausnahme. An dieser Stelle kann ich deshalb keine generellen Empfehlung aussprechen, einfach weil dies meines Erachtens nicht möglich ist. Stattdessen beschreibe ich den Weg, den wir in der Firma heco mit Erfolg gegangen sind.

Einer unserer Administratoren in der IT sprach mich darauf an, dass er mit seinen Aufgaben zum Teil unterfordert ist und sich zum Teil auch noch mehr einbringen wolle. Beim Reflektieren darüber stachen für mich 5 wesentliche Eigenschaften hervor:

• In seiner aktuellen Aufgabe hatte unser Admin sehr engen und guten Kontakt zu allen Mitarbeitern, die das Produkt (hauseigenes ERP-System) einsetzen
• Sein Verständnis für Geschäftsprozesse war stark ausgeprägt, was auch seine akademische Karriere (Wirtschaftsgymnasium, DHBW Studium) belegte
• Seine IT-Kenntnisse machten die Kommunikation mit dem Entwickler Team einfacher
• Er betreute bereits das Produkt auf technisch administrativer Ebene
• Er war motiviert und wollte das Produkt aktiv mitgestalten

Klar war aber, dass ihm das fachliche Know How und deshalb auch die konkrete Produktvision fehlen würde. Deshalb waren die ersten zwei Schritte ihn direkt zu der Person zu setzen, die das Produkt bis ins kleinste Detail kannte: Unseren Geschäftsführer. Um den Einlernungsprozess zu beschleunigen, war die erste Aufgabe eine vollständige Dokumentation über alle Schnittstellen zu schreiben – sowohl fachlich (das WAS) als auch technisch (das WIE).

In der anschließenden Retrospektive zeigte sich, dass damit der Lernprozess nicht schnell genug voran kam. Deshalb übertrugen wir ihm die Aufgabe alle User Stories fortan selbst zu erfassen. Wir wichen also von den Empfehlungen der Standardliteratur ab, dass die Entwickler die User Stories schreiben sollen. Für mich eine der besten Entscheidungen überhaupt. Immer wenn er nicht in der Lage war die User Story zu erfassen, egal ob zu formulieren oder gemäß dem Business Value zu priorisieren, musste er mit unserem GF darüber sprechen. Zur Gänze hab ich ihn immer zusammen mit den Fachexperten die zugehörigen Informationen im Unternehmens-Wiki festhalten lassen, also z.B. die erarbeitete Domänen-Sprache (vgl. Ubiquitous Language) oder die Bedienungsanleitung. Konsequenterweise war er auch an allen Meetings anwesend. Dass Informieren der Mitarbeiter in Form von Trainings, Schulungen oder E-Mails vervollständigte die Botschaft: Er ist der PO, an den sich die Belegschaft wenden muss.

Die ersten 4 Monate agierte er als sogenannte Proxy Product Owner, der dem eigentlichen PO (in unserem Falle dem Geschäftsführer) versuchte möglichst viel Arbeit abzunehmen, v.a. wenn dieser nicht die nötige Zeit für die Ausübung seiner Rolle hatte. Der Anlernphase folgte dann das Gespräch mit unserem GF, in welchem er seine PO Position übergab. Das bedeutete in erster Linie: Benötigt das Entwickler Team sofort eine Antwort auf eine Frage, dann hat der neue PO die entsprechende Kompetenz, eine etwaig endgültige Entscheidung zu treffen. Diesen Aspekt möchte ich ganz klar hervorheben, weil er nicht unterschätzt werden darf! Zuvor hatten wir bereits eine 100%ige Verfügbarkeit des PO für das komplette Scrum Team erreicht. Diese beiden Eigenschaften zusammen lieferten einen unglaublichen Impuls für die Entwicklung.

Ein Beispiel hierfür: In der Vergangenheit trauten sich die Kollegen aus den Niederlassungen nicht direkt an unseren Geschäftsführer mit Verbesserungsvorschlägen oder Fehlermeldungen heran. Oftmals wählten sie einen Umweg über mich, jedoch verwies ich immer auf den GF als Product Owner, da ich nicht priorisieren konnte bzw. wollte. Das Problem war mir bereits früher aufgefallen, doch fand ich nie eine zufriedenstellende Lösung. Inzwischen ist eine äußert produktive Feedback Kultur entstanden, bei der die Belegschaft die Umsetzung ihrer Wünsche logischerweise sehr positiv aufnimmt.

Selbstverständlich machte unser PO parallel zur Produktschulung regelmäßig Scrum Schulungen (Inhouse), las Bücher (Empfehlung hier), ging zu Scrum Stammtischen oder machte Webinare. Alternativ kann auch ein externer Berater herangezogen werden, mit dem die ersten Schritte gemeinsam gegangen werden.

 

Mich würde interessieren, wer unter den Lesern mit der unternehmenseigenen Besetzung des PO zufrieden ist. Vor allem in Hinblick auf Verfügbarkeit fürs Team!