The need for quicker solutions to the problems is driving organizations to adopt the Agile methodology of development. As per Gartner and Forrester 2012 statistics, 60-80% of software development teams today use Agile as a method to create software which is higher than 2009 levels of 45%. Agile method of development helps companies to take the products to market quickly and in an incremental fashion leading to faster realization of returns on the investments made. The evolution of disruptive technologies across the SMAC (Social, Media, Analytics and Cloud) stack is pushing companies to adopt Agile methodology to software development.
The journey for us from a 15 (+) months product release cycles based on Waterfall model to 6 month release cycle using Agile SCRUM method was not easy. It takes 12-15 months for the process to stabilize and teams getting used to “Agile” way of project execution. Some initial challenges we faced and lessons learned are:
- Still thinking waterfall – Though we moved to so called “4 week sprints”, we were doing waterfall during this duration with Dev teams busy during the initial weeks and QA teams during the later part. It took us 7-8 Sprints to get to effective Sprint planning.
- Long Stand up meetings – No way we could stand so long…. During the initial days, the daily stand up meetings would run up to 90mins going much beyond the status updates. Gradually we managed to cut the duration and sticking to 15-20 mins and started using Urban Turtle for virtual SCRUM boards.
- SCRUM team size – Our initial SCRUM teams were 12-14 members essentially formed based on size of the modules/product areas. While this was convenient, work allocation and tracking became a challenge and we streamlined to get to a size of 6-8 members.
- Another related problem we got into was forming Dev SCRUM teams and QA SCRUM teams. We corrected the process to form balanced teams.
- User story definitions – Our early days of user story creation had Dev stories and QA stories and not feature driven. It took us 4-5 sprints to write feature based stories and thus also correcting team formation challenges. It is equally important to clearly articulate the requirements and define the acceptance criteria for the user story. Story grooming got better after 6-7 sprints to have user stories with estimated effort of 40-45 hours.
- Sprint planning – Story grooming and planning has to be a continuous process to ensure that all user stories are defined clearly by the time sprint starts. It took us 6 sprints to get to this state.
While the operational challenges can be addressed, the cycle time of adoption can be reduced if the change management is driven effectively by training the teams early. The most catalytic factor is accepting the need for change and willingness to embrace the change.