Agile In Practice: An Agile Success Story February 2012

Agile In Practice An Agile Success Storyfebruary 20122agile In Prac

Our client, serving approximately 10,000 clients worldwide, faced significant challenges with their aging platform, which was inefficient and costly to adapt. In August 2010, Deloitte Consulting was engaged to develop a new global platform with portal, collaboration, and document management features, utilizing Microsoft SharePoint 2010 (SP) as the foundation. The project involved complex requirements, including thousands of combinations of clients, locations, modules, and functionalities. The client lacked extensive experience with enterprise-scale projects, making the development process particularly intricate.

Over 16 months and through 11 releases, the Deloitte team successfully delivered a solution that surpassed expectations. Each release provided working software, allowing the client to provide feedback and refine requirements iteratively. All releases were delivered on time and under budget, demonstrating the effectiveness of an agile approach tailored to the project's unique constraints and needs. This paper explores the reasons behind choosing an agile methodology, how it was implemented, and key lessons learned to benefit future projects.

Paper For Above instruction

Introduction

Agile methodologies have revolutionized software development by promoting flexibility, iterative delivery, and close collaboration with stakeholders. For large-scale, complex projects like the development of a new global platform for a major client, traditional waterfall methods often fall short due to rigid planning and delayed feedback cycles. The Deloitte team’s experience underscores the strategic importance of adopting an agile lifecycle tailored to project specifics, especially in environments marked by evolving requirements and distributed teams.

Rationale for Adopting Agile

The initial phase of the project employed a conventional waterfall approach to establish high-level requirements and design, given the need for control over scope and budget. However, as requirements became more detailed and prototypes proved insufficient, the need for more flexible and responsive development practices became evident. The client’s involvement and willingness to embrace change were crucial in shifting to an agile approach. The decision was driven by the necessity to facilitate continuous refinement, deliver incremental value, and adapt to the rapidly evolving project landscape.

Moreover, the limitations of traditional SDLC in managing complex, high-volume configurations and the desire to gather real-time feedback from the client reinforced the switch to an agile model. The client’s involvement in prioritizing scope and directly participating in reviews also aligned well with agile principles, enabling the team to maintain agility despite resource and time constraints.

Implementation of Agile Methodology

The team adopted a modified SCRUM-based framework, adjusted to fit the project’s specific context. Terms such as "Releases" replaced "Sprints" and "Features" replaced "User Stories" to accommodate client preferences and the nature of work primarily centered around features rather than discrete user-centric stories. The agile transition was incremental, avoiding disruptive overhauls—an essential approach given initial limited experience with agile and lack of full tooling support for agile practices.

Initially, the team invested three months (February-April 2011) developing processes, frameworks, and tools necessary for consistent release cycles. From May onward, the team achieved a rhythm of delivering functioning software approximately every four weeks. This iterative cycle allowed the client to evaluate each release, provide feedback, and influence subsequent development, significantly improving project alignment with business goals.

The team also tailored planning, execution, and reporting practices. During co-location weeks, the team prioritized backlog refinement, feature selection, and task breakdown. Each release adhered to a structured workflow: development and testing in the first three weeks, stabilization, and a final week dedicated to presentation, feedback, and planning the next iteration. This structured approach balanced agility with project control, ensuring steady progress amid evolving requirements.

Distributed Teams and Collaboration

Initially, offshore resources were considered to control costs; however, due to the iterative nature of the project, a shift was made to onshore teams. Talent was sourced from Mexico City and the US Federal Consulting practice, with remote collaboration facilitated using technological solutions like Microsoft Lync (now Teams) and virtual machines (VMs). The VM infrastructure allowed rapid setup, flexible access, and minimized travel needs, boosting productivity and work-life balance while maintaining effective communication and oversight.

Regular virtual stand-ups, design reviews, and weekly status calls kept the team aligned. The use of shared documentation and project management tools enabled real-time updates on issues, risks, and work progress, fostering transparency and accountability across dispersed teams.

Planning and Execution

The project utilized an evolving Release Roadmap, iteratively refined during team co-locations. Features were prioritized based on client input and technical feasibility, with detailed task breakdowns assigned through a comprehensive backlog maintained in SharePoint and TFS (Team Foundation Server). The planning process involved selecting high-priority features, estimating effort, and delivering increments every four weeks, with each cycle culminating in a client presentation and review.

Execution involved continuous development, integration, and testing, with emphasis on delivering value in each release. Notably, although continuous integration was not fully implemented, the team maintained disciplined development processes to ensure stability. The final week of each cycle focused on user demonstrations, feedback collection, and process retrospection, fostering continuous improvement.

Documentation and Reporting

Given the rapid pace, traditional static documentation was replaced with "smart" documents integrated into the development process, such as XML-generating SharePoint artifacts, code-enforced specifications, and reverse-engineered diagrams. This approach minimized rework, maintained current documentation, and supported traceability.

Progress tracking and reporting utilized SharePoint, TFS, and Excel dashboards. Project issues, risks, work items, and change requests were managed in SharePoint, while Excel charts provided visual status summaries. Weekly status updates were automated, reducing administrative overhead and ensuring stakeholders always had current project information. Formal project dashboards and release decks summarized progress, challenges, and upcoming priorities, facilitating transparency.

Lessons Learned

Successful adoption of agile practices depended heavily on team competence, managerial support, and client engagement. The key enablers included highly skilled, self-motivated team members, a knowledgeable and flexible client project owner, and the strategic use of remote collaboration tools to offset geographical dispersion. The team’s focus on quality and incremental delivery consistently exceeded client expectations, confirming the efficacy of the agile approach in complex environments.

Nevertheless, areas for improvement were identified. These included the need for client training in agile principles, emphasizing the importance of understanding roles and responsibilities, and the adoption of automated unit testing to support continuous integration. Implementing a comprehensive Application Lifecycle Management (ALM) toolset, such as TFS, was recommended to enhance requirements traceability, test management, and reporting automation, further streamlining project governance.

Conclusion

This case study illustrates that an incremental, adapted agile approach can successfully manage complex, large-scale projects with distributed teams, limited initial agile experience, and evolving requirements. The project’s success—delivering on time, under budget, with high quality—attests to the importance of flexible planning, committed stakeholders, and continuous learning. Organizations undertaking similar initiatives should consider a tailored agile lifecycle, focusing on incremental delivery, stakeholder engagement, and robust collaboration tools to navigate the challenges inherent in enterprise software development.

References

• Cohn, M. (2005). Agile estimating and planning. Prentice Hall.
• Highsmith, J. (2002). Agile software development ecosystems. Addison-Wesley.
• Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum. Prentice Hall.
• Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON, 26, 1-9.
• Derby, E., & Larson, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
• Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. (2016). Agile project management and success: A systematic literature review. Journal of Software Engineering and Applications, 9(10), 533-552.
• Beck, K., et al. (2001). Manifesto for Agile Software Development. Agile Alliance.
• Kniberg, H. (2011). Scrum and XP from the Trenches. C4Media.
• Ambler, S. (2012). The Agile Data Warehouse. IBM Press.
• PMI. (2017). Pulse of the Profession: Navigating Complexity. Project Management Institute.