Agile Software Development in
Practice – A Developer
Perspective
Weerasak Witthawaskul
Mr. Sweet Corn
29 August 2009

Companies' Most Important Assets
Employees = You
Current Treatments
More workload /
documentation
= More stresses, High
turnover, Low quality
work
Happy, talented,
empowered, passionate
employees = productive

To Agile, or Not to Agile

What? You are still not an agile
developer?
 Agile will make you
more, if not most,
productive
 Don't do things that do
not help make working
software
 No more repeated bugs
 Agile is about organizational transformation
 Try Scrum for project management
 Try XP for design, develop and test

Pick 3 out of 4
Deadline
Scope Budget
Quality

Agile Practices
 User Stories
 Iteration Planning Meeting
 Daily Stand-up Meeting
 Retrospective
 TDD
 Refactoring
 Continuous Integration

User Story Stack

Scrum in Theory

Scrum in Practice

Card Wall
Ready In Dev In BA In QA Ready for
for Dev Business

Release and Iteration Plannings
Daily Standup
Release 1 Planning
IPM 1
End of Iteration 1
Retrospective
IPM 2 End of Iteration 2
Retrospective
Release 2 Planning
IPM 3 End of Iteration 3
Release 1 Retrospective
IPM 4
IPM = Iteration Planning Meeting

Iteration Planning
 Review vision and roadmap
 Review development status from previous
iterations
 Demo of previous iterations
 Review team availability & capacity
 Review product backlog & select items for
iteration
 Identify tasks & estimates
 Commit

Productive Scrum
 Time management is crucial
 All roles must be identified
 Business / PM / BA / Tech Lead / Dev / QA
 Onsite team is most desirable
 Be concise and direct
 Trust that everybody does the best job possible
given context and timeframe
 Daily or on-demand group huddle
 Use simplest tools possible

Measurements
 Frequent releases of working software
 Iteration Velocity
 Repeated Defects
 Team productivity / morale / happiness

Eternal Engineering Sunshine of
the Spotless Minds
 We tend to overengineer design...
 Lets do the Strategy pattern when there is only one
algorithm
 Lets use the Observer pattern when there is only
one observable and one observer
 Lets use this because in the future...
 I have beautiful diagrams of the system; don't
change it
 Aim for 100% test coverage

XP is for...

eXtreme Programming (XP)
Move People 100%
CRC Around
Cards Unit
Change We Tests
Simple Pair Need
Help Passed
Design
Complex
Problem Run All Unit
Failed Tests
Unit New Unit
Next Task Create Test Pair Tests
Or Failed Programming Continuous
a Unit Integration
Acceptance Test Passed New
Test Unit Functionality
Simple Complex
Code Code
Refactor Acceptance
Mercilessly Test
Passed
Copyright 200 J. D. Wells
Collective Code Ownership

Pair Programming
 Pairing Matrix
Developer Dev A Dev B Dev C Dev D
Dev A Monday Tuesday Wednesday
Dev B Monday Wednesday Thursday
Dev C Tuesday Wednesday Friday
Dev D Wednesday Thursday Friday
 Ping Pong Programming

Test Driven Development
 New Project
 Help you shape your design from the caller point of
view
 Set of tests (test suite) become assets
 Reengineering Project
 Help you understand existing implementation by
writing test coverage of existing code
 Ensure that your refactored code and new code do
not break tests

Three Rules of TDD Fight Club

Three Rules of Fight Club TDD
 You are not allowed to write any production
code unless it is to make a failing unit test pass.
 You are not allowed to write any more of a unit
test than is sufficient to fail; and compilation
failures are failures.
 You are not allowed to write any more
production code than is sufficient to pass the
one failing unit test.

Typical Coding
 Understand user accpetance criterias in
each user story
 Write functional tests for each criteria
 They will fail
 For each functional test
 Write unit tests for controllers
 Think about what should be in controllers, what
should be abstracted into models
 Write unit tests for models
 Write code to make tests pass

Test Double
 Use Stubs / Mocks
 Stubbing things you
don't want to test but
are necessary
 Mocking things you
expect some
behaviors
 Examples?

Level of Tests
 Unit tests
 One class; stubs the rest
 Functional tests
 Groups of classes; use fixtures as test data
 External tests
 External service dependencies; may fail if
external services are unavailable
 Integration tests; User acceptance tests
 End-to-end tests
 Webapp tests from web browser

Testing Styles
 Assertion is so '90s
assert_equals(”must be empty”, message, ””)
 Behavior Drien Design (BDD)
message.should == ””
 Test name prefixed is for grandpa
void testMessageMustBeEmpty() { … }
 Use annotation
[test]
void messageMustBeEmpty() { … }

BDD
 We describe something that it must behave …
describe ”user login” do
it ”must not allow user login without password” do
… password.should_not be_nil ...
end
it ”checks password from the user id” do
… user.valid?(password).should == true ...
end
end

BDD and User Stories
 Story n
As a …stakeholder...
I want to …goal...
so that …reason/business value...
 Scenario m
Given …context...
When ...event...
Then ...expectation...

From User Story to Implementation Demo
Story 1
Title: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.

Demo – ATM Withdrawal
Scenario 1: Account is in credit Scenario 2: Account is overdrawn past
the overdraft limit
Given the account is in credit
Given the account is overdrawn
And the card is valid And the card is valid
And the dispenser contains cash When the customer requests cash
Then ensure a rejection message is
When the customer requests cash displayed
Then ensure the account is debited And ensure cash is not dispensed
And ensure the card is returned
And ensure cash is dispensed
And ensure the card is returned

Spec-first Design – User/BA pairing

BA / Dev Pairing
Dev Pairing

Test / Code / Test Cycle
Dev done when we see all dots
With nested option, test result
becomes documentation

Checkin Messages as Documents
 Instead of
 svn ci -m ”fixing bugs”
 Try
 svn ci -m ”[jira 1234] Boat/Pok – Checked null
pointers of cart.items before accessing each item”
 Why?
 svn log | grep -i -C 3 pok | less
 svn log | grep -i -C 3 cart | less
 Bug tracking tool integration

Continuous Integration
Builder Server 2
Builder Server 1
VCS
Check-in

Tools
 User Stories
 Index cards
 User Story Tracking – Card Wall
 Whiteboard
 Mingle
 VCS
 Subversion / Git
 Bug Tracking
 Jira / Bugzilla

Testing Libraries / Tools
 Mockito – Java
 rSpec DSL – Ruby
 Selenium/Watir – Web
UAT

Presentation Summary
 No more excuse not to do agile
 If you can't go full-stream agile, consider
gradually applying agile practices
 Self-discipline, don't do shortcuts, i.e. always
test first. You will thank yourself later.
 There is no 'i' in Teamwork; develop soft skills
to work effectively with others

Keep Learning
 Self Study – Keep up with technololgy
 Software Craftmanship: Apprenticing
 Higher Education

Towards Agile Manifesto – Thai Edition

Now You Have Questions
Time to Ask!
 Agile 2009 http://www.agile2009.org/
 Martin Fowler Bliki http://martinfowler.com/bliki/
 Agile Consulting
http://agileconsulting.blogspot.com/
 Planet ThoughtWorks
http://blogs.thoughtworks.com/