125
GUERRILLA LARGE SCALE PORTFOLIO PLANNING @ziobrando

Guerrilla portfolio management

Embed Size (px)

Citation preview

GUERRILLA LARGE SCALE PORTFOLIO PLANNING

@ziobrando

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD #Developer

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD #Developer

#Coach

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

#Agile

#Developer

#Coach

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

#Agile

#Developer

#Coach

#Facilitator

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

#Agile

#Developer

#EventStorming

#Coach

#Facilitator

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

#Agile

#Developer

#EventStorming

#Coach

#Facilitator

#Consultant

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

#Agile

#Lean

#Developer

#EventStorming

#Coach

#Facilitator

#Consultant

About me@ziobrando

I do something else instead

@ziobrandoAbout me

avanscoperta

#DDD

#Agile

#Lean

#Entrepreneur

#Developer

#EventStorming

#Coach

#Facilitator

#Consultant

THE ANTAGONISTThe quintessential stereotype

OUR HERO

I am a certified X-Wing Fighter PilotTM

Trust me!

Too obvious

WE NEED A BETTER HERO

Ladies ! Gentlemen, let me introduce you Mr…

Drummer with Nirvana Singer ! Guitar with Foo Fighters Plus amazing appearances (QoTS)

Cancelled a gig to bring the daughter to a party

Didn’t cancel a show when he broke his leg on stage.

THE DARK SIDE OF CAPACITY PLANNING

SOMETHING REALLY BASIC: JUST IN CASE

The setting

• Large organisations • Multiple teams • Many concurrent projects • Shared portions of the

codebase

Our resources

Empire’s capacity planning

I need a fixed story-point/man-day ratio in order to convert the estimation into FTE1s, so that I can plan projects at full capacity.

FTE = Full Time Equivalent. A unit of cost traditionally abused in the empire

Empire’s capacity planning

I would be happy to get rid of this agile stuff and just get Guaranteed Dates of Delivery

My resources

Risk management?

Rigid dress code Predictable salary Predictable value Excel-level replaceability

Empire’s capacity planning

The business is growing so that I need to hire more developers in order to catch the new opportunities

FTE = Full Time Equivalent. A unit of cost traditionally abused in the empire

My resources

* Fred Brooks …1975

Ninewomencan’tmakeababyinonemonth*

Ourgoalistomake9babies(projects)in6months!

That’sthepoweroftheforce!

Wemusthaveparallelprojects

THE UNTOLD QUESTION

It’s still wired in Kahneman’s System One

Idoubledthenumberofdevelopers.

WhytheS*thcan’tIdoubleproductivity?

It’s not about individuals, it’s

about the bands

It’s about team’s capacity

-Ramp-up time

-Domain knowledge

-Good teams have a style

-Mastery of key practices

It’s about system capacity

-Teams should be able to deliver independently

-1 cross functional team

-1 backlog

-1 product owner

That’s pretty much agile by the book

But in the empire…

• Large organisations • Multiple teams • Many concurrent projects • Shared portions of the

codebase

But in the empire…

• Large organisations • Multiple teams • Many concurrent projects • Shared portions of the

codebase•Teams can’t deliver by

themselves

Cross Functional?

The larger the organisation, the more the idea of Cross-Functional teams becomes a fairytale.

THE FORCE

DOESN’T WORKWhat cannot be seen cannot be

improved

Unfortunately

• Large organisations • Multiple teams • Many concurrent projects

Unfortunately

• Large organisations • Multiple teams • Many concurrent projects

•Teams can’t deliver by themselves

Above the surface…

Project #1

8 weeks

Project #1

4 weeks

Team Alpha

Team Tango

QA

Integrationteam

Project #1:

4 weeks

Project #1:

2 weeks

January February March

Project #1:

3 weeks

Above the surface…

Project #1

8 weeks

Project #1

4 weeks

Team Alpha

Team Tango

QA

Integrationteam

Project #1:

4 weeks

Project #1:

2 weeks

January February March

Project #1:

3 weeks

… and below

Above the surface…

Project #1

8 weeks

Project #1

4 weeks

Team Alpha

Team Tango

QA

Integrationteam

Project #1:

4 weeks

Project #1:

2 weeks

January February March

Project #1:

3 weeks

… and below

PO Clear business goal Visible team capacity

Supporting goals, not so visible team capacity often, conflicting ownership

fairly common setupFrontline teams

Service Teams

With no cycles, hopefully

The problem looks like….

Dependent activities pile up in some teams more than others.

Frontline teams experience delays from service and platform teams —> extra

management ! rework

Platform ! Service are burdened with growing incoming requests

My resources

My resourcesOurbacklogistoofull!

My resourcesOurbacklogistoofull!

Ourisoverloadedtoo!!

Ourstoo!!

My resourcesOurbacklogistoofull!

Ourisoverloadedtoo!!

Ourstoo!!

My resourcesOurbacklogistoofull!

Ourisoverloadedtoo!!

Youhaven’tseenmine!

Same problem

Show the problem-Find a way to visualise !

investigate the system constraint —> the real team capacity

-Put key stakeholders in the same room and co-create the corresponding model

Guess where…

Guess where…

Whoops!

-Once the constraint is visible, we can do sensible planning around that.

Once the constraint is visible…

Once the constraint is visible…

The empire view

Heavily unbalanced system Many idle resources are not

producing value Adding more resources to the

system isn’t really improving the system

Theory of constraintsIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

There’s no 100%

-Non bottleneck resources shouldn’t be allocated 100% - …or they’ll create more mess and interruptions

around the bottleneck

-Bottleneck resources shouldn’t be allocated 100% either - They’re humans

- ripple effects are more expensive then slack.

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

Empire ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

punish the bottleneck

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

punish the bottleneck

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

punish the bottleneck

Recruit more people

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

punish the bottleneck

Recruit more people

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

punish the bottleneck

Recruit more people

The constraint is still there, only worse

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

EmpireHide the system

constraints

Overload the bottleneck

punish the bottleneck

Recruit more people

The constraint is still there, only worse

ToCIdentify the constraint

Exploit the bottleneck

Subordinate the system to the constraint

Elevate the constraint

identify the new constraint

I played in Nirvana and in Foo Fighters

I played in Nirvana and in Foo Fighters

But NOT at the SAME time!!

A CLOSER LOOK AT COSTS

What cannot be seen cannot be improved

A simplified view

costs accumulate during development phases apparently small

or no cost in waiting to release

Revenues pop in (minus operations)

Cost of delay

Costs go down during development

(apparently) no cost in waiting to release

Revenues pop in (minus operations)

End of period

Cost of delay

Putting costs together

It’s just man_days * average_salary. Easy.

Overall…

But if we mess it up…

My resources

We’ll never finish that!

A CLOSER LOOK TO VALUE

Can you control that?

Problem solving

Does it happen in working hours only?

Can you relate that to timesheet?

Learning

Does it happen in working hours only?

Can you relate that to timesheet?

There’s no direct linear connection between cost

# value

Unless we want to destroy it

Interruptions

While working on different projects they’re disruptive or ineffective

They’re valuable while working on the same one

Dependencies

Are they the root of all evil?

What about self-inflicted mandatory dependencies?

Can’t solve the problem-Without allowing for some

duplication

-Without putting architecture under scrutiny

-Without allowing some heterogeneity

Estimations

An experienced agile team can be pretty good estimating

their own activity

Estimations

The same team is helpless estimating activities

depending on somebody else

Estimations

In corporate scenarios, the part which is out of control could easily get over 50%

… yep, talking about #noestimates

Unfortunately, one of our key resources quit

Unfortunately, one of our key resources quit

Unfortunately

Turnover

Turnover is a major disruptive force

It’s not bad luck.

It’s learning

Put the WiP under control

Remember the old… stop starting, start

finishing?

KEEP THE WIP SMALL

That’s the real ‘corporate-level’ force

Asyousaid…Ninewomencan’tmakeababyinone

month.

Oh c’mon…!

https://www.youtube.com/watch?v=JozAmXo2bDE

It’s viable

-Build around the learning

- create a shared (temporary) context

- build together a vision (#UserStoryMapping, #EventStorming)

-pride and ownership are your friends

Remember the old talks

Software development is a learning process

Working code is a side effect

Still valid at this scale too

THE DARK SIDE OF HR

Rigid dress code Predictable salary Predictable value Excel-level replaceability

Rigid dress code Predictable salary Predictable value Excel-level replaceability

What about TALENT?

Talent cannot easily be replaced

Replaceability is for piano-bar, not for great bands

Can you name a great band with continuous turnover?

Can you name a band that outsourced?

* …well Dave hasn’t really said that ;-)

A losing game

If you’re not working to attract ! retain talent, then you’re actively

working to lose talent

WRAP IT UP

The hard way

Being counterintuitive means that you’ll have to fight for the basics

Management with no specific IT background is very likely to blow it.

IT background is no guaranteed recipe for success either

Can’t solve invisible problems

Make the system constraint visible Make the implicit goals visible

Make the system constraint visible Make the implicit goals visible

Competing goals

Competition on key resources is poisonous

Please STOP it (including the invisible part: bonuses etc.)

There is no 100%

Slack is good

think twice before throwing in resources,

then think again

Not a process only It is an ecosystem, not a factory

HR is part of the problem and of the solution

Talent ! Pride are your friends

Dependenciesare making the problem

harder

It’s an architecture ! governance problem too

Ecosystem

it is always an ecosystem whether you like it or not

ignoring this, just places yours at the lower end of the spectrum

THANKS

[email protected] @ziobrando

Special thanks to @papachrismatts for (re)opening my eyes at ALE 2015 Sofia www.infoq.com/presentations/theory-constraints-portfolio

REFERENCES

http://www.infoq.com/presentations/theory-constraints-portfolio