Essential practices and thinking tools for Agile Adoption

1. Essential Thinking tools and
Practices for Agile Adoption
Steven Mak
Agile Coach
http://www.odd-e.com
steven@odd-e.com

2. About me and my job
Grow a productive team that thinks for itself
Change how they work and think, and very often
unlearn old habits
Guide the team through the tough patches until they find
their own way
So it’s about helping organisations adopting Agile

3. Today’s discussion
What is needed and difficulties in adopting Agile
Organisational and Engineering Practices
Thinking tools
How to begin with them

4. Do you enjoy this course?
So you have heard something about Agile software
development
Want to try it out?
Welcome to the reality!

5. You are not alone
Adelaide Bank Australia, Adobe Systems Seattle WA USA, Air New Zealand, APL ,
Ariba , b+m Informatik AG Melsdorf Germany, BBC New Media Dept London England
UK, Bentley Systems, BMC, Bose, CAN, CapitalOne, ClearChannel, Conchango,
Federal Reserve Bank, Ericsson, FormScape Fleet England U, French Post Office,
Gestalt, Google, HP, IBM, IDX, Intel, InterAct Public Safety Systems Asheville NC
USA, InterBusiness Technologies Curitiba/São Paulo PR/SP Brasil, Leapfrog, Online
Evanston IL USA, Lexis-Nexis, LMCO, Lockheed Martin, Medtronics, Microsoft,
Mobile Fun Limited Birmingham England UK, Motorola, Motorola Poland Cracow
Poland, Nokia, Nokia NET, Océ Netherlands, Philips, Primavera , Print Inc Bellevue
WA USA, Qpass/Amdocs Vienna Austria, Qualcomm San Diego CA USA, SAIC,
Sammy Studios, SAP, Security Benefit, Siemens, Siemens Austria, Siemens Medical,
Siemens Medical Solutions Malvern PA USA, Smith Seckman Reid, Inc. Nashville TN
USA, State Farm, State Street Bank, Sun, Symphony Services Corp. (India) Pvt. Ltd
Bangalore India, Telegraaf Media Group NV Amsterdam Netherlands, Trango
(Siemens) Toronto CAN, TransUnion, TrendMicro, Wildcard Systems, Xerox, Yahoo

6. Does this happen to your
organisation?
Sprint/Iteration requires a lot more work than was
planned
Team member reports the same item more than two
days with the same or greater estimates and nobody
notices or cares
No interaction outside (or even inside) daily stand-up
meeting
Customer/Product Owner not available for consultation
Distractions from outside the team

7. Does this happen to your
organisation? (more)
Single-Function groups
Individual performance evaluation and reward
Assumption that Book learning is enough
Silver bullet thinking or Cargo-Cult adoption
Culture of individual workers rather than teamwork
Gap between people in management roles and those
doing the hands-on work

8. Technical Debt
The sum of future maintenance that could have been
avoided if the software had been developed according
to reasonable software-design practices.
For example: Cut-and-paste coding
Other sources: design that lacks testability, inappropriate
coupling...

9. Cost of Change

10. Legacy systems
Doesn’t have test harnesses
Few people still know how to or are willing to touch it
Requires more time to work on

11. “Equally responsible for the initiation of project with
predefined failure is management that insists upon
having fixed commitments from programming
personnel prior to the latterʼs understanding what the
commitment are for. Too frequently, management does
not realize that in asking the staff for “the impossible”,
the staff will feel the obligation to respond out of
respect, fear or misguided loyalty. Saying “no” to the
boss frequently requires courage, political and
psychological wisdom, and business maturity that
comes with much experience.”
Charles Lecht -
“The Management of Computer Programming Projects” - 1967

12. Avoiding Technical Debt
Refactoring
Test-driven development
Acceptance test-driven development
Continuous Integration

13. Refactoring
Disciplined technique for restructuring an existing body
of code, altering its internal structure without changing
its external behaviour.
Small step each time
Protected by tests

14. Why Refactoring
Improve the design
Better understanding
Easier to add new code

15. Test-driven development
Use tests to drive the development/design
No production code is written before there is a failing
test
Not a testing technique

16. Test-driven development
1 Rule:
-
Only ever write code to fix a failing test
3 Steps:
1. Write a test (which fails “red”)
2. Code (to make test pass “green”)
3. Refactor (test still pass “green”)

17. Test-driven development
Cost of bug fixing is lower if it is found earlier
In 2008, Case Study of TDD at IBM and Microsoft
shows that TDDers enjoy a defect density reduction
ranging from 30% to 90% and a productivity cost of
between 15% and 35%
http://research.microsoft.com/en-us/projects/esm/
nagappan_tdd.pdf
Kent Beck: “If it doesn’t have to work, I can get it done a
lot faster!”

18. Test-driven development
Allow plenty of time for the team to pick up TDD
Think more during test, be pragmatic and quick to write
code
Shared commitment and working agreement
Try Coding Dojo
Try Ping-Pong programming

19. Acceptance TDD
Requirement Acceptance Test Feedback Implementation
Drive implementation of a requirement through a set of
automated, executable acceptance tests
It’s a whole team practice, not just developers

20. Examples, Tests, and Spec
Examples can become Tests
ela
rify
bo
ve
ra
te
Requirements

21. Acceptance TDD
Real-world examples to build a shared understanding of
the domain
Select a set of these examples to be a specification and
an acceptance test suite
Automate the verification of acceptance tests
Focus the software development effort on the acceptance
tests
Use the set of acceptance tests to facilitate discussion
about future change requests
Open Source tools, e.g. FIT, Robot Framework,
Cucumber

22. Acceptance TDD
•Implementation of tests
coding usually occur before the
testing code is done
• Feature not done until test
Feature
Specification architecture passes
Done
Workshop
customer documentation
other activities
• Activities happen in
parallel
Developers
Testers •Team clarifies and implement
Product Owner Example the feature together
Architect tests •Tests are executable at the
Technical writers end of the ATDD Workshop

23. Continuous Integration
Developer practice
To keep a working system
Small changes
Growing the system by integration at least daily
Supported by automated tests
Open Source tools, e.g. Hudson, Apache Gump,
Tinderbox

24. CI System
Check-in Monitor CI
SCM
Server
Compile
Email/SMS find out who Unit Test
“Fix the build” broke the build
Install /
any step failed? deploy
acceptance
test
any other
test

25. Facilitate Adoption
Evangelise - increase awareness
Lower the bar - quick path to the first success
Train and educate - from general training to specific needs
Share and infect - sit together and sharing sessions
Coach and facilitate - learn about yourselves and cope with the
findings
Involve others - know the stake-holder groups and give them roles

26. Organisational Assumptions
Self-management teams
Cross functional teams
Team incentives
Continuous improvement
Respect for people

27. Self-management teams
Higher motivation when the team is responsible for end-to-
end result.
The authority to design, plan, and execute their tasks
Leadership shared among team members
Autonomous
Cross-functional
Challenged - realistic goals
But you can’t start by simply asking the team “go self-
organise themselves”

28. Cross-Functional teams
Do your company still have a QA team?
Self-management teams are cross-functional, at working
level
“Group of people with a clear purpose representing a variety
of functions or disciplines in the organisation whose
combined efforts are necessary for achieving the team’s
purpose”
Global optimisation over local optimisation
Avoid creating queues and hand-off, reducing feedback loop
and hence decreasing learning opportunities

29. More about teams
Team owns the process, responsible for improving his
team’s work
Working agreements
Manage across their boundaries reaching out to find the
information they need, understand the context in which
they work, manage the politics and power struggles, get
support for their ideas
Dedicated team members and long-lived teams
Let the team make decisions

30. Team incentives
Paying solely on individual basis signals what the
organisation believes is actually important - individual
behaviour and performance
Avoid incentives on productivity measures,e.g. LOC
Avoid performance appraisals
Try “Go See” instead of annual review

31. Lean Thinking -
Continuous Improvement
Go See - go to the source and find the facts to make correct decisions,
build consensus, and achieve goals at our best speed
Kaizen - “my work is to do my work and to improve my work, and
continuously improve for its own sake”
Choose and practice techniques the team has agreed to try, until they
are fully understood
Experiment until you find a better way
repeat
Perfection challenge - high expectations beyond status quo

32. Lean Thinking -
Respect for People
Manager - teachers mentor people closely for years
Managers “Walk the Talk”
Teams and Individuals evolve their own practices and
improvements
Lots of formal education and coaching
Lots of coaching

33. More thinking tools
Systems Thinking
Queueing Theory
Theory of Constraints
Agile values is also a thinking tool
Software Craftsmanship Manifesto
Beyond Budgeting Movement

34. Good books to read - Agile

35. Good books to read - Technical

36. Good books to read - People

37. Extra
Certified Scrum Master Course
-
Tentatively in March 2010 - Hong Kong
Check out on http://www.odd-e.com and http://
www.scrumalliance.org/
S c r u m G u i d e h t t p : / / w w w. s c r u m a l l i a n c e . o r g /
resource_download/598
Scrum Primer http://www.goodagile.com/scrumprimer/
scrumprimer.pdf
http://tech.groups.yahoo.com/group/agilehongkong/
http://www.agilehongkong.com

38. Thank you
Steven Mak
http://www.odd-e.com
Email: steven@odd-e.com
Twitter: http://twitter.com/stevenmak