Agile Experience


Published on

Rama Krishna Pulivendla's presentation at Agile Goa 2007 conference.
This highlights Tech Mahindra's experience with Agile

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Experience

  1. 1. Case Study by Rama Krishna Pulivendla Agile Experiences
  2. 2. Agenda <ul><li>Introduction </li></ul><ul><li>Why we had to go in Agile way? </li></ul><ul><li>How the issues were addressed? </li></ul><ul><li>Team background </li></ul><ul><li>Agile Practices followed </li></ul><ul><li>Initial Issues </li></ul><ul><li>How did we overcome them? </li></ul><ul><li>Current state </li></ul><ul><li>Release planning </li></ul><ul><li>Iterative development </li></ul><ul><li>Daily Stand-ups </li></ul><ul><li>Retrospectives </li></ul><ul><li>User Stories </li></ul><ul><li>Pair Programming </li></ul><ul><li>Test Driven Development </li></ul><ul><li>Continuous Integration </li></ul>
  3. 3. Why we had to go in Agile way? <ul><li>Customer started seeing the changing scenarios and want the development team to adapt to the changing requirements and was not willing to renegotiate the schedule </li></ul><ul><ul><li>Results in team ramp up at a short notice and make the existing/senior team members spend long hours in the office to ensure that they complete the same </li></ul></ul><ul><li>Clarity of requirements </li></ul><ul><ul><li>Initially the customer may not be clear in explaining his requirements and needs a quick prototyping to get the look and feel </li></ul></ul><ul><ul><ul><li>Final decision may take its own time </li></ul></ul></ul><ul><ul><ul><ul><li>This affects schedule and increases cost for the customer as he has pay up for the delays caused from his end. </li></ul></ul></ul></ul><ul><li>Time line for delivery was long </li></ul><ul><li>Some times requirements use to be over taken by an event </li></ul><ul><li>Communication flow from the end user to developer </li></ul><ul><ul><li>Mismatch between user expectations and what has been delivered. </li></ul></ul><ul><li>Development of other interfacing modules going in parallel </li></ul><ul><ul><li>Customer may get what he has asked for but not useful till all the modules are complete. Adds to the cost for keeping the team intact </li></ul></ul><ul><li>Post Delivery Defects </li></ul><ul><li>Initial estimates going wrong and increase in efforts </li></ul><ul><ul><li>Explain the issues to the customer and try to negotiate on the contract </li></ul></ul><ul><ul><ul><li>May not be successful to renegotiate the contract </li></ul></ul></ul>
  4. 4. How the issues were addressed? <ul><li>Constant communication between the end user and the developer to minimize the communication gaps </li></ul><ul><ul><li>Clarity of requirements as explained by the customer </li></ul></ul><ul><ul><li>Requirements as understood by the developer </li></ul></ul><ul><li>Customer can see the early drops and can suggest enhancements, if required </li></ul><ul><ul><li>Customer is happy as working software is available </li></ul></ul><ul><ul><li>Easy to negotiate the contract for the enhancements </li></ul></ul><ul><li>Priority of which functionality is decided by the customer </li></ul><ul><ul><li>In line with the progress of the other modules </li></ul></ul><ul><ul><ul><li>Any issues in other modules, customer can re-prioritize the work stack. </li></ul></ul></ul><ul><li>Continuous integration helps in early detection of faults and reduces the post delivery defect density </li></ul>
  5. 5. Team Background <ul><li>PM and Developers are from waterfall model and never worked on Agile methodologies </li></ul><ul><li>In house training on Agile methodologies </li></ul><ul><li>Team was ready to adapt to Agile </li></ul><ul><li>Support from Senior Management </li></ul><ul><li>Willing customer </li></ul>
  6. 6. Agile Practices followed… <ul><li>Release planning/Hot house </li></ul><ul><li>Iterative Development </li></ul><ul><li>Daily stand-ups </li></ul><ul><li>Retrospectives </li></ul><ul><li>User Stories </li></ul><ul><li>Burn charts </li></ul><ul><li>Customer Collaboration </li></ul><ul><li>Automated testing </li></ul><ul><li>Continuous integration </li></ul><ul><li>Test Driven Development </li></ul><ul><li>Pair Programming </li></ul><ul><li>Product and Spring backlog </li></ul><ul><li>Value Stream Analysis </li></ul>
  7. 7. Initial Issues <ul><li>Releases once in two weeks (six iterations/release) </li></ul><ul><ul><li>Quickly getting in to the waterfall model </li></ul></ul><ul><li>Communication with the customer </li></ul><ul><ul><li>Updating progress and what’s coming up in the next delivery. Communication between the PM and the developer regarding assessing the progress and risk of not delivering. </li></ul></ul><ul><ul><ul><li>Tendency to stay late and complete the work but couldn’t sustain it for long. </li></ul></ul></ul><ul><ul><li>Requirement clarifications – Got into tendency that requirements are clear and there is no need to further talk to customer </li></ul></ul><ul><li>Reluctance for pair programming </li></ul><ul><ul><li>“I can work better when I am alone” </li></ul></ul><ul><ul><li>“Actual efforts” more than the “planned efforts” </li></ul></ul><ul><li>Missing the delivery date because the functionality is not complete </li></ul><ul><li>Code quality and rework on delivered functionality </li></ul><ul><li>Not recognizing the importance of Acceptance Test results </li></ul>
  8. 8. How did we overcome? <ul><li>Informal review of work at the end of the day in addition to scrum meeting every day morning, which is very focused on the activities. </li></ul><ul><ul><li>The purpose is to encourage team members to do better revised estimates so that the progress is shown correctly on the burn chart. </li></ul></ul><ul><li>Pair programming between “experts” and “novices” for ramping up the new team members quickly. </li></ul><ul><ul><li>Recognizing the importance of it and why it is required </li></ul></ul><ul><ul><li>After the initial resistance, team realized the importance of it </li></ul></ul><ul><li>Constant discussions with the customer (even if the requirements are clear) </li></ul><ul><ul><li>As soon as the developer picks up a user story, to call customer and verify the acceptance criteria </li></ul></ul><ul><ul><li>Discuss the possible changes to the screen </li></ul></ul><ul><li>Early demonstrations to ensure that the implementation is in sync with what customer is expecting. </li></ul><ul><li>Understanding the importance of AT results </li></ul><ul><ul><li>Failed AT is given highest priority to fix in comparison to the currently underdevelopment functionality </li></ul></ul>
  9. 9. Current State <ul><li>Project rated excellent in all the agile practices </li></ul><ul><li>Zero post delivery defect density </li></ul><ul><li>Satisfied customer </li></ul><ul><li>Helping customer in planning and prioritizing </li></ul>
  10. 10. Release Planning <ul><li>Release Plan </li></ul><ul><li>Prioritized requirements </li></ul><ul><li>New Product Backlog </li></ul><ul><li>Updated Wiki page </li></ul><ul><li>Retrospective of previous release (Day1) </li></ul><ul><li>Current Status of various functionality(Day1) </li></ul><ul><li>Discussion of new requirements(Day1) </li></ul><ul><li>Preparation of Index cards for new requirements with estimates (Day1) </li></ul><ul><li>Determining velocity (based on previous release)(Day2) </li></ul><ul><li>Prioritizing the user stories(Day2) </li></ul><ul><li>High Level Business Requirement </li></ul><ul><li>Current product backlog </li></ul><ul><li>Velocity from the previous release </li></ul>Outputs <ul><li>Customer Representative (s) </li></ul><ul><li>System Owner </li></ul><ul><li>Project Manager </li></ul><ul><li>Development team </li></ul><ul><li>Support representative </li></ul><ul><li>Testing team representative </li></ul>Project Manager Activities Inputs Participant Initiator/Driver 2 Days, every quarter Duration
  11. 11. Release Planning Game Backlog Prioritizing the Work Stack Final Work Stack
  12. 12. Iterative development <ul><li>Implementation </li></ul><ul><ul><li>Developers pick the user stories </li></ul></ul><ul><ul><ul><li>Only one user story per developer at any point of time </li></ul></ul></ul><ul><ul><li>Daily stand-up meetings </li></ul></ul><ul><ul><li>ATs run every night automatically. </li></ul></ul><ul><ul><li>Test Driven Development (TDD), Pair programming, Continuous testing by testers on the latest build </li></ul></ul><ul><ul><li>Communication with the customer about progress and requirements </li></ul></ul><ul><ul><li>2 weeks duration. Release candidate on second Thursday </li></ul></ul><ul><ul><li>Testing and sign-off by testing team on Friday </li></ul></ul><ul><ul><li>Deployment on Monday! </li></ul></ul>Iteration Planning Meeting: <ul><li>Updated wiki page </li></ul><ul><li>Setting the velocity for this iteration </li></ul><ul><li>Identifying the user stories and setting the priority for them. </li></ul><ul><li>Release Plan </li></ul><ul><li>Product Backlog </li></ul><ul><li>Velocity from the previous iteration </li></ul>Outputs <ul><li>Customer Representative </li></ul><ul><li>Project Manager </li></ul>Project Manager (Tech Mahindra) Activities Inputs Participants Initiator/Driver 30 Minutes, Telephonic call Duration
  13. 13. Daily Stand-ups <ul><li>Every day at 10AM. Duration 10-15 mins </li></ul><ul><li>Attended by all developers (unless on leave) and project manger/scrum master </li></ul><ul><li>What is discussed? </li></ul><ul><ul><li>What was done yesterday? </li></ul></ul><ul><ul><ul><li>Which user story working on? And paired with whom? </li></ul></ul></ul><ul><ul><ul><li>Acceptance Tests/JUNITs written for the functionality before starting coding – To be mentioned by both Primary and Secondary </li></ul></ul></ul><ul><ul><li>What is planned today? </li></ul></ul><ul><ul><ul><li>Functionality to cover that day </li></ul></ul></ul><ul><ul><ul><li>Discussions required with Customer (this is to plan the discussions) </li></ul></ul></ul><ul><ul><li>Issues faced </li></ul></ul><ul><ul><ul><li>Anything that stopped the developer from completing the previous day’s activities </li></ul></ul></ul><ul><ul><ul><li>Possible dependencies like clarifications required from customer etc. </li></ul></ul></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><ul><ul><li>Who is going to pair with whom? </li></ul></ul></ul>
  14. 14. Retrospectives <ul><li>Iteration Retrospective </li></ul><ul><ul><li>After the completion of iteration </li></ul></ul><ul><ul><li>Direct participation </li></ul></ul><ul><ul><ul><li>Developers </li></ul></ul></ul><ul><ul><ul><li>Testing team </li></ul></ul></ul><ul><ul><li>In direct participation (through mail) </li></ul></ul><ul><ul><ul><li>Customer </li></ul></ul></ul><ul><li>Release Retrospective </li></ul><ul><ul><li>During the Release planning meeting </li></ul></ul><ul><ul><li>Comments mainly from the customer </li></ul></ul><ul><li>What is discussed? </li></ul><ul><ul><li>What went well? </li></ul></ul><ul><ul><li>What could be better? </li></ul></ul><ul><ul><li>What we learnt? </li></ul></ul><ul><ul><li>What still puzzles us? </li></ul></ul>
  15. 15. User Stories <ul><li>Promise for Conversation with the user/customer </li></ul><ul><li>Index cards used to write the user stories. Contains the following </li></ul><ul><ul><li>User story description </li></ul></ul><ul><ul><li>Acceptance criteria </li></ul></ul><ul><ul><li>Estimate for implementing the user story </li></ul></ul><ul><li>Index cards are stuck on the white board during the iteration with following information </li></ul><ul><ul><li>Developer’s initials </li></ul></ul><ul><ul><li>Estimated hours of work </li></ul></ul><ul><ul><li>Hours of work spent so far </li></ul></ul><ul><ul><li>Remaining (estimated) hours of work – Information used for marking the burn down chart </li></ul></ul><ul><li>User stories are also mentioned on the WIKI page </li></ul><ul><ul><li>Status update by developers/testing team is done here. </li></ul></ul><ul><ul><ul><li>Developer </li></ul></ul></ul><ul><ul><ul><ul><li>Under development (developer name) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Ready for Test (build xxx) </li></ul></ul></ul></ul><ul><ul><ul><li>Tester </li></ul></ul></ul><ul><ul><ul><ul><li>Tested (build xxx) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Failed, if acceptance criteria is not met </li></ul></ul></ul></ul><ul><ul><ul><li>Visible to customer. </li></ul></ul></ul><ul><li>Burn charts are maintained both for the iteration and at the release level. </li></ul>
  16. 16. User Stories (Continued…) <ul><li>Splitting the major functionality to smaller user stories </li></ul><ul><ul><li>STATS Functionality </li></ul></ul><ul><ul><ul><li>Requirement was to provide various stats for the logs created by the user. </li></ul></ul></ul><ul><ul><ul><li>User wants stats to mailed on 1 st of the month and also stored in the application so that he can refer them </li></ul></ul></ul><ul><ul><ul><li>Scheduler and Email stats developed as per the user priority – Iteration 2 </li></ul></ul></ul><ul><ul><ul><li>Headline figures for Roaming stats, Details of stats developed – Iteration 3 </li></ul></ul></ul><ul><ul><ul><li>STATS viewer added on the main page so that the user can check the stats anytime – Iteration 4 </li></ul></ul></ul><ul><ul><ul><li>Further enhancements/changes to the display requested by the user after reviewing the functionality (priority as set by the user – Iteration 5 onwards) </li></ul></ul></ul>
  17. 17. Pair Programming <ul><li>Implementation of user stories is done in pairs. </li></ul><ul><li>No production code is checked in without a pair </li></ul><ul><li>Primary and Secondary </li></ul><ul><ul><li>Primary is the owner of a particular user story </li></ul></ul><ul><ul><li>Secondary provides a guidance, support and helps in implementation </li></ul></ul><ul><ul><li>Primary for a user story is constant, secondary is rotated </li></ul></ul><ul><li>Two pairing sessions per day </li></ul><ul><ul><li>First session primary and secondary swap roles for the second session. </li></ul></ul><ul><ul><li>User story 1 – X is primary and Y is secondary </li></ul></ul><ul><ul><li>User Story 2 – Y is primary and X is secondary </li></ul></ul><ul><li>Pairing Matrix is maintained to see how many times same pairs were together </li></ul><ul><li>No separate code review process </li></ul>
  18. 18. Charts
  19. 19. Test Driven Development <ul><li>The first activity once the developer picks up the user story is writing the Acceptance test and checking in the AT. </li></ul><ul><li>This is followed by the junits being written and then the code is written to pass the junits first and then the Acceptance tests </li></ul><ul><li>Secondary programmer ensures that the same are done before the development of code. </li></ul><ul><li>Same is verified by the “failed” test case appearing on the next day’s automated testing. </li></ul><ul><li>This is mentioned in the stand up meeting the next day by both primary and secondary </li></ul>
  20. 20. Continuous Integration <ul><li>Code is checked in after the implementation of the functionality as identified by the user story after synchronizing the code with the latest. </li></ul><ul><li>Merging is done after manually identifying the code changes to merge. </li></ul><ul><li>Once checked in, new build is made and all the junits are executed to ensure that nothing is broken in the existing functionality </li></ul><ul><li>One person checks in the code at a time and waits for the build to be made. Others wait till the build is complete before checking in their code. </li></ul><ul><li>Acceptance test suite is run the next day morning to ensure that the earlier delivered functionality is not broken. </li></ul><ul><li>Fixing of any acceptance test that has failed is given the highest priority (over any other activity) </li></ul>
  21. 21. <ul><li>Questions? </li></ul>
  22. 22. <ul><li>Thank You </li></ul>