Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Creating change from within - Agile Practitioners 2012


Published on

Faced with management that do not care about "being agile" what can a single developer do? Quite a lot!
Every developer has the power to improve the organization he works in in small iterative steps – and I can show you how.
If you want to make the change and don't know where to start – look no further, in this session I'll share my experience and show a few tips and tricks I learnt. As well as discuss the do and don'ts that can make all the.
- How to be agile developer in a waterfall company.
- Influencing people without formal authority.
- Using the right practices that makes the difference
- How to avoid alienating people
- Discovering your allies
- Know when to fight and when to "retreat" and cut your losses
- Making a change without disrupting the daily routine
- What being an agile evangelist is all about

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Creating change from within - Agile Practitioners 2012

  1. 1. Creating changefrom within The Agile Developer story By Dror Helper
  2. 2. About.Me• Software Developer 9+ years• Team’s technical lead• TDD/Unit testing enthusiast• Some SCRUM/Kanban background• Blogger –
  3. 3. The problem with AgileWe don’t have time It would never work in this I don’t want to do this! project
  4. 4. So what can a single person do?
  5. 5. Let me tell you about the lastyear and a half
  6. 6. The cast ManagerDeveloper Developer Consultant Me
  7. 7. Team’s methodology• Unit tests – more or less• Iteration tracking?• Manual deploy builds – from developer’s PC• Code reviews
  8. 8. My 1 st week on the job
  9. 9. Let’s do TDD!
  10. 10. Analysis• Took two days to fix 40% of tests and make all of the test run• Find what are the main issues – and focus on them o Not readable o Using logic inside test o Testing too much o Hand rolled mocks o Scenarios hiding as unit tests o Highly coupled code
  11. 11. Teach the teamAnd decide on next steps
  12. 12. CI server Build Server What’s new?Commit There you go Source Control Build Agents
  13. 13. Immediate steps• Using MSTest• Write test before fixing bug• Fix existing tests when implementing new features• Delete obsolete tests
  14. 14. Code reviews
  15. 15. Then came mocking• Hard to explain at the beginning• Instead show them! o Free tools – low cost upfront o Commercial products• Get rid of existing hand-rolled mocks
  16. 16. And excuses• “I didn’t have enough time so I didn’t write a test”• Crisis mode• I cannot test it – so I won’t…• There’s no need to test everything• It’s much better to have one big test• Remember not to be discouraged
  17. 17. Today• More than 3000 tests• Good code coverage• Most features are developed using TDD• CI server run all tests on commit• Change code without fear
  18. 18. How to decide what to do?
  19. 19. Total cost of change Participants Maintenance Effort (Time) Cost of Change Emotional Cost Value (Money) Previous investment
  20. 20. The most difficult task Replaceexisting tool or Hard!methodology
  21. 21. Your knowledge WhatSubjectdomain you Gap know
  22. 22. Iterationtracking
  23. 23. In the beginning
  24. 24. Post-it + wall
  25. 25. Excel in shared folder
  26. 26. TFS + Work item manager
  27. 27. Tips and tricks
  28. 28. The power of code reviews
  29. 29. Effective Code reviews• Advise don’t force• Review the code not the person• It’s ok to discuss the good things as well• You should get reviewed as well!• After a while team members can review each other
  30. 30. Have the right attitude• Be positive• Don’t tell them what to so - suggest improvements• Don’t force – convince• Be ready to change if proven wrong• Don’t be “that guy”
  31. 31. Communicate!• Email• Phone call• Face to face• Presentation• Coder reviews• Pair programming• Daily meetings
  32. 32. Create success record
  33. 33. Enlist HelpBecause You cannot do it all by yourself
  34. 34. Change is iterative• Hard to perform big changes overnight• Small incremental changes• Teach the team about the “boy scout rule”.
  35. 35. Be pragmatic!• Every action should have a purpose• If it doesn’t work – change it!• Names are not important – just what you do• Practices can be adapted for the team• Don’t be a strict task master Know where to draw the line
  36. 36. Journey not a destination
  37. 37. Aftermath
  38. 38. Team growthopportunity/challenge
  39. 39. The end?• TDD & unit tests• CI server• Code reviews before commit• Automatic deployment• Task board and iterations• Better estimations• Faster time to deploy
  40. 40. Thank you