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