“We’re great at welcoming change but

suck at accommodating it”

The need for sound technical practices in Agile

Agile has gone mainstream

agile for the sake of agile

• sometimes users are not the consumers

• preachers and fanboys

• the cool kids are doing it

a lot about team and management practices

• largely by scrum

• people-focussed

• organizational practices

• technically agnostic

welcoming change

• “we add business value frequently”

• “we constantly re-prioritize our backlog”

• “we integrate customers into the team”

• “we always communicate”

• “we’re a cross-functional team”

welcoming change

the full picture

backlog code checkin QA releasebuild test UAT

accommodating change

• code changes

• database changes

• configuration changes

• infrastructure changes

• ...

welcoming vs. accommodating

welcoming changeiterative reqs, re-prioritizing backlogs, frequent

releases, customer feedback

accommodating changeiteratively and incrementally design, code, build,

test, integrate, release

why do we care?

• local optimization

• slower team

• sacrifice quality

• stress buildup

• ritualistic feel

solution

backlog code checkin QA releasebuild test UAT

need principles to drive practices

optimize holistically, not locally

principles

Working software over comprehensive documentation• how easy is it to create a shippable version of your

software?

• how do you know if your software is working?

• how do you even know what your software is supposed to do?

• how quickly can you get working software to the customer?

• how quickly do find out if your software is NOT working?

individuals and interactions over processes and tools

• how are your tech team members interacting with the rest of the team?

• developers

• QAs

• operations

practices

configmgmt

deploymentpractices

build practices

continuousintegration

code checkin QA releasebuild test UAT

emergent design

testing practices

change

you

get a grip on technical change

configuration management practices

version control

• check in everything

• single source of truth

• short and frequent checkins

• meaningful commit messages

environments

• environment configuration just as important as application configuration

• OS, database, additional s/w, services

• baseline to a known good state

• automate creation of environments

• standardize development environments

configmgmt

deploymentpractices

build practices

continuousintegration

code checkin QA releasebuild test UAT

emergent design

testing practices

build practiceshow quickly can you go from code to software?

build practices

• build from the command-line

• build from scratch

• idempotant process

• same build process across the team

• always build before checking in

configmgmt

deploymentpractices

build practices

continuousintegration

code checkin QA releasebuild test UAT

emergent design

testing practices

testing practiceshow do you know if your software is working?

class

component

complete solution

multi-faceted testing

class

component

complete solution

functional

integration

acceptance

unit

multi-faceted testing

test automation

• every change requires retesting

• prone to human error

• qa: less time doing exploratory testing

• dev: less confident about making changes

test automation

• design for testability

• idempotant

• use test patterns (e.g. mocks/stubs)

• lots of mature tools

• run with build

• as early and as often as possible

• boring and harder to “test-after” what’s already working

• learn in short cycles

• “free” regression tests

• exposes design flaws early

• forces you to think about details

• supports emergent design

tdd vs. test-after

configmgmt

deploymentpractices

build practices

continuousintegration

code checkin QA releasebuild test UAT

emergent design

testing practices

continuous integrationhow soon do you find out if your software is NOT

working?

• application not in working state for long periods of time

• cascade effect slows development down

• big-bang integration

• long-running branches

sporadic integration

continuousintegration

change

• goal: keep application in working state

• feedback on broken app:

• sooner

• more finely grained

• package app ready to ship

continuous integration

• build and test app on each checkin

• tag successful build

• store/version deployment artifacts

• deploy to sandbox environment on successful build

• notify team of broken or fixed build

continuous integration process

continuous integration enablers

• team ownership

• good configuration mgmt

• automated build

• ~ automated tests

• small and frequent checkins

• short build and test process

• some notification system

continuous integration practices

• don’t check in on broken build

• build and tests locally before committing

• wait for CI build to pass before moving on

• take responsibility for breaking the build

• never go home on a broken build

configmgmt

deploymentpractices

build practices

continuousintegration

code checkin QA releasebuild test UAT

emergent design

testing practices

continuous deploymenthow quickly can you get working software to the

customer?

automated deployment

automated deployment

• a lot of time spent on last mile

• ops and QA team waiting for “good” builds

• inconsistency of app across environments

• last-minute discoveries

• bugs, unmet CFRs

automated deployment

• pull system

• testers deploy specific version to testing environment at push of a button

• ops to staging and prod envs

• make end-to-end continuous delivery a reality

automated deployment enablers

• version deployment scripts

• build binaries only once

• same deployment process for all environments

• smoke test deployments

• deploy to copy of production (pre-prod)

• idempotant

• introduce incrementally

• devops = developers + operations

configmgmt

deploymentpractices

build practices

continuousintegration

code checkin QA releasebuild test UAT

emergent design

testing practices

Emergent Design

programming language

orm

platform

dbmsweb framework

idiomatic patternsclass

method algorithm

design patterns

Malleability

programming language

orm

platform

dbmsweb framework

idiomatic patternsclass

method algorithm

design patterns

Malleability

programming language

orm

platform

dbmsweb framework

idiomatic patternsclass

method algorithm

design patterns

DES

IGN

AR

CH

ITEC

TU

RE

emergent design

• opposite of BDUF

• discover vs. impose design

• form follows function

• design == code

• harvest idiomatic patterns

• avoid “rampant genericness”

emergent design enablers

• start with as little as you can

• avoid preconceptions

• test-drive the functionality

• refactor to simplify

• harvest idiomatic patterns

“Congratulations on having gained the ability to envision objects before you program. Take a moment to enjoy the feeling when it comes. Then knock it the hell off. Find the one piece of the vision that seems most compelling and do the least possible amount of that. Then bless and release the vision and get back to listening- to your code, your user, your partner, and yourself.”

- Kent Beck

Pair Programming

Collective code ownership

Refactoring