agile org is it a myth?
TRANSCRIPT
Is it a myth?
Agile(Network) organization
How to organize work?
Competition
Full stack ad-tech platform
Media Agencies
BrandsTrading desks
Publishers
35 -> 700+ in multiple locations
desire to keep the culture
300+ in product development
1911
Mechanical Engineer
Efficiency
Planning
Scientific management
1. Replace rule-of-thumb work methods
2. Scientifically select and develop employees
3. Strict division of work between workers and managers
4. Very detailed instructions for workers
DoingThinking !=
Workers are dumb.
*Method is NOT applied on managers and oriented downwards
Everything can be planned precisely.
Workers
Managersbudgetsstrategy
planningcontrolcommand
do what are told implement
follow instructions
report
no information
decisions
Why perfect* for 1911?
* even back then not all agreed
Level of education
Information access
Lower competition (monopolies, complicated projects…)
… and it’s 2016 now
1954
Peter DruckerManagement by Objectives
1960s
Douglas McGregorTheory X and Theory Y
1951 in Japan1993 in US
W. E. Deming94% of problems are system driven
1951-1971
Taiichi OhnoToyota production system
2006-…
Niels PflaegingOrganize for Complexity
2007-…
Nassim Nicholas Taleb
Things that gain from disorder
One common thing
It’s not about people
It’s mostly about the system
Is scientific management the best tool for…?
High competition
Knowledge workersFast pace
Change Complex work
Everyone is busy
Project manager
1. Team of analysts
2. Team of Devs
3. Team of QAs
but users are not not happy
SCRUM to the rescue!
It Works!
Multi functional team
Technical practicesCommon goal
Team is formed around value creationTeam is protected and served by SMs
Value is delivered incrementally
Back to org. design
Where are clients?
Things are getting slower
Not optimizing the whole
- manage dependencies - ensure value delivery
Control is needed over set of functions:
Alternatives?some ideas…
Network structure
PODInterdisciplinary (all needed roles)
Clearly defined value and output
Responsible for whole delivery cycle
Defined dependencies/boundaries
Can make decisions
Shared goal
Principles
Transparency
De-centralization
Service
Collaboration
Focus on value
2 emergent leaders: direction & execution
Product PODClosest to end users
Mobile
Direct revenueBusiness offering
Campaigns optimization
SSP DMP
Core business
Platform POD
Fraud
Indirect revenueUnique knowledge
API middleware
Data storageData collection
Research Infra
Monitoring infra
Difficult to scale out Used by many
Service POD
Serves other PODs
Supportive functions: HR, Guilds(QA, …), Coaching, Procurement, …
Main principles:educate
delegate through satellites
accumulate & spread knowledge
benefits failuresdepends
Value mapworks on a scale of 400 people
Product + Dev + IT services + CS
Dependencies
Missing units
are faster to notice
hire slow - fire fast
on-boarding
mindsetbetter than you
Technical excellence
API first thinking
Chaos monkey
Automate everything
Craftsmanship
Designed for change
split by value delivery
keep PODs small: < 30 - 40
Transparency
it’s scarydifficult to maintain
highly appreciated and noticeably improves decision making
depends on leaders
OwnershipResponsibility
Collaboration
culture remote offices
underestimated:
Cross dependent product apparently is not enough
Guidance of change
but let details evolve, don’t prescribe them
principles are not enough
describe main artifacts & guidelines asap
Do it everywhere
Platform & Service PODs
it will become a bottleneck
Delegation & Control*maintain healthy diversity of: - practices - approaches - tools - …
* there is always a temptation to make everything the same
control objectives, not approach
Conventional methods - presentation - managed discussion - status report - open discussion - brainstorm
Liberating structures - TRIZ - 15% solutions - Min specs - …
Is it a myth?
Questions?http://www.slideshare.net/npflaeging
http://eodf.eu