Embed Size (px)
Citation preview
#NoProjects Teams Over Projects
Allan Kelly [email protected] h:p://www.so?warestrategy.co.uk Twi:er: @allankelly.net
Agile on the Beach September 2015
#BeyondProjects
Allan Kelly…
Chapters in… Business Analysis and Leadership, Pullan & Archer 2013 97 Things Every Programmer Should Know, Henney, 2010 Context EncapsulaAon in PaBern Languages of Program Design, vol #5, 2006
Ø ConsulRng on so?ware development & strategy
Ø Training for Agile Author – Xanpan: Team Centric Agile So?ware Development
h:ps://leanpub.com/xanpan (2014-‐2015) – Business Pa1erns for So4ware Developers (2012) – Changing So?ware Development: Learning to be Agile
(2008)
The problem with projects….
… and I don’t mean this in a small way
Project Model AssumpRons
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. OpRons are valueless
These assumptions do not hold in software
development
Conflict and…. Goal displacement – Chasing date over benefit – Chasing Rme over benefit – Chasing cost over benefit – Chasing features over benefit
The Project model leads to…
End Dates damage quality
Short term thinking leads to… Corner cueng Known & unfixed bugs Residual technical debt Knowledge lost
BIG
Projects are big batch of work
• Project model is opRmized 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
So?ware development…
• Does NOT have economies of Scale • Development has DISECONOMIES of scale
Milk is cheapest in BIG cartons
So4ware is cheapest in lots of small cartons
And small cartons of so?ware reduce risk
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
So?ware isn’t temporary
Projects are temporary
A project is….
Project Management InsRtute -‐ h:p://pm4id.org/1/2/
"PMI defines a project by its two key characterisRcs: • it is temporary and • undertaken to create a product, service, or
result that is unique."
A Project is…
“A temporary organizaCon that is needed to produce a unique and predefined outcome or
result at a pre-‐specified Rme using predetermined resources.”
PRINCE2 definiRon of project
Successful so?ware doesn’t stop
Successful so?ware conRnues to change Only dead so?ware has an end-‐date
Projects end
Successful so
?ware
doesn’t
Successful so?ware?
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 So?ware Stops changing
Data from SourceForge search for “WebBrowser” 19 Jan 2014
Temporary organizaRons
The most destrucRve idea known to so?ware development
Temporary OrganizaRon?
• Storming • Norming • Forming • Performing • Destroying
} Takes Rme & money!
Why destroy performing teams? Why spend that money? Why loose knowledge?
Temporary organizaRons
Disbanding teams destroys – Knowledge – Capability – Performance
The most destrucRve idea known to so?ware development
Corporate Psychopathy Process by which corporaRons disband performing teams and
release staff
A Match Made in Hell
So?ware Development
Project Management
So?ware is forever Projects are TEMPORARY
So…
• Organize to do lots of small • OpRmize for small batch size • Organize around that which is stable • Plan for conRnuity
ConRnuous is not Temporary
ConRnuous flow ConRnuous improvement ConRnuous delivery ConRnuous benefit
Waterfall 2.0
Jonathon’s Run Fall, Pennsylvania by Hubert Stoffels (h:p://flickr.com/photos/22195940@N00) CreaRve Commons License
ConRnuous Flow
ConRnuous 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
Base work around stable teams
Teams Over Projects
Agile Manifesto
Teams over projects
Stable teams…
• Keep teams together • Flow work to the teams • Work in the small • Work conRnually • Demonstrate value
Bring the work to the team
Organize by business stream & team
• Aim for stable teams & conRnuity • Close to business • Manage queues within capacity
Stream #1 Dev Team
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 So?ware
comes out
MVT -‐ Minimally Viable Team
Start with the smallest team possible
2 Beware Conway’s Law Start small & grow organically as needed
Teams – Ameba!
• Start small – 1, prototype or research – 2, get going: Engineer & BA
• Grow • Split • Focus team – 1 product/area
• Contains all skills
VerRcal teams
• Staff with all needed skills – Coders – Testers – Product Analysts – Managers
• Authority – To do what is needed
• Responsible for delivery
Horizontal Teams
Business Logic
Database
Test
User Interface
Business Analysis
VerRcal Teams
Team & DuraRon
Prefer – Short and Fast
Over – Long and Thin
• Faster Rme to market • Higher Rate On Investment • Less resource contenRon • Requires clear prioriRzaRon & project closure
Beyond Projects It ain’t ever over BAU is not a dirty work
allan kelly [email protected] www.so?warestrategy.co.uk Twi:er: @allankellynet
