Introduction: [5 mins]

I currently work as a technology strategist with the IT Application Development department at a global business consultancy firm with over 16K employees and headquartered in New York. We use enterprise level third-party products for supporting our core processes - accounting, invoicing, human capital and supply chain management, where we wish to adopt standard industry practices. We also use third party products that support collaboration across the business - email, file-sharing, online meetings, team calendering, content management etc.

Our experience prior to Agile: Share metrics of typical implementations to demonstrate the following problems. [10 mins]

• P0: Convincing management of the ROI on adopting a time & materials approach instead of fixed cost contract.
• P1: Gaps in marketing promises and product realities.
• P2: Gaps in our own understanding of our end users.
• P3: Vendor resources preferred following the waterfall approach.
• P4: Less than optimal business value due to water-fall approach - Heavy upfront analysis, emphasis on sign-off of specifications and contract, low visibility in configurations and long feedback loops.
• P5: Sunk costs due to upfront infrastructure setup.
• P6: Low user satisfaction
• P7: High costs of future patch and version upgrades.

Our experiments and experiences: [15 mins]

• P0: While it was hard for us to theoretically demonstrate the value of Agile, we convinced business to allow us to conduct a time-boxed Agile COTS implementation for a smaller product, the results of which encouraged them to try it for increasingly complex systems.
• E1: We prepared RFPs in the form of prioritized product backlogs. We insisted on real demos and user labs instead of marketing presentations. We performed iterative and just enough analysis required to select the best product. Some vendors did not like the process initially but bought into it as qualifying vendors were more certain of getting business.
• E2: We insisted that vendors provide a sandbox environment where our end users could play around and experience their product first-hand. We learned a lot about usability and adoption curves through this exercise.
• E3: We tried training the vendor resources on Agile, but things eventually fell back to waterfall initially. So we decided to hire free-lance contractors with a high level of expertise and willingness to learn and have our people serve as Scum Masters and Product Owners. We adopted the Scrum-of-Scrum approach so that the infrastructure, implementation and roll-out teams could work independently but in harmony and sync.
• E4: We prioritized modules by their value to business and degree of isolation. We phased the implementation beginning with a configuration that met the needs of a large percentage of the business and then configuring for local exceptions and features. We were able to roll out pieces of the software much earlier than in the traditional approach.
• E5: Infrastructure team first provided us with a dev, integration and production environment in Sprint 0 with enough capacity to install the first module we were planning to work on and the test data we planned to load. They implemented load balancing in production when we were ready for our first release. The capacity was increased proportional to the requirements of the new features and the number of new users that were added to the system. This helped us stagger our capital and operational expenses, sometimes over years.
• E6: Involving the end users early in the process helped with smoother adoption. Our early adopters had already started sharing their positive impressions of the product to other users. Even before we released the product, there were inquires from offices on when they could have the new product. The change was well received.
• E7: We decided not to make any core customization to the third party product. Instead we built loosely coupled extensions by leveraging the APIs and using Ruby-on-Rails for rapid development. As a result, patch upgrades that used to take several months, are now performed over the weekends. We experimented with behavior driven testing where our analysts constructed automated test cases for testing our business rules and logic. We now leverage these for regression testing of our upgrades. We also created automated test cases for our extensions. We have found that our investment in building these test cases, pays off in the long run.

Results achieved: [10 mins]

• R1: We released the first module into production in just two months. Due to our iterative roll-out approach, we were able to inspect and adapt and apply our lessons learned from our experiences in earlier releases. We rolled-out the entire Employee self service module in 3 months to over 8000 users.

What challenges remain?: [10 mins]

• C1: It is challenging for business and end users to work side-by-side with the implementation team all day long, as they have to perform their regular operational duties too.
• C2: Striking the right balance on who should be involved in what meetings
• C3: Getting vendor support when you are not using their implementation service.

Re-cap, Wrap-up and Q&A. [10 mins]