Enabling Continuous Delivery (CD) in Enterprises with TestingAnand Bagmar
schedule 2 years agoSold Out!
The key objectives of Organizations is to provide / derive value from the products / services they offer. To achieve this, they need to be able to deliver their offerings in the quickest time possible, and of good quality!
In such a fast moving environment, CI (Continuous Integration) and CD (Continuous Delivery) are now a necessity and not a luxury!
There are various practices that Organizations and Enterprises need to implement to enable CD. Testing (automation) is one of the important practices that needs to be setup correctly for CD to be successful.
Testing in Organizations on the CD journey is tricky and requires a lot of discipline, rigor and hard work. In Enterprises, the Testing complexity and challenges increase exponentially.
In this session, I am sharing my vision of the Test Strategy required to make successful the journey of an Enterprise on the path of implementing CD.
Turning around a twice-failed distributed enterprise program into successSridharan Vembu
schedule 2 years agoSold Out!
The common myth about agile methodology is, it is suited for smaller, co-located teams, would not scale up for big enterprises and is best suited for smaller, less complex programs.
In this talk, I intend to share how we went about setting up, executing and successfully delivering probably one of the most complex and strategic programs for one of our customers. This program was the first ever successful adoption of the fully distributed agile implementations for the customer.
Context: The client is the leading Telecom Operator in the UK, having their captive and other strategic partners based out of India. The program was highly strategic for the client and the predicted ROI was high.
- The implementation was tried twice by different vendors for more than an year, but failed to deliver; root causes were not analyzed
- The Program Sponsor had one last chance to try and deliver the platform successfully, against a very tight schedule
- Continued Operational risk with the legacy system in place
Outcome of our engagement:
- Core functional application ready in pre-production by the end of first release cycle (4 months from engagement start); fully ready to functionally scale easily and quickly
- Adoption of the technical and execution approach to other related programs within the portfolio
- Outcome of initial assessment of the existing codebase was to go with re-write from scratch; was a really hard sell, but was the RIGHT thing to do
- Re-define the release cycle: extend development period by embedding integration testing as part of development cycle and cut down on the low level design phase
- Need-basis colocation of functional SMEs with development team
- Direct access to Product Owners: weekly video calls, must-attend iteration show-cases, etc
- Remove unnecessary operational overheads, in terms of people as well as organizational processes
- Well-defined, pragmatic strategy for Integration testing (major constraints - lead time for test data preparation, limitation in re-usability of test data, lack of e2e functional understanding within team)
- Smart seeding of other vendor team members (with good functional/domain understanding) into the core team
- Zero compromise on basic hygienic practices: IPMs, Showcases, communicate negative-news-first with alternate solutions/workarounds, strict removal of wastes, inclusive decision making, highest degree of code coverage, sanity test suite, e2e basic automation suite
- Building trust between distributed teams: cross-pairing, align on core work hours across time zones, joint showcases and retrospectives (shared responsibility)
- Big push to release the core functional platform into production in 3 months (immediate next release)
- Working out of other vendor premises: seen as threat to their business, lack of cooperation and collaboration
- Product Owners based out of UK, no easy / frequent access
- Functional SMEs/designers based out of different location
- Release cycle that was in place: 8 weeks of design, 4 weeks of development and 8 weeks of testing!
- Distributed and isolated testing teams
- Highly manual and time-consuming E2E testing processes
- Multiple interfacing systems, both upstream and downstream
- Client development team based out of UK, different execution approach, lack of trust between the teams
In summary, I would like to share the unique aspects of the execution approach that made this program a real success for the customer, though some of the approaches might be tried out in different environments and project situations.