SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
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
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
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
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
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
Editor's Notes
Public domain image, http://commons.wikimedia.org/wiki/File:Sausage_making-H-3.JPG