agiles 2010
DESCRIPTION
Experience report I presented at Agiles 2010 titled "Compromising with Hesitant Organizations - Agile Implementation Paralysis"TRANSCRIPT
Compromising with Hesitant Organizationsagile implementation paralysis
Agiles 2010Lima, Perú
04/Oct/2010
THEME: control structures force compromises in agile adoption
PLACE: bpost - large organization, partly state-owned
QUESTION: can you compromise with entrenched practices?
THOUGHTS: identifying the building blocks of agile adoption
EXAMPLES: KPIs, nearshoring, MSPs… damaging compromises?
THEME: control structures force compromises in agile adoption
PLACE: bpost - large organization, partly state-owned
QUESTION: can you compromise with entrenched practices?
THOUGHTS: identifying the building blocks of agile adoption
EXAMPLES: KPIs, nearshoring, MSPs… damaging compromises?
20th century, rise of management
- corporations created to circumvent market forces
- standardized processes, roles and handovers
- maximize economy-of-scale benefits
- responsive to trends, forecasts and risk assessments
- management by numbers
- analytical
21st century, rise of collaboration
- “the innovator’s dilemma” and continuous creation
- change cycles getting shorter and more extreme
- “the black swan”
- successful companies are flexible, challenging hierarchies
- increased complexity and inter-connectivity
- human
“chaos is the principle of continual creation... & chaos never died."
A.O.A. Plenary SessionMarch '87, NYC
Enter Agile
- transparency (in all directions)
- flexible
- incremental
- multi-functional teams, collaborative
- organic
- human
THEME: control structures force compromises in agile adoption
PLACE: bpost - large organization, partly state-owned
QUESTION: can you compromise with entrenched practices?
THOUGHTS: identifying the building blocks of agile adoption
EXAMPLES: KPIs, nearshoring, MSPs… damaging compromises?
bpost
- Stats: revenue 2.2 billion EUR, 34,000 employees
- ICT: > 500 software engineers, serving internal clients
- Agile / Scrum: adoption of agile (2008) for some dev teams
- Culture: partly state-owned, hierarchical, bureaucratic
- Challenge: market liberalization in 2011
- People: mix of internals, externals and (recently) nearshore
- Reorganization: end of 2009
bpost 2009
Business
Operational
Commercial
…
(Client)
Projects
Client Managers
Project Managers
Business Analyst (Product Owner)
Architects
ApplicationsTeam Lead (Scrum
Master)
Developers
Testers
Technical analysts
Architects
ICT
bpost 2010
Projects
Applications
ICT
Resource Planning
- Project Managers- Business Analyst- Architects
- Developers- Testers- Tech. Analysts
Business
Operational
Commercial
…
(Client)
bpost re-organization in 2010
PROS: - E2E responsibility- (relative) freedom for teams to choose way of working- small developments are fast-tracked to release- dedicated project teams
CONS: - development team constantly changing members- central staffing treats developers as generic “resources”- increased integration risks - decreased flexibility towards business demands- application ownership remained with the client
THEME: control structures force compromises in agile adoption
PLACE: bpost - large organization, partly state-owned
QUESTION: can you compromise with entrenched practices?
THOUGHTS: identifying the building blocks of agile adoption
EXAMPLES: KPIs, nearshoring, MSPs… damaging compromises?
heisenberg x taylorism
change projects that conflict with organizational philosophy will be forced to compromise on critical aspects, leading to “implementation paralysis”
“learning organization”
command & control
organizational philosophy
- deterministic- scientific management- predictive planning- standardization- managed
- responsive- systems thinking
- continuous transformation- inter-connected
- communal
glossary mis-alignment
agile
sprint planning
story points
interaction
collaboration
bpost
work breakdown structure
contractual budget
handovers
workshops
compromise x best practice
command & control
organizational philosophy
“learning organization”
change initiatives, methodologies, processes, …
mis-alignment at this level:-agile implementation is destined for paralysis
-focus on adopting best practices
mis-alignment at this level:-compromises can lead to a successful adoption of change
-agile implementation can work
THEME: control structures force compromises in agile adoption
PLACE: bpost - large organization, partly state-owned
QUESTION: can you compromise with entrenched practices?
THOUGHTS: identifying the building blocks of agile adoption
EXAMPLES: KPIs, nearshoring, MSPs… damaging compromises?
vision aligned? now for the hard part
- vision alignment is constantly being challenged by entrenched practices and power fiefdoms
- these challenges will force change initiatives to negotiate implementation details compromising
- compromises are not inherently bad
- “irony is an agilist saying ‘that’s not how we do things’” (david hussman)
- ultimate goal should always be to find something that makes sense for a specific organization
- no set formulas, no silver bullets, no easy answer
some thoughts on compromises
- very challenging for (large) organizations to directly understand the principles of agile
- see glossary mis-alignment
- keep in mind the road of change is long, not all changes will be immediately accepted
- prioritize the agile principles needed to gain initial acceptance by management
- could be different principles for every organization, but these will set the roadmap for management acceptance
building blocks of agile adoption
T R U S T
D E L I V E R I N G V A L U E
F L E X I B L E
C O L L A B O R A T I V E
Individuals and Interactions over processes and tools
Working Softwareover comprehensive documentation
Customer Collaborationover contract negotiation
Responding to Changeover following a plan
building blocks of agile adoption
T R U S T
D E L I V E R I N G V A L U E
F L E X I B L E
C O L L A B O R A T I V EIf the foundation is not strong,
initiatives and changes that focus on the upper blocks will
ultimately fail.
Without the blocks at the bottom, Agile adoption is
essentially paralyzed
THEME: control structures force compromises in agile adoption
PLACE: bpost - large organization, partly state-owned
QUESTION: can you compromise with entrenched practices?
THOUGHTS: identifying the building blocks of agile adoption
EXAMPLES: KPIs, nearshoring, MSPs… damaging compromises?
projects
applications
ICT
resource planning
- project managers- business analyst- architects
- developers- testers- tech. analysts
central “resource” management
goal: - optimal utilization of software
engineers- rotate developers between projects
and maintenance- central pool of talent should increase
responsiveness / flexibility
assumptions: - work can be planned ahead of time- teams can be changed at all times- central planning can work for dev- chargeability KPI makes sense
projects
applications
ICT
resource planning
- project managers- business analyst- architects
- developers- testers- tech. analysts
central “resource” management
result: - unmotivated developers- senior developers always on projects- enhancements / maintenance down- pipeline management not addressed- client unhappy
compromising:
T R U S T
D E L I V E R I N G V A L U E
local team
nearshore team
application team
nearshoring
goal: - reduce cost- increase flexibility (up/down-staff)- improve documentation of existing
applications- reduce dependency on key senior
developers
assumptions: - local team can be reduced in size- client would accept remote team- documentation is sufficient to replace
local senior developer- upstaffing can resolve additional
demands
backlog
local team
nearshore team
application team
nearshoring
result: - still ongoing (too early for conclusion)- issues with central planning means
seniors have no time for coaching- knowledge transfer not happening
(distance + time)- client already doesn’t trust nearshore
compromising:
backlog
T R U S T
D E L I V E R I N G V A L U E
checkpoint report
sprint checkpoint report
goal: - increase visibility of sprint objectives /
outcome to stakeholders- identify risks / issues early on- promote agile metrics (glossary)
- burndown charts, velocity, retrospective…
assumptions: - stakeholders would be interested in a
periodic report (3 weeks for us)- ideally would cause them to be more
involved- at least would show “structure” of
agile team
screenshot
checkpoint report
sprint checkpoint report
result: - greater trust in agile teams- improved grasp of agile metrics- did not improve collaboration (“I’ll
wait for the report”)- report was input for MSP, not the first
step in real flexible planning
compromising:
F L E X I B L E
C O L L A B O R A T I V E
kpi report
kpi’s and quality gates
goal: - provide clear, measurable goals that
people should aim to achieve- visibility over ICT’s performance- ability to pinpoint areas that need to
be improved- assurance of quality / reduced risks
assumptions: - visible metrics will motivate people- problems can be identified quicker
with accurate kpi’s- passing quality gates assures client of
reduced risks
kpi report
kpi’s
result: - people are more focused on their
bonus (playing the metrics)- incorrectly tuned kpi’s lead to de-
motivation of some teams / people- quality gates not reflecting code
delivered
compromising:
T R U S T
D E L I V E R I N G V A L U E
questions
?
bibliography
• “the end of management”, the wall street journal (21/08/2010)
• “the innovator’s dilemma”, clayton christensen
• “the black swan”, nassim taleb
• “taz”, hakim bey
• “the fifth discipline”, peter senge
• “the collaborative enterprise”, charles heckscher
• “the dispossessed”, ursula k. le guin