Agile Software Development In Theory and Practice Johannes Brodwall

Agile Software Development

In Theory and Practice

Johannes Brodwall

Who am I?

Johannes Brodwall

Board member, smidig.no

http://smidig.no/forum/

Organizer,

Oslo XP Meetup

Every first Monday of the month at Scuba bar (Grünerløkka)

http://xp.meetup.com/13/

Lead Software Architect

Sole developer

Small chat solution

Who are you?

Who works on ”a large project”?

Who works on (what you feel is) ”a large project”?

Who release software infrequently?

Course in an agile method

Extreme programming

Lean Software Development

Course in an agile method

Extreme programming

Lean Software Development

History lesson

SnowbirdAgile Manifesto

We value

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

History lesson

SnowbirdAgile Manifesto

We value

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Specific for Perl

Test::MoreDevel::Refactor

JiftyPerlActor

Tinderbox

Specific for Perl

Test::MoreDevel::Refactor

JiftyPerlActor

Tinderbox

Experience report on using agile techniques in small and large environments

Continuous Integration

Relentless Testing

Frequent releasesCollective Ownership

Refactoring

Experience report on using agile techniques in small and large environments

Relentless Testing

Frequent releasesCollective Ownership

Refactoring

The Problem

Projects in crisis

Failure to deliver value

Barry Boehm: ”Software Engineering Economics”, 1984

”An infant engineering discipline”

The Response

”Make sure the reqs are right before you do anything”

”Make sure nobody changes the requirements”

”Try Harder!”

BigRequirementsUpFront

(Picture: RUP analyst hard at work)

Trying to stuff everything into my small head!

It hurts!

And then the world changes!

When I guessed wrong...

... my work is wasted

... it is even harder to change the system

Speculation breeds complexity

Complexity breeds complexity

And again....

.. my crystal ball

is broken!!!

So I get a poorly divided, rigid design

Formality:

make decision ”correctly”

The right decision

Change control mechanism

Just-in-case requirement

(”free” in the beginning)

Failure to deliver value

These ”solutions” are part of the problem

Fixed-price, fixed-scope contract bids

The Alternative

Instead of just-in-case...

... just-in-time

Boehm was wrong

(or at least Boehm’s phasist readers)

Harness the Power of Myopia

1... 2... 3...

1. Focus on short term

Requirements for current feature

Design for current requirement

2. Deliver something

Ideal: Deliver working, tested features as often as you safely can

3. Get feedback

(talk to people!)

4. Adapt

Get Feedback

Avoid Speculation

The cost of speculation

Myopic requirements

Analyse the current release

Myopic development

Design for the current problem

Myopic programming

Write a test – make it pass – Remove duplication

Changing your minds

... is not always easy

... is not always safe

(painted into a corner)

(Experience: Sustainable myopia varies with org.)

Agile: Enabling safe myopia

Not technology

Practices, discipline, communication

1. Prioritize requirements with a backlog

Prioritize requirements with a backlog

(NB: Software maintainance)

Too fully take advantage: Close communication with

stakeholders

2. Simple design: Goal and means

Avoid designs that make change expensive:

Don’t Repeat Yourself!

For example: Jifty

Solve the current problem only

3. Automated regression suite

Test::Simple

Test::More (Schwern)

4. Refactor all the time

Def: Refactor“To transform a program while

preserving its behavior.”

Refactor to simple design

5. Continuous Integration

6. Collective Ownership

It’s not: ”Your code and mine code”

Refactor everything

Continous integration keeps you safe

Fine tuning your agile process

Deliveries

Large organization Less frequent releasesHigh risk Less frequent releases

Staged (internal delivery)

Breaking it up

”The smallest meaningful task”

Small releases: Penalizes half-work

One click deployment

Extreme: Deploy every feature

Mastering Testing

”Only test what you want to work”

-- Ron Jeffries

Many types of test

Acceptance test

Databases

User interfaces

Integration tests

Unit test

Performance/Load/Stress

All can be automated

Greatest value: Acceptance tests

Easiest to implement: Unit tests

Starting unit testing:

Don’t

Try to test everything in the beginning

Focus on ”bang for the buck”

Good: New features

Better: Bugs

Even better: Bug ridden code

Smoke test

Def: ”A rudimentary form of testing; power is applied and the tester checks for sparks,

smoke, or other dramatic signs of fundamental failure”

Perfecting unit tests

Remember: Test is a noun!

Tests as specification

Write tests first

Consider test brittleness

Consider unit test running time

Implementing Continuous Integation

Avoid sliding back

Not useful in small projects (1-3 people?)

Can at least scale to 50 people

Be prepared to pay the price

Continuous Integration will become critical to you org.

Has given us the ability to do enormous refactorings

Has enabled us to treat 500 KLOC as one code base

Communication

What is the biggest cost driver?

Misunderstandings

Misunderstood business needs

Misunderstood interface to integrate with

Misunderstanding your neighbours code

Not knowing that you neighbour is doing the same

as you!

Techniques:

Keep your customer close

Obvious, difficult(But if the customer won’t be close, how

important is the project, really?)

Pair programming

Fun, difficult, rewarding, exhaustingHard to sustain (but great if you

Stand up meetings

• ”What did you achieve since yesterday?”• ”What do you plan on achiving today?”

• ”What is standing in your way?”

Keep it short!

Fun, easy, rewardingExhausting (if you don’t do it right!)

Reflection workshops

Fun, easy, rewardingValue decreases with time

Conclusion

Phasist development...

Forces us to guessForces us to consider a too

much at the same time

... leads to suffering

(and our poor reputation as professionals)

When I speculate, I’m usually wrong

So instead...

1. Short-term decisions

2. Deliver something

3. Get feedback

4. Adapt

(requires practices and tricks)

Summary of tricks

Prioritize with a backlog

Keep in touch with stand-up meetings

Just-in-time planning and requirements

Simple design

Test only what you want to work

Refactor mercilessly

Parting words

Software isn’t a canned good

It rots during storage

Good luck with your agile project!

Thank you for listening

http://smidig.no/forum/http://xp.meetup.com/13/

Agile Software Development In Theory and Practice Johannes Brodwall

Documents

Coding dojo PocketMobile Johannes Brodwall, Chief scientist Exilesoft

Extreme Programming Live WeActuallyBuildStuff Johannes Brodwall Exilesoft Chief scientist @jhannes Guest starring: Chaminda Sooriyapperuma

Extreme Collaboration Johannes Brodwall Exilesoft Chief scientist @jhannes TODO: Good pairings: Senior/senior: Ping-pong Respectful senior/senior: Stategist/tactician

Extreme delivery: The real measure of progress is… Johannes Brodwall Exilesoft Chief scientist @jhannes

Agile vs agile (vs agile)

Planning for Agile Earth Observation Satelliteski/papers/aldinger...Planning for Agile Earth Observation Satellites Johannes Aldinger and Johannes Lohr¨ Albert-Ludwigs-Universit¨at

Remote Pair Programming Agile 2013 Johannes Brodwall Exilesoft Chief scientist @jhannes Guest starring: Niruka Ruhunage

Coding Dojo AgilePrague 2012 Johannes Brodwall, Principal Architect Steria Norway @jhannes

Scenarios An old approach to user stories XP2011 Johannes Brodwall, Storyteller Steria Norway

Experience Agile Programming SDC 2012, Göteborg Johannes Brodwall Steria Norway @jhannes Featuring: Ole Chr Rynning

Bare-knuckle web development DevDay.LK Johannes Brodwall, Chief scientist Exilesoft Global @jhannes

WEB PUSH Johannes Brodwall. Outline The low down Is it time? Implementation notes Firefox Chrome Safari Implementation bits

Johannes Brodwall Chief Scientist Smidig arkitektur

Bare-knuckle web development Agile Prague Johannes Brodwall, Chief scientist Exilesoft Global

Architect Bootcamp Johannes Brodwall, Chief scientist Exilesoft Global

Johannes 21:15-17 Bijbellezing: Johannes 21:15-17

Jeg har så vondt i mvn JavaBin, 10. mars, 2011 Johannes Brodwall

Effective Enterprise Java Johannes Brodwall Chief scientist, Steria Norway

Going to Sri Lanka Miles Johannes Brodwall, Chief scientist Exilesoft Global

Effective Enterprise Java Johannes Brodwall Chief scientist, Steria Norway