Presentation is loading. Please wait.

Presentation is loading. Please wait.

® IBM Rational software © 2012 IBM Corporation A case study of Agile journey by a small software development team (2008-2011) Vivek K Gupta Engineering.

Similar presentations


Presentation on theme: "® IBM Rational software © 2012 IBM Corporation A case study of Agile journey by a small software development team (2008-2011) Vivek K Gupta Engineering."— Presentation transcript:

1 ® IBM Rational software © 2012 IBM Corporation A case study of Agile journey by a small software development team (2008-2011) Vivek K Gupta Engineering Manager – ISL Gurgaon

2 2 Team’s Charter And Products Characteristics  Support and enhance existing legacy tools  Develop Migration Tools for Legacy Products towards new Rational Tools  Applications Characteristics  CMVC: Defect Management and Version Control System  Server : C/C++, sql/c, AIX only, Clients : C, Java API, Java Swing, Eclipse RCP  BPS: Change Management Synchronization between CMVC and Retain  Server : Java RMI, Clients: Swing  eReview: Documentation Review  Server: Java RMI, Clients: Java Swing, Web Browser (Servlets, Struts 2, Dojo)  CMVC – RTC Connector : Migration and Sync tools between CMVC and RTC, RTC Java API  All Application Critical due to wide deployment and heavy usage  Fairly Stable Products especially the server code requiring lesser changes now

3 3 Incoming Work Trends

4 4 Work Management  Development Cycles  6 Months Fix Pack Release Cycles  Blockers resolved through Hot Fixes  Project Development and Tracking  Progress Tracking through Spread Sheets and emails  Testing  Manual Testing, Tracking and Reporting through spread sheets  Long Testing Cycles with each new build

5 5 About the Team and Its Challenges  Team Size = 9-12 (Dev and Test)  60%:< 2 Yrs Exp on the products  30%:2-4 Yrs Exp on the products  10 %:> 4 Yrs Exp  Challenges  Wide range of technologies with complex implementation  Requires long ramp up cycles, reduced overall work output  Defect fixing cycles requires more and more testing due to product stability  Human Resources  High Attrition attributed to  Low employee engagement’s due to continuous maintenance work  Little new learning opportunities  Lower productivity due to continuous learning cycles

6 6 Other Common Challenges  Too much time spent on status meeting  Difficult to know if someone is blocked until the meeting happens or follow up is done.  No History of Tasks  Revisiting of same issues again and again without much value add  No History of Tracking  Issues/Discussion around what was discussed and what was understood  Repetitive monotonous work  Leaves little bandwidth for improvement/learning opportunities

7 7 Introduction to Agile - Scrum -Continuous Integration -TDD - Testing Automation

8 8 Starting the Agile Journey  Backlog Analysis  Reducing Incoming Trends indicates that its possible to break 6 months fix pack cycles  Prioritized Backlog : Must Fix, Can be deferred, Nice to Have  Focus only on Must Fix defects, close the rest.  Team Goal Taken :  Break 6 monthly Fix Pack Release cycles to create bandwidth for other projects  Agile Practice Adopted  Scrum  Backlog Prioritization  Daily Scrum Meetings  No other changes Introduced

9 9 Results Q2 Q4Q2 Q1 Q4 Skipped one cycle 07 08 09 12 Q1 Allowed starting a new Project (CMVC-RTC Connector)

10 10 Scrum Benefits  Focus on delivering highest value in shortest time  Daily scrum meeting’s helped increase the team’s focus on common goal, resolve the issues faster and keep everyone updated on the state of the project  Backlog prioritization helped team to focus and address the major problem area’s first  Made bandwidth available to take up new tasks  Daily scrum is fine, but how do we efficiently :  Do Agile planning and Tracking  Track tasks efficiently  Track task history  Communicate and collaborate across the team  Report work progress transparently

11 11 Introducing Rational Team Concert – Jan 2009  Team advisor for defining / refining “rules” and enabling continuous improvement  Process enactment and enforcement  In-context collaboration enables team members to communicate in context of their work  Single structure for project related artifacts  World-class team on-boarding / offboarding including team membership, sub-teams and project inheritance  Role-based operational control for flexible definition of process and capabilities Jazz Team Server  Component based SCM enables reuse across projects  Change set based for easy addition or removal of features  Server-based sandboxes  Can also work with SVN, Git, ClearCase or Synergy SCMWork Items  Defects, enhancements and conversations  View and share query results  Support for approvals and discussions  Query editor interface  ClearQuest or Synergy Bridge  Automated Work item and change set traceability  Build definitions for team and personal builds  Local or remote build servers  Multi-level continuous integration  Integration with Build Forge Build Planning  Integrated release/iteration planning  Effort estimation & progress tracking taskboards  Out of the box process templates: formal or agile Project Transparency  Customizable web based dashboards  Real time metrics and reports  Project milestone tracking and status

12 12 Work Items Hierarchy Work Item Plan Structure Task Defect Epic/Use Case Story/Scenario Task Release 1.0 Story/Scenario Planned Items Execution Items Iteration 1 Iteration 2 We started using RTC for : Work items with custom attributes, tracking, and approvals Project tracking and status update on the dashboard History tracking, Daily Scrum Updates Impediment work items for instant help from the team

13 13

14 14

15 15 Custom Fields

16 16

17 17

18 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 26 Some Practices which worked for us best  Keep number of work items limited. Group similar topics into one work item and track the progress through updates in the description  Reduce triaging overheads  Reduce navigation overheads from one work item to other, have more quality content in each WI  Have just enough subscribers or limit no of subscription events. Too many updates can render them meaningless.  Encourage team members to :  Report problems/blockers as soon as they encounter them – someone else in the team might be able to help/provide direction  Document the technical details about the work done to serve as a reference for later use than just the status update  Enforce process controls gradually i.e. start making fields mandatory gradually based upon team’s confidence and acceptability to change.  Try centralizing information from disparate sources into one system  Its easy to migrate to RTC using the available migration tools or by extending the code  We migrated from multiple team rooms to RTC. –All artifacts (code, documents, task history, planning etc) centralized into a common placeholder

27 27 Results Achieved  Team as a whole felt productivity improvements of about 20%  Improved Team work and collaboration amongst team members.  Reduced meeting’s and status reporting/tracking overheads.  Better organized information structure.  Faster Ramp Up Time for members shifting from one project to another  Sense of accomplishment and belief that Agile practices do work  Increased motivation in the team to adopt other Agile practices  IBM’s Agile Experience ( https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537- 92ef-8982fc416138/entry/ibm_s_own_experiences_with_agile13?lang=en ) https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537- 92ef-8982fc416138/entry/ibm_s_own_experiences_with_agile13?lang=en  Join http://jazz.nethttp://jazz.net  Try RTC, RQM and RRC sandboxes  What’s Next should we adopt in Agile ?

28 IBM Software Group | Rational IBM Confidential28 Act Rapidly deploy tools, workflow and best practices An approach for continuous improvement in software delivery The Measured Capability Improvement Framework (MCIF) Steer Monitor progress, take corrective actions and measure business value Identify business goals and set priorities Assess

29 IBM Software Group | Rational IBM Confidential29 Assess – Set Priority Significant Repetitive Manual Efforts in Build and Testing due to lack of enough Automation

30 IBM Software Group | Rational IBM Confidential30 Addressing Testing Automation Problem  Challenges –No skills in the team for testing automation. Tight delivery schedules leave less scope for dedicated learning –How to address different testing challenges for different products Stand Alone product Testing One or More Clients for One Product Products Integration Testing  Different Clients for different products  Assess and Compare Intermediate results  Tools Deployed –Rational Functional Tester Java UI, Web UI, Java API & Command Line Testing

31 IBM Software Group | Rational IBM Confidential31 Practices which worked for us  Micro Learning –Spend maximum of 1 hour per day on learning –Split the topic’s amongst few team members who would Learn the information / Come up with solutions Share the learning’s across the team. –Team would prioritize the next set of topics for learning and implementation Focus on what’s needed, ignore the rest for later Implement a small portion / do POC and then move ahead

32 IBM Software Group | Rational IBM Confidential32  Automate Regression Testing First : –Alleviate Team from bulk of repetitive workload with lesser value –Help focus manual effort on new functionality.  Test tool sensitivity to rapidly changing user interface or network communication design –Avoid automated setup during 1.0 product development. Focus on manual execution. –Avoid design and execution of extremely complicated, long tests. –Leverage tools providing keyword testing frameworks. Helps separate test design from script  Inconsistent/unreliable automated test frameworks –Ensure proper skill on team to maintain and adjust framework(s) –Leverage or develop common framework across many projects to reduce risk –Consider GUI-free (headless) automated functional tests –Keep tests singular in purpose and focused Some Automation Testing Best Practices

33 IBM Software Group | Rational IBM Confidential33 Steer – Measure Business Value 44% Return on Investment

34 IBM Software Group | Rational IBM Confidential34 Steer – Take Corrective Actions

35 IBM Software Group | Rational IBM Confidential35 Tools Deployed  Rational Build Forge for Centralized Build and Deployment –Build and Deploy the Applications under test –Deploy and Configure the associated software required for testing for eg WAS, DB2 –Deploy the repeatable configuration on any machine  Results Achieved –Significant Reduction in deployment cycles For eg manual task of 4 hrs (turn around time of 1.5 days avg) reduced to consistent 27 min each –Specific skill dependency removal. Anyone in team could prepare the test machine with few clicks on the UI

36 IBM Software Group | Rational IBM Confidential36 Steer – Measure Business Value

37 IBM Software Group | Rational IBM Confidential37 Act Rapidly deploy tools, workflow and best practices 2010 and Beyond – Continuous Improvement Steer Monitor progress, take corrective actions and measure business value Identify business goals and set priorities Assess

38 IBM Software Group | Rational IBM Confidential38 Agile and Tools Adoption v/s Deliveries Q1 08 Fix Pack BPS=0 Fix Pack CMVC=0 Very Low Incoming Rate Q2 08 Q3 08 Q4 08 Q1 09 Q2 09 Q3 09 Q4 09 Q1 10 Q2 10 Q3 10 Q4 10 Q1 11 Q2 11 eReview 5.2 Connector 1.0 eReview 5.3 eReview 5.3.1 Connector 1.1 Connector 1.1.0.1 Connector 1.2 Connector 1.3 Agile + Strong Focus on Engineering productivity Reduced Attrition RTC RFT RAD RQM(TDD) 1.4 CLM Fix Pack Q2 12 Q4 11

39 IBM Software Group | Rational IBM Confidential39 Smarter Work = Results + Learning + Increased Job Satisfaction

40 IBM Software Group | Rational IBM Confidential40 Conclusion  Implementing Agile in software maintenance project can have significant impact on people and productivity of the team.  Each Team is Unique with its own set of challenges –Let the team decide the best way for themselves Not everything works by the book  Start small, pick up practices which would have maximum impact on team’s productivity –You still have to deliver the committed work plan –There is significant learning curve in understanding the practices and tools involved by EACH individual in the team –ASSESS on Regular basis on what is working and what not and adapt accordingly –Spend time on learning and building new skills. Revamp the existing ways of working with improved technology.  Use Tools to multiply the force –Collaborate extensively within the team, Improve Transparency, Reduce Overheads in reporting Agile Planning tools like Rational Team Concert –Eliminate Manual Repetitive work of Significant Volume Rational Functional Tester and Build Forge


Download ppt "® IBM Rational software © 2012 IBM Corporation A case study of Agile journey by a small software development team (2008-2011) Vivek K Gupta Engineering."

Similar presentations


Ads by Google