Viewing entries in

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



Scale a Scrum - How Spotify did it

Currently we at youngculture have mostly independed scrum teams. However, I always was wondering how huge companies like Microsoft, Apple, etc  handle hundreds and thousands of people with Scrum. Read below, Spotify made there way of implementation public. images-2

In the "traditional" scaling of scrum, as Craig Larman, Bas Vodde described 2003 in there article, I always missed the deep connection on a team level. Ok we do scale at product owner side, but how we handle topics like architecture, infrastructure, sharing technical knowhow and experiences over all teams?-Spotify describes in there article how they did. And you know what, without knowing it, that was exactly our  implementation at youngculture so far too :-).



  • A Squad is similar to a Scrum Team, designed to feel like a mini-startup
  • A Tribe is a collection of squads that work in related areas
  • A Chapter is your small family of people having similar skills and working within the same general competency area, within the same tribe
  • A Guild  is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices

What I personally like mostly is having instruments like Chapter's and Guild's that makes the glue over all company and share knowhow, tools and code not only but mostly on personals interest.