Presentation by saurabh chandra
- 1. Mantra for Innovative Project Management Saurabh Chandra Associate Consultant Tata Consultancy Services Limited
- 2. Title of the Paper:AGILE way forward - Agile based execution for a Research Commercialization Program Theme:Mantra for Innovative Project Management Keywords:Agile, Project Management, SDLC, Execution, Methodology Abstract Prior to introducing Agile methodology to our Program, we faced following typical problems characteristic of any project/program: a) Frequent change in course of delivery and delivery targets, due to unplanned business imperatives like customer demand for a solution, urgent enhancement requests to the deployed system from the field operations team etc. b) 50% Time spent on Requirements and Design, as the team aimed to deliver the right feature with right design the very first time c) Unplanned and untracked work for many team members d) General confusion and chaos on what next? e) Some of the project team and delivery issues were escalated to the Senior Management. In this paper, we describe the benefits we have reaped by following the Agile methodology for our product - an innovation by TCS that is undergoing commercialization. Our excitement with Agile is not incidental. If applied well, the key benefits can be summarized as below: 1. Plan for team to work upon upfront for a month 2. Business has a handle on what is getting built and how it’s getting built 3. Early feedback through weekly demo 4. Well documented execution plan and complete transparency to all stakeholders 5. Sprint issues and corrective action ascertained during timely status updates 6. All stakeholders play their role perfectly 7. Delivery on time always 8. Quality being built as per process of demos – what is broken will be apparent
- 3. Table of Contents Contents Introduction .......................................................................................................................................4 Main body of the paper: The Solution - Agile way forward ....................................................................4 Pre-requisites for our Agile Implementation.........................................................................................4 Senior Management buy-in and guidance.........................................................................................4 Articulation of benefits to the Business Team ...................................................................................5 Planning and availability of User Stories (Backlog).............................................................................5 Agile in Motion ...................................................................................................................................6 The Method....................................................................................................................................6 Key Artifacts ...................................................................................................................................6 Sprint Metrics.....................................................................................................................................7 FIGURES .............................................................................................................................................8 Fig 1: Snapshot of Backlog - User Stories, Plan and Tracking ..............................................................8 Fig 2: Share Point Site for our ‘Agile Corner’ .....................................................................................8 Fig 3: Sprint-2 Artifacts on our ‘Agile Corner’ ....................................................................................8 Conclusion: Key Benefits of Agile .........................................................................................................9 Quotes from the Team ....................................................................................................................9 Acknowledgement..............................................................................................................................9 References ....................................................................................................................................... 10
- 4. Introduction Prior to introducing Agile methodology to our Program, we faced following typical problems characteristic of any project/program: a) Frequent change in course of delivery and delivery targets, due to unplanned business imperatives like customer demand for a solution, urgent enhancement requests to the deployed system from the field operations team etc. b) 50% Time spent on Requirements and Design, as the team aimed to deliver the right feature with right design the very first time. This is true of a volatile product requirements and design paradigm. The Requirements and Design were discussed and finalized before development began, instead of clean feature based user-stories which broke the requirements in tangible components. c) General confusion and chaos on what next to do? Uncertainty in response from Business Stakeholders. d) Unplanned and untracked work for many team members – general chaos and crisis led to lack of focus on delivery and side-tracking of actual work to be accomplished by team and tracked by the management. e) Lack of transparency in Delivery Team’s capability and operations leading to over expectation or frustration by Business and Management. f) Some of the project team and delivery issues were escalated to the Senior Management by Business. Main body of the paper: The Solution - Agile way forward With the help of our Senior Management, we took stock and undertook an improvement journey, making fundamental changes in the way we planned and operated our product roadmap and delivery. We adopted ‘AGILE’. Pre-requisites for our Agile Implementation Senior Management buy-in and guidance Senior Management was more than happy to introduce the ‘Agile’ way forward, in view of the problems pointed out. They also deputed a ‘Coach’ to the team. As the coach took over the main problems faced by the team, he articulated the problem and laid the ground-rules for the team to follow. We discussed the following principles guiding us for future deliveries in our journey in 'going' the Agile way: 1. Create User Stories - as requirements. 2. Over time, we should build a 'Backlog'.
- 5. 3. Use 'Priority' settings to choose work to do in a given SPRINT (Development cycle). 4. Execute each user story / requirement completely before taking up another. 5. Re-factor at regular intervals to improve code-base. 6. Develop in fixed development cycles (SPRINTs). 7. Estimation of User Stories based on similar stories executed in the past. 8. Design document and Test cases to be done simultaneously with the development. 9. Demo the developed software periodically. 10. Do not extend the end date for any reason. The business and delivery team had been briefed and agreed to adopting these principles. We published the Backlog and Status Tracking updates on our organizational Share Point based knowledge repository to track and monitor transparently. The link to the repository was published to all relevant stakeholders including Senior Management and the development team. Articulation of benefits to the Business Team After we planned and delivered few Sprints using the Agile Methodology, following benefits to the business were apparent: 1. Completion of pre-defined backlog, prioritized by business, dot on the pre-defined delivery date 2. Complete transparency on the business deliverable and development through weekly demos on Monday evenings. Feedback by business was recorded and incorporated subsequentl y and demoed on next Monday. 3. Transparency on who is doing what and tracking it to closure – Issues if any, were discussed upfront in tri-weekly status update meetings: on Monday, Wednesday and Friday. 4. The Sprint plan contained it all! - From which developer is working on which User Story, to the estimate in Person Days (PDs), and the plan of delivery in terms of development planned start date and end date. 5. Actuals against plan were tracked with actual start date, end date and percentage work remaining. Planning and availability of User Stories (Backlog) The business team including the Business Analysts became the source of compilation of User Stories for the Product and Sprint Backlog. The User Stories backlog was compiled for a long time to come. The business team also prioritized what will be build first.
- 6. Agile in Motion The Method Following are the notes for the execution method of Agile for our Program: 1. Monthly Sprints were planned with a definite backlog, pre-determined, before the start of the Sprint. The business team had documented the User Stories and prioritized them too. 2. During a Sprint, estimates were done by the Project Manager along with the technical leads, based on similar user stories, built in the past. Developers were assigned from Web-Console, Mobile and IVR teams and start and end dates were planned, for each user story. 3. For tracking Actuals against plan were tracked with actual start date, end date and percentage work remaining. 4. Design and Test documentation was done parallel during the execution of the Sprint. This helped as at the end of the Sprint we had documentation available for Design and Testing could be done as documented. 5. Demo was held every Monday of the week, for one hour in the evening, for demonstration of the user stories built by the development team and obtains feedback from the business. Feedback by business was recorded and incorporated subsequently and demoed on next Monday. 6. Weekly status meetings were held on each Monday, Wednesday and Friday for 45 Minutes, between all stakeholders. 7. In a variation to point#6, when the process got established, we started to have daily SCRUM meetings of the delivery team. Key Artifacts The key artifacts to be delivered in a Sprint were as follows: 1. Product - BACK LOG – containing the overall backlog as arrived at by the business team for the Product. 2. SPRINT X - BACK LOG - Estimates and Plan – containing the estimates and plan for the SPRINT X. 3. SPRINT X – Design Document - developed by the Tech Leads for the SPRINT X. 4. SPRINT X – Test cases - developed by the Tech Leads and Testing team for Integration and System Testing. 5. SPRINT X – UAT Test Cases – As prepared by the Business team.
- 7. Sprint Metrics Below are some of the key Sprint Metrics: Sprint Name Major Features No of User Stories Planned Person days Sprint-1 Crop Protocol 46 126 PD Sprint-2 Dynamic Surveys, Weather Forecast 41 120 PD Sprint-3 Technical Backlog 27 85 PD Sprint-4 Harvesting Module, Technical Backlog 41 64 PD The above table shows the actual number of user stories completed in the Sprints. More than 40 functional user stories are completed in a month based Sprint. The team also did a Sprint on pure Technical Backlog, Sprint-3, with powerful technical features in the product, as the business was finalizing further user stories. The planned person days is showing a declining trend as some of the developers in the team have been released, incidentally.
- 8. FIGURES Fig 1: Snapshot of Backlog - User Stories,Plan and Tracking Fig 2: Share Point Site for our ‘Agile Corner’ Fig 3: Sprint-2 Artifacts on our ‘Agile Corner’
- 9. Conclusion: Key Benefits of Agile Our excitement with Agile is not incidental. If applied well, the key benefits can be summarized as below: 1. Plan for team to work upon upfront for a month – The Sprint Plan is done before the start of the Sprint, for duration of Sprint of a month. This means that the developers are clear on a daily basis what they need to do. 2. Business has a handle on what is getting built and how it’s getting built – The business has complete transparency on the Sprint Plan as well as prioritizes the backlog themselves. 3. Early feedback through weekly demo – This is very important as we get all stakeholders on board for a weekly demo on finished user story. This lets us track the status, gauge the velocity of the development and also gain feedback from the business on the development. Business can suggest changes and provide feedback. 4. Well documented execution plan and complete transparency to all stakeholders – The Sprint Plan is available to all from Senior Management, Business owner, Business team, Technical Leads, developers and testers. Everybody is involved in the demos. 5. Sprintissues and corrective action ascertained during timely status updates – any execution issues or improvements are ascertained and implemented during the status meeting. 6. All stakeholders play their role perfectly – With the establishment of the Agile method, the stakeholders: Business owner, Business team, Technical Leads, Developers and Testers – have an idea of the deliverables expected through them and discuss and work around these deliverables, in a focused manner. There no confusion as pointed out in the problem statement of this paper. 7. Delivery on time always – The Sprint timelines and delivery dates are fixed. Based on what we manage and achieve, customer is always assured of delivery on the particular date. This also meant infrastructure team’s deployment time was planned properly. 8. Quality being built as per process of demos – what is broken will be apparent; As the demos are held, we know where the code is broken and what needs to be fixed. Developers know they have to demo to all stakeholders, so they ensure proper testing to avoid embarrassment during the demo. Quotes from the Team "Using agile methodology, we are now reasonably sure of rolling out to the customer expectations." – Quote from the Business Owner “Agile way of working has paved path for systematic work environment -- Growth, Learning and utmost convenience in meeting customer's requirements and deadlines. ” – Quote from a developer in the team Acknowledgement
- 10. I thank Mr. K. Padmanabhan, Vice-President TCS-CTO and Mr. Srinivasu P, Head Agri-Business Initiatives at TCS for sponsoring the improvement in the project and Mr. A P Srinivas, Head Solutioning & Innovative Offerings, TCS-CTO for coaching us on Agile. References None