Im Vortrag “The Canary in the Coal Mine” (Der Kanarienvogel im Kohlenbergwerk) behandelt Ken Schwaber eine Reihe interessanter Aspekte des Scrum-Prozesses. Ich habe hier einige Stichwörter aus seinen Ausführungen notiert:
- Product Owner ownes the project and is responsible for success and fail of project (product manager don’t code and are not ever responsible for success)
- Team is responsible for building great software (example: team=Car, PO=Driver), quality of software!
- Up to 35% of requirements change during the avearage project
- Up to 60% of the functionality delivered in successful projects is rarely or never used
- Quality Reduction Techniques:
- Overtime and weekends (HighMoon Studios)
- Cut testing (unit, acceptance, performance)
- Cut reviews (design, code)
- Don’t follow standards
- No refactoring
In herkömmlichen Szenarien ohne Scrum wird nach dem Schema Planung->Analyse->Design->Coding->Testing vorgegangen. Die weiteren Schritte Performance/User Acceptance/Pilot/Live müssen unter Scrum in den jeweiligen Sprint einbezogen werden. Es soll keine sogenannten “Post-Release-Sprints” geben! Ganz im Sinne von “Completely DONE – Every Sprint!”, also beachtung der “Definition of Done”! Wichtig: Der Scrum-Master darf das Team nichts präsentieren lassen, das nicht fertig ist. NIEMALS!
Hier noch einige Aussagen zum Stichwort “Core Functionality”, die m.E. äußerst zutreffend sind und deren man sich stets bewusst sein sollte:
- most significant new functionality builds on it
- also called infrastructure and legacy software
- is fragile, doesn’t have test harnesses, and few people still know how to or are willing to touch it
- requires more time to work on (lower velocity)
- Less/Bad quality kills companies
Hier der Link zum Vortrag, danke an Boris Gloger für den Tipp!
publiziert von e.rottensteiner am 19. Feb. 2011.
 Hier ein Video der RSA (royal society for the encouragement of arts, manufacturers and commerce), das sehr eindrucksvoll und gut gemacht zeigen möchte, welche Faktoren auf die Motivation Einfluss nehmen. Sinnhaftigkeit, Selbstverwirklichung, Lernen – das sind Motivations-Treiber in unserer heutigen IT-Welt. Finanzielle Aspekte wirken bis zu einem gewissen Grad, arbeiten aber wirklich nur erwartungsgemäß, solange es sich um mechanische Arbeit (bzw. und dem dazu verbundenen exakten Wissen) handelt. Je besser die Bezahlung, desto besser die Ergebnisse (in diesem Fall). Aber bei Tätigkeiten, die zunehmend von nicht exakt vorgegebenem Wissen abhängen, die kompliziert werden und deren konzeptuelle und kreative Anforderungen ansteigen, führen vermehrte finanzielle Anreize zu vermehrter schlechter Performance. Das Video arbeitet ganz gut die drei Faktoren, die zu besserer Performance und persönlicher Zufriedenheit führen, heraus: Autonomy, Mastery und Purpose. Ich empfehle dieses Video ganz besonders, nicht nur für jene Personen die andere motivieren sollen, sondern für jeden der im kreativen Bereich tätig ist…
publiziert von e.rottensteiner am 25. Okt. 2010.
 Ich bin hier über einen alten aber immer noch absolut guten Artikel von Joel Spolsky, CEO der Frog Creek Software in New York, zum Thema “Fünf einfache Fehler um zu scheitern” gestolpert. Joel schildert hier eindrucksvoll, welche fünf Dinge ganz einfach dazu führen können, ein Projekt scheitern zu lassen. Übrigens führte er als gutes Beispiel das im Jahr 2003 von Microsoft angekündigte WinFS an, welches ja bekanntlich bis heute nicht Realität wurde. Hier die fünf Fehler:
1. Start with a mediocre team of developer
2. Set weekly milestones
3. Negotiate the deadline
4. Divide tasks equitably
5. Work till midnight
Den gesamten Artikel lesen Sie hier.
publiziert von e.rottensteiner am 15. Okt. 2010.
Eigentlich will ich über einen äußerst interessanten Artikel von Roy Osherove zum Thema “Start doing code reviews” berichten, aber….
folgende ganz wichtige – und nicht nur in diesem Zusammenhang gültige – Aussage fand ich in diesem äußerst informativen Blogposting: “Your most important role in the team is to act as a coach – to teach them to solve their own problems.“. Das ist genau der Punkt, auf dem sich der Scrum-Master oder Projektleiter bewegen sollte. Jedes Über- oder Untersteuern dieser Linie wirkt sich negativ auf die Team-Performance aus und führt zu akuten Fehlfunktionen im Team. Ich finde, dieses Problem lässt sich wunderbar mit diesem einen Satz zusammenfassen.
Und jetzt zum eigentlichen Beitrag: Roy schreibt über einige gute Ansätze und Ideen was Code Reviews betrifft und gibt Hinweise was man bei Code Reviews feststellen sollte, warum man sie eigentlich und wer sie macht. Weiters gibt er eine gute Anleitung, wie man im Team überhaupt mit Code Reviews beginnen könnte (genial!) und beschreibt, was am Ende einer Einführungsphase als Ergebnis vorliegen sollte. Unter anderem das: “My team knows how to write better code today than they did last month”.
Der Beitrag ist unbedingt empfehlenswert, hier der Link dazu.
publiziert von e.rottensteiner am 14. Dez. 2009.
\\ Tags: Scrum
Über ein ausgezeichnetes Video zum Thema “Scrum Team Removes Impediment” bin ich gestolpert. Zeigt neben ein wenig Blödelei ganz gut einige der Kerneffekte von Scrum auf: Unter anderem nämlich Impediments zu finden und zu erkennen. Das Entfernen bzw. Beseitigen dieser ist dann der logisch weitere Schritt, wenngleich dies im Video eher auf sehr handgreifliche Art erfolgt. Aber besser irgendwie als nie – und dass der Scrum-Master schon eine gewisse Durchsetzungskraft auszuüben hat ist wohl unbestritten. Übrigens war ich sehr überrascht und erstaunt, Boris Gloger unter den Darstellern zu finden – da kann ich zur schauspielerischen Leistung ja wohl nur gratulieren!
publiziert von e.rottensteiner am 07. Okt. 2009.
Sicherlich ein wenig übertrieben dargestellte Szenen, aber demonstriert ganz gut wie auch ich mir die Arbeit eines Teams vorstelle, denn wie schreibt der Autor auch treffend im Kommentar zum Video: Time lapse of my team one day. We are the best team ever, living the Scrum dream. Every day is a party. The song is Ada’s “Bum Bum” off of “2 Rabimmel 2 Rabammel 2 Rabum 2 Bum Bum”. Und genauso wirkt auch das Team…
(PS.: Falls das eingebettete Video nicht läuft, einfach Klick darauf…)
publiziert von e.rottensteiner am 06. Okt. 2009.
\\ Tags: Scrum
 Ebenso wie sich die beiden konträren Projektmanagement-Methoden Wasserfall und Agile gegenüberstehen, positionieren sich auch führungsorientierte Teams zu autonomen Softwareteams. Auf gmbsg.com gibt es einen interessanten Artikel zum Thema “.NET Works: Autonome Software-Teams” zu lesen, der genau diese Thematik behandelt und herauszuarbeiten versucht, ob der eine Ansatz oder der andere Vorteile bringt. Um das Fazit vorweg zu nehmen: Es ist wieder der ganzheitliche Ansatz, der zählt. Nur wenn das Team richtig zusammengestellt ist, das Management bereit ist Verantwortung und Entscheidungen an das Team zu delegieren und das gesamte Unternehmen die Methode lebt, wird agile Vorgangsweise funktionieren. In den anderen Fällen wird wohl die konservative Team- und Unternehmensstruktur besser funktionieren. Hier der Beitrag.
publiziert von e.rottensteiner am 25. Sep. 2009.
Henrik Kniberg schreibt in seinem Blog im Artikel “Is your team cross-functional enough?”, dass nicht jeder im Team alles wissen muss sondern dass das Team als Ganzes das Wissen haben muss, das Projekt durchführen zu können. Henrik stellt eine einfache Workshop-Technik vor, mit der sich unter Zuhilfenahme der Fragestellung “Was sind die Hauptfähigkeiten, die für unser Projekt erforderlich sind?” das Know-How und dessen Verteilung im Team ganz gut ermitteln lässt (und auch einen guten Affekt auf die Teambildung erwarten lässt). Lesen Sie hier den Originalbeitrag.
publiziert von e.rottensteiner am 15. Sep. 2009.
\\ Tags: Scrum
Auf Google Tech Talks habe ich ein wunderbares Video gesehen, in dem Ken Schwaber (ich würde ihn als einen der beiden “Scrum-Päpste bezeichnen) das Basis-Framework von Scrum (naja, eigentlich ist Scrum selbst ja ein Framework…) erläutert und über dessen Verwendung in der Praxis erzählt. Obwohl schon im Jahr 2006 recorded hat der Beitrag imho keinerlei Aktualität verlorden – ein wirklich erfrischender und lockerer Vortrag (in der Dauer von über 1 Stunde) eines sympathischen Ken Schwaber…
publiziert von e.rottensteiner am 29. Aug. 2009.
\\ Tags: Scrum
 Die Clean-Code-Developer (CCD)-Initiative von Ralf Westphal und Stefan Lieser wurde zwar mittlerweile schon vor einiger Zeit gestartet und die erste große Euphorie ist vorbei – und gerade deshalb habe ich mir ein wenig Zeit genommen um jetzt darauf hinzuweisen, dass es sich bei dieser Initiative um einen ersten Anlauf handelt, Softwareentwicklung auf eine qualitativ nächsthöhere Stufe zu stellen. Worum geht’s? Das CCD-Team meint, dass Softwareentwickler nicht nur Profis sein sollen, die ihr Geld verdienen, sondern dass weit mehr dazu gehört. Und so haben sie ein Wertesystem erfunden (naja, vieles das ins Wertesystem aufgenommen wurde gab’s ja schon), welches Clean Code als Fundament zum Ziel hat. In der CCD-Initiative kann sich jeder einzelne durch die CCD-Grade arbeiten und nach und nach über vordefinierte Prinzipien, Regeln und Praktiken professionelle(re) Qualitätsarbeit als Ergebnis seiner täglichen Tätigkeit erzielen. Ich halte diese Initiative unbedingt für empfehlenswert und werden versuchen, diese demnächst (ev. auch im Team) umzusetzen. Hier noch der Link zum Forum und ein Link zu einem super PDF-Plakat mit dem Wertesystem.
Übrigens erarbeiten in Deutschland gerade Sofwareunternehmen (SAP u. andere) sowie Forschungseinrichtungen (Fraunhofer Institut u. andere) soeben an einem Industriesstandard für Softwarequalität, der den gesamten Software-Lebenszyklus umfassen soll (die CCD-Initiative beschränkt sich hier ja eher auf den Quellcode-Bereich). Mehr zu dieser Initiative, die auf 3 Jahre ausgelegt ist erfahren Sie hier.
publiziert von e.rottensteiner am 19. Mrz. 2009.
\\ Tags: ccd, Scrum
Hier ein Lesezeichen zu einem absolut guten Posting “How to recognise a good programmer” von Daniel Tenner aus dem Jahr 2007. Es geht hier um jene “Theorie”, dass der Lebenslauf nicht unbedingt über die wahren Qualitäten eines Programmierers aussagen muss. Woran erkennt man einen guten Programmierer? Hier sind die Basis-Indikatoren aufgelistet, die D. Tenner hinterfragt wenn er sich mit den Qualitäten eines potentiellen zukünftigen Mitarbeiters auseinandersetzt:
#1 – Passion
#2 – Self-teaching and love of learning
#3 – Intelligence
#4 – Hidden experience
#5 – Variety of technologies
#6 – Formal qualifications
Und hier der Link zum Originalbeitrag.
publiziert von e.rottensteiner am 04. Feb. 2009.
|
Letzte Kommentare