The need for sound engineering practices in Agile. A look at a very common Agile anti-pattern (Flaccid Scrum) found in large organizations, and how to fix it.

1. “We’re great at
welcoming change but
suck at accommodating it”
The need for sound technical practices in Agile

2. Agile has gone mainstream

4. agile for the sake of agile
• sometimes users are not the consumers
• preachers and fanboys
• the cool kids are doing it

5. a lot about team and
management practices
• largely by scrum
• people-focussed
• organizational practices
• technically agnostic

6. 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”

7. welcoming change

8. the full picture
backlog code checkin QA releasebuild test UAT

9. accommodating change
• code changes
• database changes
• configuration changes
• infrastructure changes
• ...

10. welcoming vs.
accommodating
welcoming change
iterative reqs, re-prioritizing backlogs, frequent
releases, customer feedback
accommodating change
iteratively and incrementally design, code, build,
test, integrate, release

11. why do we care?
• local optimization
• slower team
• sacrifice quality
• stress buildup
• ritualistic feel

12. solution
backlog code checkin QA releasebuild test UAT
need principles to drive practices
optimize holistically, not locally

13. principles

14. 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?

15. individuals and interactions
over processes and tools
• how are your tech team members
interacting with the rest of the team?
• developers
• QAs
• operations

16. practices

17. config
mgmt
deployment
practices
build
practices
continuous
integration
code checkin QA releasebuild test UAT
emergent
design
testing practices

18. change
you
get a grip on technical
change

19. configuration management
practices

20. version control
• check in everything
• single source of truth
• short and frequent checkins
• meaningful commit messages

21. 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

22. config
mgmt
deployment
practices
build
practices
continuous
integration
code checkin QA releasebuild test UAT
emergent
design
testing practices

23. build practices
how quickly can you go from code to software?

24. build practices
• build from the command-line
• build from scratch
• idempotant process
• same build process across the team
• always build before checking in

25. config
mgmt
deployment
practices
build
practices
continuous
integration
code checkin QA releasebuild test UAT
emergent
design
testing practices

26. testing practices
how do you know if your software is working?

27. class
component
complete solution
multi-faceted testing

28. class
component
complete solution
functional
integration
acceptance
unit
multi-faceted testing

29. test automation
• every change requires retesting
• prone to human error
• qa: less time doing exploratory testing
• dev: less confident about making changes

30. 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

31. • 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

32. config
mgmt
deployment
practices
build
practices
continuous
integration
code checkin QA releasebuild test UAT
emergent
design
testing practices

33. continuous integration
how soon do you find out if your software is NOT
working?

34. • application not in working state for long
periods of time
• cascade effect slows development down
• big-bang integration
• long-running branches
sporadic integration

35. continuous
integration
change

36. • goal: keep application in working state
• feedback on broken app:
• sooner
• more finely grained
• package app ready to ship
continuous integration

37. • 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

38. continuous integration
enablers
• team ownership
• good configuration mgmt
• automated build
• ~ automated tests
• small and frequent checkins
• short build and test process
• some notification system

39. 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

40. config
mgmt
deployment
practices
build
practices
continuous
integration
code checkin QA releasebuild test UAT
emergent
design
testing practices

41. continuous deployment
how quickly can you get working software to the
customer?

42. automated deployment

43. 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

44. 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

45. 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

46. config
mgmt
deployment
practices
build
practices
continuous
integration
code checkin QA releasebuild test UAT
emergent
design
testing practices

47. Emergent Design

48. programming language
orm
platform
dbms
web framework
idiomatic patterns
class
method algorithm
design patterns

49. Malleability
programming language
orm
platform
dbms
web framework
idiomatic patterns
class
method algorithm
design patterns

50. Malleability
programming language
orm
platform
dbms
web framework
idiomatic patterns
class
method algorithm
design patterns
DESIGNARCHITECTURE

51. emergent design
• opposite of BDUF
• discover vs. impose design
• form follows function
• design == code
• harvest idiomatic patterns
• avoid “rampant genericness”

52. emergent design
enablers
• start with as little as you can
• avoid preconceptions
• test-drive the functionality
• refactor to simplify
• harvest idiomatic patterns

53. “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

54. Pair Programming

55. Collective code
ownership

56. Refactoring