Viewing entries tagged

 How Hierarchy prevents Agility


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 


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


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

„Individuals and Interactions over Processes and Tools“
„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.


Image Source:

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)?


Why Scrum is that successful - Another perspective


Why Scrum is that successful - Another perspective

I recently talked with a Scrum Newby about why scrum is that successful and what makes the difference. I explained him that based at an instrument he knew, the task force.A task force is a temporary grouping of best resources for the accomplishment of a specific objective within shortest possible time. In IT it’s usually to solve a business critical incident.


If we compare a scrum team with a Task Force I see a lot of overlappings. We put together a multi-funtional team, containing of best resources each to accomplish fastest possible our objectives. While this process the scrum team has full management attention with direct communication to. Outcome has to fulfill highest business value, otherwise company looses time-to-market and it will become a problem. Only difference is that a Task Force will be disband after incident is solved. In other words we also could say:

"Scrum Teams are ongoing Task Forces"
Mirko Kleiner, 11/2013

Interesting point thinking about Task Forces is, that this is not new -but used very rarely- and just in extreme situations. Question is why, it’s approved and one of multiple reasons why Scrum is that successful.



My Talk about distributed Scrum @CodeCamp Romania

Today I held at Developer Conference CodeCamp in Isai, Romania a talk about our experiences in setup and run a distributed scrum. I'd like to share with you some impressions, over 150 attendees came to me speech. While the whole event had 600+ registered visitors.


Find below the presentation at slideshare and don't hesitate to contact me in any case of questions. I'll answer you on any channel, like twitter, comment to that article, email, etc.

[slideshare id=27100393&style=border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px&sc=no]

Download Link:


1 Comment

When we have a distributed Scrum?

I'd like to present you my personal definition of "Distributed Scrum". Do not take it too serious. But on the other hand it's not so wrong too. In discussions with newbie's about distributed scrum I often notice, that they put it in relation with nearshore/offshore teams. This gave me reason for finding a simple definition, that makes sense for business people too :-).


It's a fact that a lot of informal talks but also social integration are important topics during a coffee break. Thinking about this I came up with idea, that


Mirko Kleiner, 10/2013

If they don't do, they are distributed and should organize themselves as distributed scrum teams do. I often saw on customer side, that those teams are not aware of being a distributed teams. In other words companies with multiple offices, even in same street/city/country have distributed teams and should be aware of that while implementing scrum.

1 Comment


Importance of Meetings on same level in distributed Teams

While sharing customer experiences about distributed scrum a very simple action came up, that could have big impact to team culture and satisfaction. Last week we made a workshop with one of our team sourcing customers, that has it's own nearshore team at youngculture as workbench extension of his local developement team. While discussion with customer about they're implementation of a distributed scrum we noticed one simple action I'd like to share with you.

Usually meetings, e.g. daily standup, were done using video conferencing. Therefor each part of team moves to it's meeting room. So far so good.


In this case scrum master was part of local part of scrum team. So local team was talking and talking and often after a while they realized, that delocated part of scrum team was recently disconnected because of network issue. This sounds now nothing special, this happened to everybody of us in the past.

However, customer had afterwards internal discussions about this from another perspective. How this meeting passed off until this moment from point of view of delocated part of team?-The local part of team put themselfs in place of delocated team members and decided together the following action.

From now on scrum master was in any meetings added remotely too. In my opinion they reached with this very simple action, that  both parts of team are handled at same level. Doing so local part of team accepted delocated part of team as full-fledged team members!

To be honest I never looked at this from this perspective, but I will give this higher priority in the future for sure.



Wie gehe ich mein erstes Scrum-Projekt an?

Wie heisst es so schön "die Theorie ist das Eine aber die Umsetzung etwas ganz Anderes". @JeffSutherland hatte hierfür das Beispiel eines Tangotänzers genannt, der sich bei den ersten Tanzversuchen wohl auch ziemlich doof vorkommt :-). Gleiches gilt auch für die Implementierung von Scrum, zumindest hatte ich dies damals so erlebt. Nachfolgend möchte ich Euch einige Learnings aus eigener Erfahrung mitgeben.
Die @ScrumAlliance gibt bei der Einführung von Scrum relativ wenig vor, was einerseits ein Vorteil ist da flexibel und adaptiv. Andererseits fühlt man sich u.a. vor einem unüberwindbaren Berg beim erstmaligen Setup eines Scrum Teams.
Generell macht es sicherlich Sinn vor Start eines Initialprojektes ein Training mit dem Pilotteam durchzuführen. Um die Kosten klein zu halten bieten sich Scrum Trainer  zum Teil auch für Gruppenschulungen ohne Zertifizierung an. Ist erstmals das Grundwissen vorhanden gilt es praktische Erfahrungen zu sammeln, entweder in einem nicht zeitkritisches internes oder aber externes Projekt. Sehr gut geeignet für eine erste Scrum Implementation  sind bspw. auch Maintenance Projekte/Teams. Denn idealerweise kennen sich die Teammitglieder bereits und d.h. funktionieren als Team, verfügen über einen guten Kundenfokus bei hohem Qualitätsverständnis. Letzteres ist wichtig bei der Erreichung von Done. Als nächstes werden die Rollen (PO, SM, TE, Testing, etc) innerhalb des Teams verteilt.
Es empfiehlt sich die Teststrategie zusammen mit Done bereits in der Projektinitialisierung zu definieren. Auch sollte vor Projektstart sichergestellt werden, dass der PO über die notwendigen Entscheidungs-, als auch Fach-Kompetenzen verfügt. Die ideale Teamgrösse liegt unter 7 Personen, aus Erfahrung würde ich mit maximal 3-4 permanenten multifunktionalen Teammitgliedern starten. Sehen Sie bei der Kapazitätsplanung bereits auch adhoc Ressourcen wie IT-Unterstützung, internes/externes technisches Consulting bspw. für Architekturreviews und Audits vor. Die ersten Sprints würde ich kurz halten 1-2 Wochen um einerseits die Meetings zu trainieren, aber auch um schnellstmöglich einen ersten Output zu erhalten.
 "Vertrauen ist gut, Kontrolle ist besser"; setzen Sie Kontroll- und Optimierungsmechanismen auf bspw. über die Messung der Velocity, Sprintfortschritts via Burndown Chart, Qualität über das Tranken von Findings, etc. Sie werden sehen, dass die Messung der Velocity das Team zusätzlich anspornt und die Performance unglaublich schnell in die Höhe schnellt. Das Tool ist in einem ersten Projekt sekundär. Verlieren Sie damit keine Zeit sondern setzen sie ein Whiteboard inkl. Post-it's oder aber bspw. Excel via Dropbox ein, dies reicht erstmals völlig aus.
Starten Sie nicht mit einem verteilten Team. Dies ist höhere Schule bzw. ein Distributed Scrum, dazu später mehr. Dann geht's los. Etablieren Sie alle Artefakte und Meetings. Am Anfang wird alles noch sehr ungewohnt sein und evt. etwas länger dauern. Aber bereits ab Sprint 2 werden Sie die gemachten Erfahrungen in Adaptionen einfliessen lassen.