The document provides an overview of Agile Engineering Practices (AEP), detailing its various aspects and how they can be implemented in Agile teams. It outlines both entry and expert levels of understanding, emphasizing best practices like continuous integration, test-driven development, and collective code ownership. The document also highlights Agile42's training and coaching methods to facilitate the adoption of AEP.

1. Presentation of
Agile Engineering Practices
Overview of the different aspects of agile engineering practices (AEP)
and how they can be adopted in agile teams
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

2. About us
Niels Verdonk Roberto Bettazzoni
eXtreme programming Trainers
niels.verdonk@agile42.nl
linkedin.com/in/nverdo
@nverdo
Agile Coaches
roberto.bettazzoni@agile42.it
linkedin.com/in/robertobettazzoni
@bettazzoni
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

3. Presentation of Agile Engineering Practices
• Introduction
• Presentation of the level of knowledge
• Presentation of Agile Engineering Practices
• Presentation on our way to approach these practices
• Explanation of two different activities happened in Siemens
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

4. A.E.P. entry level
Personal point of view:
• your production code is tested (in some ways)
• you can test your code (in some way)
• you can access and understand all the part of the project of your competence
• you can repeat the building of any version of your project
• you can do and undo any modification to the code of your competence
Project point of view:
• The product is tested (in some way)
• The production code is tested (in some ways)
• The contents of any releases is known
• Any releases can be re-build
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

5. eXtreme Programming practices
Sit Together
Whole Team
Informative Workspace
Energized Work
Weekly Cycle
Quarterly Cycle
Slack
User Stories
Pair Programming
Refactoring
Ten Minute Build
Continuous Integration
T.D.D. (was Test first)
Incremental Design
font: Extreme Programming Explained: Embrace Change 2nd Ed. (2004)
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

6. eXtreme Programming practices
Sit Together
Whole Team
Informative Workspace
Energized Work
Weekly Cycle
Quarterly Cycle
Slack
User Stories
Pair Programming
Refactoring
Ten Minute Build
Continuous Integration
T.D.D. (was Test first)
Incremental Design
AEP
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

7. A.E.P. expert level
Personal point of view
•You produce code that is working as expected, easily readable and properly tested.
•You know your project[s]. You can modify any part that concern your skills and you can overview the
entire project to a new member
•You have a basic understanding of the Software Build, Unit Test and Continuous Integration tools and you
can explain it to a new team member using shared lectures or pair programming
Project point of view
•There are Acceptance Tests created for any new US completed
•The successful build implies the successful run of all the tests of the project (Unit, Functional, Acceptance)
•The build are completely automated. The tests that can be automated are completely automated. Both
are under Continuous Integration.
•Collective code ownership: no procedure or access restrict or limits changes to the code, so every coder
could understand and change any part of the project. In this way no person or group of people could
become a bottleneck.
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

8. AEP an overview
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

9. Agile42 way to facilitate application of AEP
• presentations
• trainings
class training
dojo
workshop
• mentoring
• coaching
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

10. Some training examples
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

11. Hot topic on “Pair Training”
1hour, 10-20 participants - presentation - 4C schema
Agenda
• Guess 3 pair training or coaching characteristics. (C1: connection activity)
• Pair Training and Coaching (C2: concept)
• Pair Programming references (C2: concept)
• Pair Story Writing (C3: Concrete practice. Activity)
• Share your opinion (C4: Conclusion)
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

12. Unit test Awareness Dojo in C#
3 hours 6-12 participants
Agenda
• Unit Test in a very small nutshell
• The Dojo rules
• Unit Tests demo
• 1st round on Kata (25 min.)
• 2nd round on Kata (25 min.)
• Code sharing
• Retrospective
agile42 | We advise, train and coach companies building software | www.agile42.com | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License