JAX2011

Why don't small
companies do Agile?

David Green

@activelylazy

londonswcraft.com

Java developer

Agile enthusiast

Aspiring software craftsman

Co-founder of LSCC

Twitter

Why don't small companies do Agile?

Small Company

Small companyEveryone knows everyone

People identified by name

Large companyPeople identified by role/team

Start with some definitions

Tried doing by numbers

About names not rolesWe need Mike to help with this

That's a job for Rachel

In large coWe need QA to help with this

That's a job for the operations team

Not to say ppl dont know each other

Identifying by role/team creates short hand but creates barrier

Little a agile

Something you areAbility to respond quickly

Some teams are naturally agileFind their own process

Bottom up agile

We mean agility

Responsiveness; ability to react

Bottom up enthusiastic developers introduce specific practices

Big A Agile

Something you do

Management imposed top down agile

By introducing specific processI.e Scrum

Goal is to be more agile to increase agility

Agile goes mainstream

Big-A-Agile is how we try to get there

Agility

Responding quickly to a change

1. Determine next required change

2. Implement small product increment

3. Get feedback from customer

Take away the theatre and buzzwords agility is pretty simple

Iterate!

Agility

Responding quickly to a change

1. Determine next required changeOn-site customer, prioritised backlog

2. Implement small product incrementUser stories, short iterations, TDD

3. Get feedback from customerCI, small releases, continuous deployment

XP practices fit this perfectly

Scrum & kanban provide structure on top forecasting, planning & process improvement

What makes a small companylittle a agile?

Small Company has...

Less process / bureaucracyQuicker to describe required change

Fewer signoffs before implementing change

Less inventoryLess code to change

Less likely to have legacy code

One team mentality

BA vs talking direct to customer

Requirements review; architecture standards committee; design sign-off

Not been in business long

Large business, older, more time to build legacy

Interesting metric: LOC/developer

50k 10ppl = 5k/dev

1m 20ppl = 50k/dev

Large companies, more code & more code per-developer

More to remember

Harder to changeSoftware factory

Small Company does...

Unit/acceptance testingEasier to retrofit tests

No arguments over ownership

Continuous integrationExcellent free CI tools

If any test coverage, devs likely to setup unasked

With less inventory, even starting on wrong foot easier to retro-fit tests

Dev owns junit tests; BA owns acceptance tests; who owns browser tests? QA or dev? What if they're written in junit?

Small Company does...

Shared ownershipWhole team own whole codebase

One team mentality

Small releasesCan't wait months/years for new product

Need to recognise revenue

Demoable product to drive sales

Learn & iterate

Small company trying to find product market fit cant wait

What stops a companybeing agile?

So small companies naturally do something approximately agile; what stops a large company replicating that?

Constraints

ProcessResponse to each mistake is more process

Accumulate over time

Difficult to unwindThats the way things are done around here

Any alternative must work first time

Checklists, sign-offs, reviews

Explicitly waterfall process

Byzantine process dedicated job to navigate

Failure of an alternative, nervous management return to process safety net

Were doing agile, but...

Requirements review, design sign off

This isnt scrum, but its waterfall, but were pretending its agile

Constraints

Functional silosEconomies of scale / simplify management

Releasing an increment involves multiple teams

The result?Resource contention

The response?Scheduling, priorities, reviews

Needs sufficient bandwidth & reliable SLA

Separate QA, build, operations team

More people, more meetings, more waste

Constraints

Lack of ownershipIt's always somebody else's problem

Lack of care someone else can clean it up

Competing demandsMultiple customers multiple views of priority

Different priorities: new features, support, technical

Team ends up thrashing

Everybody does their job, instead of delighting the customerI fixed the bug, it's up to QA to test it

I raised the defect, I'm waiting for dev to fix it

The build's ready, operations need to deploy it

It's the maintenance team's job to fix bugs

Thrashing - reviewing possibilities / changing direction

Constraints

Lack of flexibilityFixed scope, fixed deadline

Project mentality

Command and controlAgile removes the illusion of control

Politics

Development is documenting requirements

Start from vague ideas; most precise form is code

Project idea has a lot of appeal but software is weird stuff

People feel threatened by agile

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

So why do large companies do big A Agile...

Or the stupid...

What drives Agile Adoption?

If small companies are more naturally agile:

A large company adopts agile to behavemore like a small company

A company only needs formal Agile Adoption if it isn't naturally agile

Coming from waterfall background, or half arsed 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 toolsand we have mandatory processes and tools to control how thoseindividuals (we prefer the term resources) interactWorking software over comprehensive documentationas long as that software is comprehensively documentedCustomer collaboration over contract negotiationwithin the boundaries of strict contracts, of course, and subject to rigorous change controlResponding to change over following a planprovided 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, were an enterprise company, and theres no way were letting go of the items on the right.halfarsedagilemanifesto.org

What does Doing Agile look like?

What would a diabolical agile roll out look like? How would Dilbert's PHB do it?

Agile Roll Out

Pick project

Write requirements as User StoriesCreate project backlog

Prioritise

Form teamNo history to base judgements on

No story point standard

Project mindset

Have team size, fixed scope, fixed date

Backlog full of mandatory stories

Extra credit: new to company

Agile Roll Out

Run user story workshopsTeam takes time to form

Let team solve design problems up front

By the 3rd day, everyone has lost interest

Run first sprint planning sessionTeam commit to first sprint scope

Best if expected velocity reverse engineered

Planning theatre

Alpha geek & passive-aggressive cynicSolve all design problems can't estimate without understand what we're buildingEverything is a 5 anywayMight feel like planning theatre, but its important to be able to hold developers accountable for their commitment

Agile Roll Out

Nominate a Scrum MasterOr Project Manager as they used to be called

Have daily stand upsWhat I did yesterday...

Update burn down chart dailyAnd challenge the team when they're behind

Agile Roll Out

Sprint retrospectiveBut don't follow up on actions

Ship working softwareBut not till the end of the last sprint, obviously

Congratulate everyone on a successful agile project

Sprint end stories not done carry over

Process set in stone, can't change it

But of course, this isn't agile it's a checklist of behaviours

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

Now agile is mainstream

First line of the agile manifesto

Ironically...

Developers started the Agile movement to get closer to customers not project managers

-- Bob Martin

If big-A-agile isnt the answer for large companies, perhaps software craftsmanship provides a better view?

Software Craftsmanship

All about the peopleIf your business makes money from software, the people building that software are the most important in your business

Professionalism in programmingTaking responsibility for our craft

Taking responsibility for our careers

A culture for learning and improving

Team of Craftsmen

Software craftsmanship typically focuses on the individual developer How can I improve?

How can I learn?

How can I mentor others?

Id like to go off in a slightly different direction if I built a team of craftsmen, what would that look like

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

Responsible for, and capable of, delivering a working increment

More dependencies, more project management

Developers want to understand the business

Let them work with the customer, not for the customer

Experience

Correct balance of experience

Continuous learning

Best developers writing code, not managing

More developers faster

Avoid dead sea effect

Bob Martin talks about 1 master, 3 journeymen, 9 apprentices

Fred Brooks If a 200 man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back programming

Process

Rigid process is a constraint

Process should be internal to team

Standardisation is good but hard!Limits teams flexibility in face of change

Some mandatory process inevitableE.g. legal compliance

If team responsible for customer to production; all process is internal to team

Conforming to standard should be choice of team because its beneficial to the team

Some mandatory rest owned by team

Quality

The only way to go fast, is to go well-- Bob Martin

Rushing will make you go slowerCorners cut this morning will cost you this afternoon

We cannot successfully trade quality for timeWrite clean code first

Schedule implied

Cut features not corners

Most developers need to work harder on improving quality; very few over-engineer

Rush design, multiple code rewrites

Skip unit testing, bugs found late expensive to fix. Not my fault unlucky

Bugs thrive in crap code; debugging crap code takes time -> just fix the code!

Scrum/kanban etc give ways of tracking velocity/cycle time to make projections based on past experience

If schedule is slipping, 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

So how does craftsmanship help?

Agility

Responding quickly to a change

1. Determine next required changeProductive partnership, trust

2. Implement small product incrementAutonomy, experience, quality, minimal process

3. Get feedback from customerOne team, fast process, partnership with customer

Developers understand the business; customer trusts the development team what to build next.

Small, autonomous team; with right experience; producing clean code implement smallest thing

One team (devops); minimal, self-improving process; working in partnerhsip with the customer get feedback quickly

On top of the XP practices, craftsmanship is about the relationships, the team structure and a focus on quality

XP

Scrum

Craftsmanship

Pair programming

TDD / ATDD / BDD

Continuous Integration

Small releases

Coding standards

Collective ownership

Three Layers

XP is about the day-to-day practices

What developers do

XP

Craftsmanship

Prioritised product backlog

Product owner

Daily scrum

Sprint planning

Sprint review

Sprint retrospective

Information radiator

Scrum

Three Layers

Scrum is about the iteration-by-iteration practices

What project managers do

Three Layers

XP

Scrum

Craftsmanship

Autonomous

Balance of experience

Just enough process

High quality product

Software craftsmanship is about developers raising the bar

But its also about building the right team and genuinely empowering them to craft great software

This is in managements domain

Craftsmanship has these four key goals to enable agile delivery: autonomy, experience, process & quality let me summarise my thoughts about this into what I think the software craftsmanship manifesto should have said

Craftsmanship in Software

Autonomy over shared responsibility

Better developers over more developers

Permission over process

Quality over crap

We dont want dependencies, scheduling and project management we want autonomy

We dont want armies of untrained developers we want to hire great developers with a balance of experience and help them all progress

We dont want long process definition documents we want permission to use the right process for the job

Finally, we have to stop writing crap thinking its quicker. If we do the job right, speed will come naturally.

Questions?

@activelylazy

londonswcraft.com