This document discusses agile engineering practices used to develop software iteratively. It recommends practices like test-driven development, continuous integration, refactoring, collective code ownership, and pair programming. It emphasizes automating tests, keeping designs and documentation simple, evolving designs over time based on needs, and inspecting and adapting practices based on measurements and retrospectives. The goal is to deliver working software frequently that satisfies customers' needs.

1. Introduction to
Agile Engineering Practices
Yuval Yeret
Agile Coach @ Agilesparks
yuval@agilesparks.com
Mobile: 054-4802458

3. What’s missing?

4. What is technical debt?

8. Henrik Kniberg

9. Driving Force - Change

10. Iterate / Inspect & Adapt

12. BIG Features

13. Longer iterations?

15. Agile Architecture/Design
Prepare for
the future
Focus on the NOW /
Just in Time

16. Share the work
• Reach a Shared Understanding
• Courage to work outside comfort
zone
• Make it Easy to work anywhere in
the code

17. Continuous
Collective Code Coding Standards
Refactoring
Design Patterns
Ownership (CI)
Integration
Test Driven Design/Development
Pair Programming
Agile Testing

19. 45
41.33
40
35
31.03
30
% 25
Total
20
17.88
15
10
5.8
5
2.29
1.73
0
PSPsm XP Agile Scrum ISO9001 CMMI®

20. Next Steps
Learn more about the engineering practices. Ask your teams questions
that will engage them in this learning as well.
Evaluate how YOUR engineering practices/level are affecting your agile
environment
Pay attention to Technical Debt, Batch cost, knowledge silos as part of
your Inspect and Adapt cycle –
Leverage your Scrum retrospectives
Encourage teams to establish an engineering level backlog and assign
capacity to work on it.
Setup the right measures, communicate the right message.
Consider carefully whether to pick and choose practices or
adopt a methodology like Extreme Programming

21. XP and Scrum

22. Ask us how!
info@agilesparks.com
yuval@agilesparks.com
Get the slides at http://www.slideshare.net/yyeret/agile-eng-practices-
agilesparks-v2

23. Go on, Jump into the details!

24. Continuous Integration

25. Agile Testing
Cost per cycle should be minimal  Automate Automate Automate!!!
 Unit / Integration / Acceptance / Regression
Lean test documentation –
 Consider Exploratory Testing where applicable.
 Focus on outline, elaborate details verbally as you go, or trust testers to do
the right thing.
QA Measurements should drive Agile Testing
Minimize freeze/stabilization time
 Aim for shorter length, and consider it a maturity sign
 How?
• Maximize quality delivered for regular sprints
• Maximize efficiency of manual test work
• Did we mention Automate?

26. Test-Driven Development/Design
TDD is a method of designing software, not
merely an approach to testing.
Over a period of time, as a side effect, TDD
will lead to suite of automated unit tests.

27. Refactoring
 Refactoring increases
flexibility and the
product lifetime by
allowing and
encouraging
developers to change
the design of the
system as needed.
 Quality to market and
costs are reduced
because continuous
Refactoring keeps the
design from degrading
over time and thus
making it harder to
modify the product
correctly”

28. Design Patterns
 Knowledge
Management - Avoid
reinventing the wheel
 Improves Refactoring
/ TDD / Design
 Deciding when to use
– Experience/Skill of
professional
developers

29. Simplicity / Just in Time
Simplicity - the art of
maximizing the amount of
work not done - is essential.

30. How to evolve Design/Work
• Simple Design
• Design Patterns
• Agile Modeling

31. Simple Design
Start Simple
Evolve JUST IN TIME
YAGNI –
You Ain’t Going to Need it

32. Agile Modeling
 Just enough Modeling/Documentation
 Use the relevant model/artifact for the situation
 Only keep models you REALLY need to maintain.
Its ok to model and throw away later

33. Coding Standards
 Code must be formatted
to agreed coding
standards.
 Coding standards keep
the code consistent
and easy for the entire
team to read and
refactor.

34. Collective Ownership
Collective Code Ownership
encourages everyone to
contribute new ideas to all
segments of the project.
Any developer can change
any line of code to add
functionality, fix bugs, or
refactor. No one person
becomes a bottle neck for
changes.

35. Pair Programming
Two team
members
working on the
same code base
and working
side-by-side
(Also applicable
to tests/etc. – not
just code)

36. Pair Programming ROI

37. Pair Programming ROI

38. Pair Programming ROI

39. Pair Programming ROI

40. Pair Programming
 Very effective, if a good cultural fit for the team.
 Hard to adopt, mainly due to personal space and lack of
privacy issues, as well as individuality.
 Try and Buy - on writing User Stories, debugging of
difficult defects/code areas, for Code reviews of critical
production code, etc.

41. Iterate / Inspect & Adapt
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
Deliver working software frequently, from a
couple of weeks to a couple of
months, with a preference to the shorter
timescale.
BUT - iterating is HARD and expensive?