Being Diversely Agile Beyond Shores: A Practical Approach
Agile methodology has gained enough ground and has wide spread acceptance in the industry because it offers numerous benefits. It has reached a stage where it has started maturing in its model of co-located agile. The next stage from this maturity is to gain out of these experiences and start reducing cost further, optimizing the time to market while maintaining the same or better the quality of the matured Agile organization.
The momentum has led us to innovate in a way to achieve the objectives. From co-located agile now the things have to diversify to AGILE BEYOND SHORES. This distributed agile will help the industry to utilize the best of talents wherever those are available at the most competitive price. This needs moving to advanced stage of maturity with innovative development and testing practices. If time can be utilized well the time to market can reduce as people at different location can work on the same piece at different 8 hours of the day multiplying the rate of deliverables and reduce time to market significantly.
The implementation of this methodology has worked and has worked in the best way possibly. It challenges the critique who always said “AGILE IS ALWAYS FOR CO-LOCATION”. Not only the Go to Market reduced but the quality saw a significant upward trend as best possible resources at best possible place at best possible timeframe were involved.
The learnings are immense and the practitioners need to understand and inculcate that, to get the best in future. The FOCUS of the whole paper would be to let the audience know what has really worked. It is imperative that due diligence is observed before jumping into the race for AGILE BEYOND SHORES.
Also we need to take care of the measurements to track and benchmark the activities which will become base for the next generation of implementation.
Outline/structure of the Session
Introduction & What is the Theme: Agenda for the session: 3 Min
Presentation: 25 Min
Take Aways: 7 Min
Q&A: 10 min
Some of the recommendations which would be of immense help apart from Learnings and Best Practices described in the other section are written below.
It is recommended to use Scrum during feature releases and point releases but not in New release due to following
Requires Framework selection, Architecture design, technology changes which we didn’t see working well with Scrum
Working s/w not available due to initial major design changes
Difficult to involve customer from this stage through Beta
Needs to be compatible with a lot of environmental challenges
A project plan along with quality plan and testing cycle calendar are must
Unit tests should be handled by the development team, but the results should be available with QE
Program Managers, Project Managers