1. Implementing Agile
Do's and Don'ts
Anay Narendra Kamat
PresentSoft Technologies
http://www.presentsoft.co.in

2. Takeaway
• Learning from mistakes
• Confidence from success stories

3. All the teams and people mentioned in this
talk are real and as such, could resemble to
the people living or dead and the teams
existing in organizations.

4. The Prime Directive
Regardless of what we discover, we
understand and truly believe that everyone
did the best job they could, given what they
knew at the time, their skills and abilities, the
resources available, and the situation at hand.

5. Why to be Agile?

6. What does it take to be Agile?
Agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

7. Do perfectly agile teams really exist?

8. TEAM A
• BA formed the list of stories based on the requirements
given by the client only.
• PM managed the team without getting into micro-
management.
• Team provided and received updates during stand-ups.
• Every member of the team was allowed to
communicate with the client
• Dev followed PP, good design pattern, TDD and
Continuous Integration
• QAs used automation tools to run tests
• Deployment was automated as well

9. TEAM B
• Product owner had delegated the responsibility of
requirements and communication to one of his trusted
person
• BA formed the stories based on the requirements given
by the client only
• Only PM and BA were allowed to communicate with
the client
• Teams shared updates through stand-ups
• Team followed PP, good design patterns, TDD and CI
• QAs used automation tools
• Deployment was automated

10. TEAM C
• Team members had attended SCRUM trainings
• Each team managed the leave requests of their members
• Requirements/Stories were written by a different team
• Estimates were done in ideal days
• Duration of sprint was 3 weeks
• Long stand-ups
• Code reviews were done by members of another team.
• Team did not follow TDD, PP, CI
• QA members belonged to a different team
• Requirements changed frequently
• Team never delivered all the stories planned in the sprint.

11. TEAM D
• All the stories were written and updated in project management
tool directly by the client.
• Team relied heavily on email communication
• Only few senior members were allowed in client call updates
• Estimates were done in story points mapped to idea days
• Team did not follow TDD, code was completely procedural, CI was
not used
• Team members were divided in specialized groups
• QA members belonged to a different team
• Deployment procedure was separate for production and stage
environments
• Only few people were able to handle deployment activities on
production

12. TEAM E
• Client had no time to give or finalize requirements. BA had
to judge most of the requirements on his own.
• Only PM, BA and Architect was allowed to communicate
directly with the client
• Long stand-ups. Stand-up was driven by the Project
Manager.
• Development used to start for the stories which were not
completely defined
• Design decisions were taken completely by the architect
• No strict code reviews. OO was not followed since
management was of the opinion that it was too advanced
for the team members.

13. Quotes

14. Quotes
• It’s been 3 months since we started following scrum.
We don’t see any improvement, but situation has
definitely become worst – A team member
• On estimates done using story points over the scale of
2 - 3 - 5 - 8 (and 13), team of 12 people cannot achieve
velocity of more than 10 points – Scrum expert of one
organization
• Let’s start with the estimates, 2 point is for the story
taking 1.5 days, 3 point for the stories taking 4 days … –
A team lead from one organization
• We learnt a great thing. Remember it, and you can
implement in your next project . – PM

15. Do’s and Don’ts

16. Focus Areas
• Project planning
• Project management
• Development
• Quality analysis
• Documentation
• Skill enhancements

17. Project planning

18. Duration of sprint matters

19. Try to have high bus number

20. Have a story wall

21. Involve entire team in estimation
meetings

22. Follow continuous integration

23. Design the deployment strategy
well in advance.
• And make it scripted

24. Project management

25. Do not micro-manage
• Ensure that team understands the goal and
the big – picture and is not dependent on
stories.
• Be with the team

26. Encourage innovative ideas

27. Ensure learning from “Yesterday’s
weather” is implemented

28. Development

29. Do not design too much in detail

30. Reuse, Reuse and Reuse

31. Be responsible
• Ensure you are not breaking existing features
• Use automated unit tests. It helps a lot.
• Every feature needs to be “Deployable”

32. Quality analysis

33. Put efforts to understand real user
behavior

34. Reduce manual work through
automation tools
Encourage test automation right from the
beginning

35. Do not use “Number of defects
identified” as matrix to measure
QA effectiveness

36. Documentation

37. Documentation
• Prefer following over text based
documentation/comments:
– Automated Unit Tests
– Automated Functional Tests
– Deployment scripts
– Story description and discussions from project
management tool

38. Example : Using Cucumber

39. Skill enhancements

40. Skill enhancements
• Pair programming helps
• Encourage training within the team
• Encourage and reward implementation of
innovative ideas
• Discourage forming of specialized groups
within the team

41. Questions ……

42. Thank you
Contact
Email: anay@presentsoft.co.in
Twitter: http://twitter.com/kamatanay