Viewing entries tagged
get agile

 How Hierarchy prevents Agility

3 Comments

How Hierarchy prevents Agility

Big projects tend to setup a big project organization, but why?-And is this really supporting agility needed or is it create other risks, that slows down time-to-market?

In my previous blog entry I told you about 

alternatives how to handle very big projects

. Well, I’ve noticed even though big projects have been broken down into smaller waves companies tend to setup a big project organization. Basically there’s nothing against an agile organization consisting of multiple teams such as 

SaFE

or similar. However, there have to be considered some important topics.

trafic-organization

I’d like to start with 2 phrases of the Agile Manifesto

„Individuals and Interactions over Processes and Tools“
and
„Customer collaboration over..“
 Agile Manifesto, 2001

First phrase tells us that tools should have less priority than direct interactions and communication. Well from my point of view in a big project organization that’s true AND false at the same time, let me explain you why!-On one hand it’s crucial to invest more in direct communication as in a single team organization. Otherwise we end up in well-known situation of the calling game, that first/team says red and until the end of the queue it’s green to the last. On the other hand in a scaled agile organization it’s impossible to talk to each teams from scaled product owner organization perspective and not all the teams could talk to each other at all the times. Otherwise team productivity will decrease dramatically. So key is identifying and planning dependencies. But product owner should not exclude teams in direct communication then again we come back to a multi-layered proxy organization. 2nd part of first sentence „..over Processes and Tools“ gets another importance in scaled agile organizations. Tools such as for agile portfolio management could support transparency in progress and budget burn-down. They deliver real time informations bottom up and prevent the calling game situations.

agile-portfolio

Image Source: rallydev.com

With real time information product refinements, problems identification and intervention could be done much earlier. Furthermore the agile organization, with it’s self organized approach, reduces overhead costs but also organizational risks.

"In reports about the failed project Insieme from the Swiss Fedural Departement of Tax the risks were much more positiv reported at management level, than originally at project level. For the followup project Fiscal-It Findel proposes reports on a half-year-based by the governement."

Findel-Report, NZZ 4. April 14

That leads me to 2nd phrase „Customer collaboration over ..“. Beside self-organization of scaled agile organization the stakeholder involvement is key. Based at real time informations and feedback about the periodically delivered working increments the stakeholders take there responsibility and even big projects could be worked out successfully!-How agile is that if we send reports on a half-year base, as mentioned in the Findel-Report (Findel is the delegation for finance from the Swiss Governement)?

3 Comments

Comment

Scrum - Ein umdenken im Sales Prozess 2, Argumente fürs Management

Generell wurde, wie schon in "Scrum - Ein umdenken im Sales Prozess" angetönt, der Verkauf von Scrum Teams vom Markt sehr gut angenommen. Dennoch gilt es nach wie vor Kunden und Stakeholder, welche noch in klassischer Vorgehensweise denken von Scrum zu überzeugen. Vielfach erhalten ich die Frage, wie garantieren Sie mir dass wir am Ende des Projektes die für uns wichtigen Lieferobjekte erhalten, wenn wir diese nicht im Detail offerieren und den Skope gemeinsam festlegen?-Scrum bietet hierfür wundervolle Antworten.
Besteht das Vertrauensverhältnis zwischen Kunde und Lieferfirma die ein Scrum Team stellt, da man beispielsweise schon gemeinsame Projekte durchgeführt hat, ist der Kunde meist leicht für den Bezug von Kapazitäten eines Scrum Teams ohne genaue Skopedefinition zu gewinnen. Kennt der Kunde aber weder die Lieferfirma noch Scrum gilt es zuerst etwas Marketing für beides zu betreiben.
Seitens Scrum gibt es die allgemeinen Argumente wie Transparenz bzw. Einbezug des Kunden in den Entwicklungsprozess, kurze Releasezyklen mit dem Resultat eines working Increments, etc. Erfahrungsgemäss lässt sich das kundenseitige Management  durch folgende Aussagen und Statistiken noch besser überzeugen:
Gartner Inc. says "get agile"
Für die Kunden die sich primär an Anderen orientieren sagt u.a. auch @Gartner_inc "get Agile". Beispielsweise hat das Departement of Defense DoD der USA kürzlich entschieden nur noch agile Projekte zuzulassen. Mehr dazu im Blog-Beitrag von @JeffSutherland 
Scrum is faster
Aufgrund von der Bündelung der Kräfte in multifunktionalen Scrum Teams, dem einfachen Tracken der Velocity und der fortwährenden Verbesserung sind Scrum Teams, gemäss Erhebungen von Scrumalliance.org2-8 Mal schneller als klassische Team nach Wasserfall. Über die Velocity besteht in Scrum ein einfaches Instrument die Teamperformance zu messen und die gesteigerte Performance über mehrere Sprints zu visualisieren.
Classic methods more often fail
Scrum Projekte sind, gemäss der 8 jährigen Erfahrungswerte des CHAOS Manifesto von 2011, mehr als 3 Mal erfolgreicher als Projekte nach Wasserfall. Zudem senkt Scrum die Abbruchrate von Projekten signifikant, von fast 30% bei klassischen auf unter 10% bei agilen Projekten.
8679e826488e1757adfb26aa9cca60f9
Doing what is really needed
Gemäss einer Studie der @StandishGroup wurden nur gerade 20% aller umgesetzten Features durch die Anwender oft gebraucht. Das heisst es hätte mit einem Minimum an Investitionskosten der volle Kundennutzes erbracht werden können, wären der Kundennutzen Treiber für die Umsetzung gewesen. Durch den Produktowner hat der Kunde in Scrum jederzeit die Hoheit über die Priorisierung von Features und kann deren Nutzen jeweils nach Abschluss eines Sprints beim User abholen. Somit wird mit höchster Sicherheit nur das umgesetzt was das Business benötigt.
d77fa27fa78d42e6bc2be13a40aacbfd
Changes for free
Scrum kennt zwar auch Changes jedoch entfällt der gesamte Overhead für deren Nachofferierung. Es werden Anpassungen und neue Features jederzeit ins Backlog aufgenommen. Logischerweise entfällt somit Umsetzungszeit am Ende für nice-to-have Features. Dies ist aber weniger kritisch, da nur das umgesetzt werden soll was dem Business auch was bringt.
759d40323f6297f02d3aaae6c7411a9e
Aus eigener Erfahrung ist es am Wichtigsten dem Kunden im Salesprozess glaubhaft klar zu machen, dass er durch den Bezug des Scrum Teams innerhalb der gebuchten Zeit die Features mit dem grössten Business Nutzen erhält. Hierfür erstelle ich meist zusammen mit dem PO des Kunden, anhand der groben Aufwandschätzung, eine erste Road Map. Es hilft auch den Leistungsausweis des Scrum Teams anhand analoger Projekte und in einem letzten Schritt das Scrum Team selbst vorzustellen. Über einen etwas radikaleren Ansatz berichte ich das nächste Mal.

Comment

Comment

“Get Agile or Get Outsourced!“ by Jeff Sutherland@Scrum Master Certification Course

Get Agile or Get Outsourced! by Jeff Sutherland@Scrum Master Certification Course Endlich fand ich die Zeit mich als Scrum Master zertifizieren zu lassen. Natürlich wollte ich das Neuste vom "Besten" erfahren und nutzte die Gelegenheit, dass Jeff -der Co-Gründer von Scrum- am 11./12. April einer seiner seltenen Besuche der Schweiz machte.

Siehe auch mehr bzgl. "Get Agile or Get Outsourced!" unter http://scrum.jeffsutherland.com/2012/12/tipping-point-get-agile-or-get.html

Comment