Your SlideShare is downloading. ×
Scrum is not enough - being a successful agile engineer
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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.

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Scrum is not enough: being an Agile engineerAnton Agile Days Moscow, 4.03.2011
  • 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. Iterative &IncrementalNOT Big-Bang
  • 4. Adaptable NOT Predictable
  • 5. TeamworkNOT Lone Ranger
  • 6. TestingNOT Praying
  • 7. SimplicityMaximizing 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 CodingGuessing Patching WTF
  • 16. in e pr a ct ipl ic is c es = =dDevelopers 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 – Dont 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 programmingTDD - 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. SoftwareCraftsmanship
  • 31.
  • 32. ...the Codeborne waySoftwareCraftsmanship...
  • 34. HeavyweightLightweight
  • 35. ComplexSimple
  • 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 dont forget paying the Technical debt
  • 38. The “easy” wayHire the right people! “hire for attitude, train for skills” Anton Keks,