Creating changefrom within The Agile Developer story By Dror Helper
About.Me• Software Developer 9+ years• Team’s technical lead• TDD/Unit testing enthusiast• Some SCRUM/Kanban background• B...
The problem with AgileWe don’t have time                     It would never                       work in this   I don’t w...
So what can a single    person do?
Let me tell you about the lastyear and a half
The cast                   ManagerDeveloper   Developer   Consultant   Me
Team’s methodology• Unit tests – more or less• Iteration tracking?• Manual deploy builds – from developer’s PC• Code reviews
My   1 st   week on the job
Let’s do TDD!
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 th...
Teach the teamAnd decide on next steps
CI server                      Build Server                           What’s new?Commit                          There you...
Immediate steps•   Using MSTest•   Write test before fixing bug•   Fix existing tests when implementing new features•   De...
Code reviews
Then came mocking• Hard to explain at the beginning• Instead show them!   o Free tools – low cost upfront   o Commercial p...
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…•   Th...
Today•   More than 3000 tests•   Good code coverage•   Most features are developed using TDD•   CI server run all tests on...
How to decide what to do?
Total cost of change                 Participants  Maintenance                   Effort (Time)                Cost of     ...
The most difficult task  Replaceexisting tool      or          Hard!methodology
Your knowledge               WhatSubjectdomain                you        Gap               know
Iterationtracking
In the beginning
Post-it + wall
Excel in shared folder
TFS + Work item manager
Tips and tricks
The power of code reviews
Effective Code reviews• Advise don’t force• Review the code not the person• It’s ok to discuss the good things as well• Yo...
Have the right attitude•   Be positive•   Don’t tell them what to so - suggest improvements•   Don’t force – convince•   B...
Communicate!•   Email•   Phone call•   Face to face•   Presentation•   Coder reviews•   Pair programming•   Daily meetings
Create success record
Enlist HelpBecause You cannot do it all by yourself
Change is iterative• Hard to perform big changes overnight• Small incremental changes• Teach the team about the “boy scout...
Be pragmatic!•   Every action should have a purpose•   If it doesn’t work – change it!•   Names are not important – just w...
Journey not a destination
Aftermath
Team growthopportunity/challenge
The end?•   TDD & unit tests•   CI server•   Code reviews before commit•   Automatic deployment•   Task board and iteratio...
Thank you
Upcoming SlideShare
Loading in …5
×

Creating change from within - Agile Practitioners 2012

395
-1

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
395
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • We’ve started with sticky notes
  • Several lessons for the whole teamHow to write better testsMocking frameworksWhat is TDDAgree with the whole team on the next tasks
  • Now all of the tests must passNew tests have to runNew code have to be tested
  • We’ve started with sticky notes
  • We had nothing
  • Pros:High visibilityEasy to use and maintainCons:Statistics are not automatically createdNeed to go into the room
  • Pros:Can access from anywhereCan be sent in emailCons:Only one editor at a timeNeed to add statisticsNot automatic
  • Teach best practices – in the right contextTrack progressFind common issuesAlso pair programming – although I found that managers are more likely to
  • Don’t force – convinceIt’s ok to be wrong
  • Choose you short and long term goalsHave patienceDon’t burn out
  • 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 – http://blog.drorhelper.com
    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

    ×