Scrum is not enough - being a successful agile engineer


Published on

The recipe for developers to perform in agile software development environment is to use technical practices, many of which are coming from XP.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Scrum is not enough - being a successful agile engineer

  1. 1. Scrum is not enough: being an Agile engineerAnton Agile Days Moscow, 4.03.2011
  2. 2. Anton Keks Co-founder ofLecturer 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. 3. Iterative &IncrementalNOT Big-Bang
  4. 4. Adaptable NOT Predictable
  5. 5. TeamworkNOT Lone Ranger
  6. 6. TestingNOT Praying
  7. 7. SimplicityMaximizing the amount of work not done
  8. 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. 9. ?
  10. 10. The good stuff! Co-location Verbal communication Continuous improvement Working increment of the software
  11. 11. But can code cowboys actually do this?
  12. 12. Or even worse,bureaucrats?
  13. 13. Top-Down Adoption
  14. 14. Ken Schwaber left Scrum Alliance to work on the Professional Scrum Developer program
  15. 15. Thinking CodingGuessing Patching WTF
  16. 16. in e pr a ct ipl ic is c es = =dDevelopers need tools to perform in an agile environment
  17. 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. 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. 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. 20. Productivity● Decent version control● Master your IDE● One-click builds● DRY – Dont repeat yourself● Script any repetitive tasks
  21. 21. Avoid hopeless meetings
  22. 22. Unit tests● Standardize!● Continuous integration● Keep them “unit”● Keep track of coverage % ● Never let it fall!
  23. 23. Measuring You get what you measure
  24. 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. 25. The Truck Factor ● Avoid overspecialization ● Collective code ownership ● Coding standards ● TEX* meetings * TEX = Technology EXchange
  26. 26. Pair programmingTDD - Ping pong – Concentration - Quality
  27. 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. 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. 29. Sustainable pace
  30. 30. SoftwareCraftsmanship
  31. 31.
  32. 32. ...the Codeborne waySoftwareCraftsmanship...
  33. 33. O N AL ESSI ROFUN P
  34. 34. HeavyweightLightweight
  35. 35. ComplexSimple
  36. 36. The order of adoption● Coding standard● Unit tests● Continuous integration (+ bells and whistles)● Collective code ownership● Pair programming● TDD● Automated acceptance tests
  37. 37. And dont forget paying the Technical debt
  38. 38. The “easy” wayHire the right people! “hire for attitude, train for skills” Anton Keks,