Happy and proud to be among great people of agile community. It will definitely encourage me to continue sharing my ideas and thoughts about how to organize work in a company to keep Agile mindset even when you grow from 20 to 600.
Simple conclusion that i came up for myself – it works! And it is the best way to grow up to an organisation to a scale of 600 people at least. Reasons behind are simple – it allows you to scale fast naturally and have built-in flexibility in the structure to a constant change. Obviously there are challenges which you have to overcome.
TOP 7 Challenges
Flexible structure is not possible if you want to keep technical foundation monolithic. Devops and Service Oriented Architecture is a must use practices otherwise organisation will not be able to adjust to changing business demand fast enough
Easy to fallback to local optimizations and thinking that structure is something permanent
POD Leads and Keepers start to maintain status quo rather than to advocate the change as structure must be adjusted according new findings, growing number of people, speed of delivery and many other things that pop up during the journey
Extreme sense of ownership can lead to certain local optimizations instead of seeking global improvement
It’s very important to define common artefacts for PODs as soon as possible so everybody knows what to expect and how to work. You can start from something simple first and grow it naturally according the needs
Pod sponsor role is extremely critical in order to achieve alignment and solve challenges outside the scope of the POD or priority conflicts
Especially for service pods which are often understaffed and business value is indirect, but high expectations are formed by the community
Pod sponsor is an important contributor to network orchestration
Transparency is key, especially regarding speed of delivery and commitments
Is it possible to build an organisation which benefits from uncertainty, errors and randomness?
How small should be the teams?
What should be minimum process?
What is the level of centralisation/decentralisation?
How often achieved agreements must be reviewed?
What behaviour is needed?
What is the ratio between explicit and self-discipline?
What is the level of autonomy?
Can growth be the target?
Should it reflect value delivery?
Should org. look different depending on the context?
Should unstable be new stable?
Those are curse words for any member in a company. Often companies are designed as if for any non-repetitive task it is exactly known what is going to happen and what is the most efficient way to do that.
Often notice that people tend to be “black and white” when talking about practices in any field, let it be management, design, development or whatever… e.g. go completely scientific and measure everything and be very structured or become completely ad-hoc and reactive.
Of course it’s an option to work in a binary way, but in my opinion it is not necessarily the best way to go while facing complex problem. You must have various “tools” in your toolbox and be creative in applying them depending on a situation or context.
So, can design be a science? Sometimes yes, sometimes no. Can it be empirically based, evidence driven? Yes. Will it have to reply on intuition and the creativity of individual designers? Sometimes, yes.