Download to read offline
Uploaded byDror Helper
Creating change from within - Agile Practitioners 2012
The document discusses the challenges of implementing Agile methodologies within a development team, sharing the author's personal experiences and strategies over a year and a half. Key topics include the importance of TDD (Test-Driven Development), effective code reviews, continuous integration, and the necessity of making incremental changes for long-term improvement. The author emphasizes a collaborative and positive approach to change, highlighting that successful Agile implementation requires team involvement and persistence.
More Related Content
Similar to Creating change from within - Agile Practitioners 2012
More from Dror Helper
Creating change from within - Agile Practitioners 2012
- 1. Creating change from within The Agile Developer story By Dror Helper
- 2. About.Me • Software Developer9+ years • Team’s technical lead • TDD/Unit testing enthusiast • Some SCRUM/Kanban background • Blogger – http://blog.drorhelper.com
- 3. The problem withAgile We don’t have time It would never work in this I don’t want to do this! project
- 4. So what cana single person do?
- 5. Let me tellyou about the last year and a half
- 6. The cast Manager Developer Developer Consultant Me
- 7. Team’s methodology • Unittests – more or less • Iteration tracking? • Manual deploy builds – from developer’s PC • Code reviews
- 8. My 1 st week on the job
- 9.
- 10. Analysis • Took twodays 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. Teach the team Anddecide on next steps
- 12. CI server Build Server What’s new? Commit There you go Source Control Build Agents
- 13. Immediate steps • Using MSTest • Write test before fixing bug • Fix existing tests when implementing new features • Delete obsolete tests
- 14.
- 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. 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. 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. How to decide what to do?
- 19. Total cost ofchange Participants Maintenance Effort (Time) Cost of Change Emotional Cost Value (Money) Previous investment
- 20. The most difficulttask Replace existing tool or Hard! methodology
- 21. Your knowledge What Subject domain you Gap know
- 22.
- 23.
- 24.
- 25. Excel in sharedfolder
- 26. TFS + Workitem manager
- 27.
- 28. The power ofcode reviews
- 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. Have the rightattitude • 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. Communicate! • Email • Phone call • Face to face • Presentation • Coder reviews • Pair programming • Daily meetings
- 32.
- 33. Enlist Help Because Youcannot do it all by yourself
- 34. Change is iterative •Hard to perform big changes overnight • Small incremental changes • Teach the team about the “boy scout rule”.
- 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. Journey not adestination
- 37.
- 38.
- 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.
Editor's Notes
- #10 We’ve started with sticky notes
- #12 Several lessons for the whole teamHow to write better testsMocking frameworksWhat is TDDAgree with the whole team on the next tasks
- #13 Now all of the tests must passNew tests have to runNew code have to be tested
- #23 We’ve started with sticky notes
- #24 We had nothing
- #25 Pros:High visibilityEasy to use and maintainCons:Statistics are not automatically createdNeed to go into the room
- #26 Pros:Can access from anywhereCan be sent in emailCons:Only one editor at a timeNeed to add statisticsNot automatic
- #29 Teach best practices – in the right contextTrack progressFind common issuesAlso pair programming – although I found that managers are more likely to
- #31 Don’t force – convinceIt’s ok to be wrong
- #37 Choose you short and long term goalsHave patienceDon’t burn out