The document discusses the importance of agile practices beyond just implementing Scrum, highlighting the need for developers to adopt best practices such as pair programming, test-driven development, and continuous integration. It critiques the concept of 'flaccid Scrum,' where organizations fail to fully embrace agile principles, emphasizing the need for co-location, verbal communication, and proper tooling. The author stresses the importance of sustainable coding practices and hiring the right talent to foster an effective agile environment.

1. Scrum is not enough:
being an Agile engineer
Anton Keks
anton@codeborne.com
Agile Days Moscow, 4.03.2011

2. Anton Keks
Co-founder of
Lecturer at Tallinn Technical University
Member of the board of Agile Estonia
●
Author of Angry IP Scanner
Strong believer in
Agile and Open-source
2

3. Iterative &
Incremental
NOT Big-Bang

4. Adaptable
NOT Predictable

5. Teamwork
NOT Lone Ranger

6. Testing
NOT Praying

7. Simplicity
Maximizing the amount of work not done

8. Scrum
● Nowadays, Agile is more popular than
Waterfall
● 84% of Agile organizations are doing
Scrum
●
Only 50% of them are doing iterations
● Even fewer use developers' practices
● “Flaccid Scrum”

9. ?

10. The good stuff
!
Co-location
Verbal communication
Continuous improvement
Working increment of the
software

11. But can code cowboys
actually do this?

12. Or even worse,
bureaucrats?

13. Top-Down Adoption

14. Ken Schwaber left Scrum Alliance
to work on the
Professional Scrum Developer program

15. Thinking
Coding
Guessing
Patching
WTF

16. in e
pr
a ct
ipl
ic
is c
es
=
=d
Developers need tools to perform in
an agile environment

17. Mejores prácticas
● Simplicidad (No se va a necesitar)
● Programación en pareja
● Propiedad del código compartida
●
Pruebas unitarias
●
Desarrollo basado en pruebas
●
Pruebas de aceptación automáticas
●
Construyes y lanzamientos repetibles
●
Integración continua

18. Mejores prácticas
Best practices
● Simplicidad (No se va a necesitar)
Simplicity (YAGNI)
● Pair programming
Programación en pareja
● Collective code ownership
Propiedad del código compartida
●
Unit tests
Pruebas unitarias
●
Test-driven development (TDD)
Desarrollo basado en pruebas
●
Automated acceptance tests
Pruebas de aceptación automáticas
●
Repeatable builds & releases
Construyes y lanzamientos repetibles
●
Continuous continua
Integración integration

19. Swedbank
● The major bank in Baltics and Scandinavia
● Agile since 2005
● Started with XP (bottom-up)
●
Voted the best Internet Bank in Europe

20. Productivity
● Decent version control
● Master your IDE
● One-click builds
●
DRY – Don't repeat yourself
●
Script any repetitive tasks

21. Avoid hopeless meetings

22. Unit tests
●
Standardize!
●
Continuous integration
●
Keep them “unit”
● Keep track of coverage %
●
Never let it fall!

23. Measuring
You get what you measure

24. Vertical development
●
Every user story must be vertical
= independently add value
= potentially shippable
●
Strictly story-based development
Never add a button to the UI that
does nothing yet!

25. The Truck Factor
● Avoid overspecialization
●
Collective code ownership
●
Coding standards
● TEX* meetings
* TEX = Technology EXchange

26. Pair programming
TDD - Ping pong – Concentration - Quality

27. Software Design vs
Architecture
●
Software design is the structure of code
and relations between its elements
● Software architecture is the same as
software design, but used when people
want to make it look important
(after Martin Fowler)
– Architecture is the part of design that is
difficult to change
– Therefore it is undesired :-) 27

28. Design vs Construction
● In civil and mechanical engineering
– Cost distribution ~ 10% / 90%
– Design: intelligently skilled, creative
people
– Construction: manually skilled
● In software ~ 100% / 0% distribution!
– Code is the design, not UML, etc
– Construction: compilation, builds, etc –
almost free 28

29. Sustainable pace

30. Software
Craftsmanship

31. http://manifesto.softwarecraftsmanship.org

32. ...the Codeborne way
Software
Craftsmanship...

33. O N AL
ESSI
ROF
UN P

34. Heavyweight
Lightweight

35. Complex
Simple

36. The order of adoption
●
Coding standard
●
Unit tests
● Continuous integration (+ bells and whistles)
● Collective code ownership
● Pair programming
● TDD
●
Automated acceptance tests

37. And don't forget paying the
Technical debt

38. The “easy” way
Hire the right people!
“hire for attitude, train for skills”
Anton Keks, anton@codeborne.com