1.
#NoProjects
Teams Over Projects
Allan Kelly
allan@allankelly.net
http://www.softwarestrategy.co.uk
Twitter: @allankelly.net
Agile on the Beach
September 2015
#BeyondProjects

2.
Allan Kelly…
Chapters in…
Business Analysis and Leadership, Pullan & Archer 2013
97 Things Every Programmer Should Know, Henney, 2010
Context Encapsulation in Pattern Languages of Program
Design, vol #5, 2006
 Consulting on software
development & strategy
 Training for Agile
Author
– Xanpan: Team Centric Agile Software Development
https://leanpub.com/xanpan (2014-2015)
– Business Patterns for Software Developers (2012)
– Changing Software Development: Learning to be Agile
(2008)

3.
The problem with projects….
… and I don’t mean this in a small way

4.
Project Model Assumptions
1. You know what you want
• And have perfect foresight
2. Value is knowable
• And is known before start
3. There is no value in flexibility
i.e. Options are valueless
These assumptions do not
hold in software development

5.
Conflict and….
Goal displacement
– Chasing date over benefit
– Chasing time over benefit
– Chasing cost over benefit
– Chasing features over benefit
The Project model leads to…

6.
End Dates damage quality
Short term thinking leads to…
Corner cutting
Known & unfixed bugs
Residual technical debt
Knowledge lost

7.
Projects are big batch of work
• Project model is optimized for big
• Used on small pieces of work it inefficient
• Projects push big decisions up…
to big men
with big cheque books
top-down authority

8.
Software development…
• Does NOT have economies of Scale
• Development has DISECONOMIES of scale

9.
Milk is cheapest
in BIG cartons
Software is
cheapest in
lots of small
cartons
And small cartons
of software
reduce risk

10.
Consider a large project
Against several small
projects
Project A: Risk = 30% Value at risk = £1m
Therefore risk weighted value = £300,000
Prj B: Risk = 15%
Value @ risk = £½m
Therefore … = £75,000
Prj C: Risk = 15%
Value @risk = £½m
Therefore … = £75,000
E: Risk = 6%
@risk = £200k
Therefore = £12k
F: Risk = 6%
@risk = £200k
Therefore = £12k
G: Risk = 6%
@risk = £200k
Therefore = £12k
H: Risk = 6%
@risk = £200k
Therefore = £12k
I: Risk = 6%
@risk = £200k
Therefore = £12k

11.
Software isn’t temporary
Projects are temporary

12.
A project is….
Project Management Institute - http://pm4id.org/1/2/
"PMI defines a project by its two key
characteristics:
• it is temporary and
• undertaken to create a product, service, or
result that is unique."

13.
A Project is…
“A temporary organization that is needed to
produce a unique and predefined outcome or
result at a pre-specified time using
predetermined resources.”
PRINCE2 definition
of project

14.
Successful software doesn’t stop
Successful software continues to change
Only dead software has an end-date

15.
Successful
software?
Moodle
Weekly downloads: 23,239
Last update: 3 days (16 Jan)
Web Torrent
Weekly downloads: 0
Last update: 17 April 2013 (9mths)
PerlLORD
Weekly downloads: 0
Last update: 25 Feb 2013 (11mths)
1) If they use it,
it will change
2) Only Dead
Software Stops
changing
Data from SourceForge search
for “WebBrowser” 19 Jan 2014

16.
Temporary organizations
The most destructive idea known to
software development

17.
Temporary Organization?
• Storming
• Norming
• Forming
• Performing
• Destroying
}Takes time &
money!
Why destroy performing teams?
Why spend that money?
Why loose knowledge?

18.
Temporary organizations
Disbanding teams destroys
– Knowledge
– Capability
– Performance
The most destructive idea known to software
development

19.
Corporate Psychopathy
Process by which corporations
disband performing teams and
release staff

20.
A Match Made in Hell
Software
Development
Project
Management
Software is forever
Projects are
TEMPORARY

21.
So…
• Organize to do lots of small
• Optimize for small batch size
• Organize around that which is stable
• Plan for continuity

22.
Continuous is not Temporary
Continuous flow
Continuous improvement
Continuous delivery
Continuous benefit

23.
Waterfall 2.0
Jonathon’s Run Fall, Pennsylvania by Hubert Stoffels (http://flickr.com/photos/22195940@N00)
Creative Commons License
Continuous Flow

24.
Continuous flow
• Work in the small
• Get good at doing small things
– Deliver small increments of value
– And evaluate results
• Go fast
• Value seeking
• Repeat, don’t stop

25.
Base work around stable teams
Teams Over Projects

26.
Agile Manifesto
Teams over projects

27.
Stable teams…
• Keep teams together
• Flow work to the teams
• Work in the small
• Work continually
• Demonstrate value

28.
Organize by business
stream & team
• Aim for stable teams & continuity
• Close to business
• Manage queues within capacity
Stream #1 Dev Team

29.
Team is a Whole
• Testers are first class team members
– Embedded with team (always)
• Product Owners / Managers / BA are team
members too
Dev Team –
Coders,
Testers, etc. …
Requirements
go In
Working Software
comes out

30.
MVT - Minimally Viable Team
Start with the smallest team possible
Beware Conway’s Law
Start small & grow organically as needed

31.
Teams – Ameba!
• Start small
– 1, prototype or research
– 2, get going: Engineer & BA
• Grow
• Split
• Focus team
– 1 product/area
• Contains all skills

32.
Vertical teams
• Staff with all needed skills
– Coders
– Testers
– Product Analysts
– Managers
• Authority
– To do what is needed
• Responsible for delivery

33.
Horizontal
Teams
Business Logic
Database
Test
User Interface
Business Analysis

34.
Vertical
Teams

35.
Team & Duration
Prefer
– Short and Fast
Over
– Long and Thin
• Faster time to market
• Higher Rate On Investment
• Less resource contention
• Requires clear prioritization & project closure

36.
Beyond Projects
It ain’t ever over
BAU is not a dirty work
allan kelly
allan@allankelly.net
www.softwarestrategy.co.uk
Twitter: @allankellynet