Why don't small companies do big a agile?

Why don't small companies do Agile?
David Green
@activelylazy
londonswcraft.com

Small Company
Small company
” Everyone knows everyone”
People identified by name
Large company
People identified by role/team

Little a agile
Something you are
Ability to respond quickly
Some teams are naturally agile
Find their own process
Bottom up agile

Big A Agile
Something you do
Management imposed – top down agile
By introducing specific process
I.e Scrum
Goal is to be more agile
to increase agility

Agility
Responding quickly to a change 1. Determine next required change 2. Implement small product increment 3. Get feedback from customer

Agility
Responding quickly to a change 1. Determine next required change
On-site customer, prioritised backlog
2. Implement small product increment
User stories, short iterations, TDD
3. Get feedback from customer
CI, small releases, continuous deployment

What makes a small company little a agile?

Small Company has...
Less process / bureaucracy
Quicker to describe required change
Fewer signoffs before implementing change
Less inventory
Less code to change
Less likely to have legacy code
One team mentality

Small Company does...
Unit/acceptance testing
Easier to retrofit tests
No arguments over ownership
Continuous integration
Excellent free CI tools
If any test coverage, devs likely to setup unasked

Small Company does...
Shared ownership
Whole team own whole codebase
One team mentality
Small releases
Can't wait months/years for new product
Need to recognise revenue
Demoable product to drive sales
Learn & iterate

What stops a company being agile?

Constraints
Process
Response to each mistake is more process
Accumulate over time
Difficult to unwind
“ That’s the way things are done around here”
Any alternative must work first time
Checklists, sign-offs, reviews
Explicitly waterfall process

Constraints
Functional silos
Economies of scale / simplify management
Releasing an increment involves multiple teams
The result?
Resource contention
The response?
Scheduling, priorities, reviews
Needs sufficient bandwidth & reliable SLA

Constraints
Lack of ownership
It's always somebody else's problem
Lack of care – someone else can clean it up
Competing demands
Multiple customers -> multiple views of priority
Different priorities: new features, support, technical
Team ends up ”thrashing”

Constraints
Lack of flexibility
” Fixed scope”, fixed deadline
Project mentality
Command and control
Agile removes the illusion of control
Politics

What drives Agile Adoption?
Desire to...
Decrease time to market
Increase predictability
Increase productivity
Build the right product
Or the stupid, because I...
Heard about it from an analyst / at a conference

What drives Agile Adoption?
If small companies are more naturally agile:
” A large company adopts agile to behave
more like a small company”
A company only needs formal Agile Adoption if it isn't naturally agile

We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value: Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact Working software over comprehensive documentation as long as that software is comprehensively documented Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right. halfarsedagilemanifesto.org

What does “Doing Agile” look like?

Agile Roll Out
Pick project
Write requirements as User Stories
Create “project backlog”
Prioritise
Form team
No history to base judgements on
No story point standard

Agile Roll Out
Run user story workshops
Team takes time to form
Let team solve design problems up front
By the 3 rd day, everyone has lost interest
Run first sprint planning session
Team commit to first sprint scope
Best if expected velocity “reverse engineered”
“ Planning theatre”

Agile Roll Out
Nominate a Scrum Master
Or “Project Manager” as they used to be called
Have daily stand ups
What I did yesterday...
Update burn down chart daily
And challenge the team when they're behind

Agile Roll Out
Sprint retrospective
But don't follow up on actions
Ship working software
But not till the end of the last sprint, obviously
Congratulate everyone on a successful agile project

Checklist Agile
Now a checklist of processes to implement
Agile manifesto:
“ Individuals and interactions over
processes and tools”
Ironically – the success of process over people

“ Developers started the Agile movement to get closer to customers not project managers”
-- Bob Martin

Software Craftsmanship
All about the people
If your business makes money from software, the people building that software are the most important in your business
Professionalism in programming
Taking responsibility for our craft
Taking responsibility for our careers
A culture for learning and improving

Team of Craftsmen

Team of Craftsmen
What would a team of craftsmen look like?
Autonomous
Balance of experience
“ Just enough” process
Producing high quality product

Autonomy
Small team (7 +/- 2)
Deliver an increment of software independently
Minimize number of dependencies
Productive partnership with customer

Experience
“ Correct” balance of experience
Continuous learning
Best developers writing code, not managing
More developers ≠ faster
Avoid “dead sea effect”

Process
Rigid process is a constraint
Process should be internal to team
Standardisation is good – but hard!
Limits team’s flexibility in face of change
Some mandatory process inevitable
E.g. legal compliance

Quality
“ The only way to go fast, is to go well”
-- Bob Martin
Rushing will make you go slower
Corners cut this morning will cost you this afternoon
We cannot successfully trade quality for time
Write clean code first
Schedule implied
Cut features not corners

Agility
Responding quickly to a change 1. Determine next required change 2. Implement small product increment 3. Get feedback from customer

Agility
Responding quickly to a change 1. Determine next required change
Productive partnership, trust
2. Implement small product increment
Autonomy, experience, quality, minimal process
3. Get feedback from customer
One team, fast process, partnership with customer

Three Layers
XP
Scrum
Craftsmanship
Pair programming
TDD / ATDD / BDD
Continuous Integration
Small releases
Coding standards
Collective ownership

Three Layers
XP
Craftsmanship
Prioritised product backlog
Product owner
Daily scrum
Sprint planning
Sprint review
Sprint retrospective
Information radiator
Scrum

Three Layers
XP
Scrum
Craftsmanship
Autonomous
Balance of experience
Just enough process
High quality product

Craftsmanship in Software
Autonomy over shared responsibility
Better developers over more developers
Permission over process
Quality over crap

Questions? @activelylazy londonswcraft.com

Why don't small companies do big a agile?

by activelylazy

Accessibility

Categories

Upload Details

Usage Rights

Statistics