Approaches Adapting Agile Methodology in a Start-up Published on 07 April 2010 - Revised on I was invited to help a start-up company (a year old company) to build/fix their delivery process. They were catering to local market & had few typical problems: Defects in the application leading to rework; Unable to meet deadlines (this led to financial crunch); Unhappy development & Management teams. In this organization the mindset was to complete the coding, testing and deliver it to the customer. They did not follow any process; even the requirements/ defects/ enhancements were not tracked. This did not help their purpose, as revenue of the company started to show downward trend. I worked with all stakeholders & identified adopting Agile-SCRUM would be good for the organization for the below reasons: It was easy & quick to adapt; There were frequent changes to requirements from their client; They had no tools to track the requirements. There were great challenges to adapt Agile-Scrum Methodologies, some of them were: The total average developer experience in the organization was less than 1.5 years, so the team was not mature enough; They had small projects; for few of them team size was 3. Dedicating a SCRUM master was over kill on these projects; People had little/no knowledge on SCRUM. 1. Plan to Adapt Agile-SCRUM Methodology Identified pilot project that would adapt SCRUM, we picked a medium risk project for two reasons: - If the project is of low priority Management would have no/little interest; - If the project had high risk, in case of failure the organization would never try to Adapt Agile. In parallel we started organization wide SCRUM awareness program; We had lengthy discussions with the client and made them aware of our plan; A business Analyst from the client side was identified and was made the product Owner; he was given some briefing on SCRUM; The team size was 4 so one of the developers had to share the load of SCRUM Master; his time was split between both the roles; We decided to have a three week sprint. 2. Challenges We had lot of defects in the first Sprint delivery; In the Sprint retrospective we found out the team had committed to deliver lot of product backlog and skipped to do code reviews; Team had to be educated the “Definition of Done”; From Second Sprint onwards project stared to settle down. 3. Six technical Practices were adapted in the Organization Version control system was Put in Place; Continuous Integration system was adapted, so we did not find it difficult during the last day of delivery; Automated test scripts were built; used freeware automation tool to build scripts; Refactoring of source code was done to implement new functionality; As the requirements were versatile, design was planned to that sprint, so design was kept simple; Team was made aware that the code is owned collectively and each team member was responsible of the entire build. 4. Results Management team understood the importance of a Process implementation across organization; Pilot project was successful and customer believed that they saved 10% on the budgeted cost; Confidence of Delivery & Management team increased; It became easy to win more projects as they pitched in as a Process oriented Organization; Involvement of Business users has reduced defects. Rate this article: 4.0 Print Anand Rao Anand Rao is a guest contributor and has written one article for PMtips. Full biography Full biography Anand Rao is a guest contributor and has written one article for PMtips. x Contact author
Quigley & Lauck's Expert Column Mastering Quality: A Deep Dive into Quality Tools and Total... By Jon M. Quigley & Steve Lauck
Quigley & Lauck's Expert Column The Essential Guide to Project Roadmaps By Jon M. Quigley & Steve Lauck