Table of Contents SUMMARY AND CONTEXT... i UNIQUE CHALLENGES OF LARGE ORGANIZATIONS... 1 BECOMING AGILE (NOT AGILE)... 3 Lesson #1: It s the people, not the process... 3 Lesson #2: Partner developers with end-users... 5 Lesson #3: Integrate cross-functional teams for the duration of the project... 5 Lesson #4: Only deliver the most important features... 7 Lesson #5: Deliver iteratively... 8 FURTHER INFORMATION... 10 DELIVERING SOFTWARE WITH AGILITY, WITHOUT AGILE FIVE REAL-WORLD LESSONS A White Paper Terrence Blair Chief Technology Officer Tetra Tech AMT
UNIQUE CHALLENGES OF LARGE ORGANIZATIONS Institutionalized policies and practices, and the deeply ingrained cultural expectations which result from them, represent a significant barrier to introducing all but gradual, evolutionary change to software development processes. The following are some examples of practices common in large commercial and government organizations that challenge adoption of a non-waterfall development approach: Budget justification based on the result of one software development lifecycle phase. We need to request funding for this application, so we better make sure we understand the full scope of requirements. So let s gather all possible requirements this year and then fund the design and development based on those requirements next year. Contracting regulations which are perceived to strictly limit how development phases are contracted. We will hire Contractor X to come in and do our requirements. Since we can t hire Contractor X to do our design and build due to a conflict of interest, we ll contract with Contractor Y to do the design and build. To ensure that we re getting objective insight into what we re paying for, we should bring on Contractor Z to perform independent verification and validation of all deliverables and conduct our system testing. Organizational elements are aligned with both functional capabilities (e.g., infrastructure, design, and development) and life cycle phases, resulting in deep specialization coupled with a lack of overall understanding of the process. The Business Office performs the analysis of the need and requests a funding wedge. The Requirements Office meets with end-users to define the need. Speculative technical areas are handed off to Research and Development to identify technical options. The Engineering group will identify the infrastructure and hosting requirements. The Development organization will build the software (the Systems Analysis component will further decompose the requirements and the Architecture/Design group will design the software architecture before the developers write the code). The Security group will ensure that the system is certified for operation on our network before the software is handed off to our Operations and Maintenance team for release.
Reliance on a proxy system (IT manager as proxy for end-users; business manager as proxy for end-users; SME as proxy for end-users) The organization s IT Manager frequently receives funding from a Line-of-Business (LOB) Manager in order to build the business a software system. The IT Manager then contracts with a development contractor. The contractor then interfaces exclusively with the IT Manager who is serving as a proxy for the LOB manager with the need. The IT Manager then interfaces through the LOB Manager (who often lacks system development or requirements gathering experience) who works with end-users to identify their needs. In some organizations, the LOB Manager utilizes a subject matter expert (SME) who has experience with the needs of the end-users and can identify their needs. The development team sometimes doesn t have access to the actual end-users until acceptance testing. Reliance on external contractors whose scope precludes a feeling of overall ownership for the success of the program. Contractor X is contracted to deliver the requirements. Once complete, Contractor Y receives the requirements. Due to a lack of context regarding end-user needs, Contractor Y misunderstands and/or must further decompose the requirements without access to Contractor X, who is no longer under contract. Contractor Y must often decompose the requirements without validation from the end-users because they don t have access and because the requirements are already complete. Requirements by proxy often results in the development team being removed by several degrees of separation from the actual system users. For organizations with a history of traditional, waterfall-based software development approaches, adopting an Agile approach is often viewed as revolutionary and laden with risk. Small, one-off efforts, even if successful, are often marginalized due to their lack of size and regarded as research/hobby-horse projects due to their non-compliance with established enterprise life cycle requirements. How, then, can these large traditional organizations, for whom waterfall is the norm, deliver with agility without adopting Agile?
BECOMING AGILE (NOT AGILE) Instead of adopting Agile, organizations can reap many of Agile s benefits by applying the underlying tenets which form the foundation for Agile processes. Lesson #1: It s the people, not the process The most dramatic change that agile development foists upon new adopters is an enhanced development culture that contradicts many lessons learned by experienced waterfall developers. Although the waterfall process need not change, the mindset of the people executing the process must. The Agile methodology even has a manifesto, which states: We have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. For experienced waterfall developers and systems engineers in large organizations, this manifesto borders on heresy. The waterfall model is one of the most complete, well-documented, and exercised processes in the software field. An extensive aftermarket of tools has emerged over the years in support of the lifecycle and/or specific phases of the lifecycle. Large organizations rely on documentation to pass through review gates and to ensure that contractors have an understanding of the task. Documentation deliverables are generally specified in contracts along with rigid project plans which serve both as the basis for the cost estimate as well as a means to determine the progress, evaluation, and compensation of the contractor team. As if the Agile manifesto wasn t enough, Agile has also developed 12 principles which further challenge the waterfall framework. Some include the following: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Deliver working software frequently, from a couple of weeks to a couple of months. Business people and developers must work together daily throughout the project. Working software is the primary measure of progress.
These values and principles are not inconsistent with waterfall development and can be infused into the traditional development lifecycles which large organizations follow. Agile Principle Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Deliver working software frequently, from a couple of weeks to a couple of months. Business people and developers must work together daily throughout the project. Working software is the primary measure of progress. Cultural Shift We want constant end-user feedback on the product Only build the highest-priority requirements. Lower-priority requirements generally won t be built. Nothing builds buy-in like delivery Requirements changes are proof that the customer is engaged Changing requirements result in a better product New requirements indicate that the product is valuable We can react to change while following a plan Integrate software and form personal relationships early Software review is a good thing feedback is our friend The end-user is an integrated member of the product team, not an arms-length relationship We want constant end-user feedback on the product Business people and IT people can work together the effort is worth the reward Developers must build something new (albeit small) every day Demonstration of software features are our internal milestones Implications for Large Organizations Frequent ad-hoc demonstrations of the product Prioritize requirements during the planning phase into packages based on quantified business value Minor changes can be implemented Major changes can be managed through the project s Configuration Control Board (CCB) Maintain established review gates, but conduct internal formal demonstrations on a bi-weekly basis Implement a continuous build process to ensure that the product is always working at the end of each day Outlaw stubbing interfaces which merely postpone personal and technical integration Include the end-user in weekly team meetings Customer co-location with the development team Create internal milestones based around feature satisfaction instead of artifact delivery Negotiate tailored versions of organization SDLCs which minimize the creation of lowvalue artifacts Identify an alternative to Earned Value Management as the progress measurement methodology Benefits High priority requirements can be demonstrated early, resulting in momentum and buy-in End-users become invested in the product and feel a sense of ownership End-users feel heard and valued The right product is developed End-users can make rapid course corrections and iterate on the design before too much time has been invested Lack of big-bang integration mitigates technical risk early on and forces partnerships at the onset of the program Stakeholders can see demonstrable progress frequently, building momentum for the product End-users are always up-to date on the status of the software product (no surprises) End-users can make rapid course corrections and iterate on the design before too much time has been invested End-users become invested in the product and feel a sense of ownership End-users develop new appreciation for the development effort Maintains developer focus on activities that add value (software, not documents) Reduces review burden on customer for pro-forma artifacts
Lesson #2: Partner developers with end-users Embedded in the various Agile-based methodologies is a requirement for deep integration between end-users of a software system and the development team. This integration is frequent as Agile methodologies re-prioritize formal requirements after build cycles, which can last as little as one week. Many Agile projects physically co-locate one or more endusers with portions of the development team in order to streamline communication regarding requirements and design and to gain feedback on frequent system demonstrations. While this is generally a tall order for large organizations, the underlying emphasis of close and frequent interaction with end-users is a lesson that can be applied to even staid, waterfall-based projects. There is no waterfall requirement to separate the development team from the end-users of the system. It is most often done for logistical reasons: The end-users are viewed as too busy, too decentralized, or too divided in what they require to be included in the development process. Often, more experienced subject matter experts (SMEs) who may have served in the same role as the end-users act as a proxy during the project. For most software projects, this generally results in software that is based on a singular, and sometimes dated, view of how the business process should work and isn t informed by the nuances typical of most large, decentralized organizations. (The proxy system is most successful for development efforts where there are no existing business processes; where end-users can be trained on whatever new business processes are implemented in the system.) Most large organizations also utilize business analysts or systems engineers to work on behalf of the development team to gather requirements from end-users or their proxy. These requirements are delivered to the development team and then the requirements team exits the project. This can leave the development team with inadequate context about the requirements, no source for questions, and no relationship with the actual end-users. The use of functional proxies and/or distinct requirements gathering teams is not required by the waterfall methodology and unnecessarily increases risk on a software project because it precludes a direct relationship between the development team and the users of the system until development is well underway (best case) or acceptance testing is in progress (worst case). Development teams should be equipped with business analysts capable of requirements elicitation and frequent, ongoing end-user relationship management. This partnership should start during the planning phase and continue through delivery. Developers should be part of all end-user meetings and relationships with end-users should be encouraged, with feedback on the system or project performance managed through the business analyst. This will ensure that the development team and the end-users build the software product in partnership, with a better understanding of true needs and priorities, and the relationships necessary to expedite changes and incorporate feedback. Lesson #3: Integrate cross-functional teams for the duration of the project The idea of integrating cross-functional teams is not new. Almost all software development projects functionally integrate requirements, development, architecture, infrastructure, and testing teams. But integration isn t merely having different specialists work on the same project over time. It is having different specialists work on the same project the entire time. Integration via project plan only, where relevant functional teams participate at a discrete time and manner designated by their specialty and the phase of the lifecycle, is a poor substitute for truly integrating people on a project. Agile practices utilize a matrixed team of specialists (not their managers) that stay with the project from beginning to end. All members participate in all phases of the project, even if it is only through daily stand-up meetings and planning/technical reviews. As a result, each functional team has an understanding of the real delivery and information dependencies of the other members. Over the course of multiple projects, generalized specialists emerge. This close coordination and team-based problem solving results in: More planning realism Because project plans are created together by the cross-functional team, difficult conversations about expectations and otherwise unstated assumptions can be uncovered early on in the process. Earlier risk identification Because all disciplines are involved in all life cycle phases, downstream risks can be identified and mitigated by the overall team. In traditional waterfall life cycles, risks tend to be identified in later stages (e.g. integration, test, deployment), when it is much more expensive to mitigate them.
Higher quality software Because testing specialists are integrated into early requirements phases, they can begin creating test cases and performing functional tests before the end of the project, resulting in the identification of issues that can be addressed much earlier in the project. No hard hand-offs Waterfall-based methodologies are notorious for the delivery of well-documented but poorly transitioned packages from one lifecycle phase to the other. Not only does this result in a long ramp-up time to understand what has been delivered, but it unnecessarily formalizes a relationship between members of the same project. When each specialist is involved in each phase, there is context for transition and less documentation is required. The ramp-up time is drastically reduced because all members are on notice and prepared. True team work In a large organization environment where technical domain skills are often siloed into distinct organizational entities and often further constrained by the limitations of specific contracts or contractors, it can be very difficult to create a sense of teamwork cross-organizationally. Yet teamwork contributes more to agile delivery than any other single factor. Expansive interpretation of contracts in order to define activities to span the lifecycle is often required. For example, a requirements contractor should perform different requirements-related work in different phases, and would therefore be free to be a member of a team for the full lifecycle. The IBM Rational Unified Process (RUP) integrates each discipline in each phase of a software development project.
Lesson #4: Only deliver the most important features The concept of avoiding waste permeates Agile methodologies. For example, avoiding waste is the underlying rationale for reducing lowvalue documentation and other activities which contribute little to the Feature Usage Value 20% Always or often 16% Sometimes 19% Rarely 45% Never Waste *Source: Chaos Chronicles, The Standish Group, 2004
Lesson #5: Deliver iteratively Finally, and most importantly, Agile methodologies are based on the concept of iterative development. Smaller portions of the software product are built and demonstrated more often (sometimes as often as every two weeks) for customer review and feedback, with the feedback incorporated into a subsequent release. Some Agile methodologies, like Lean, even deploy software iteratively in very short time-frames. Although it is not possible to achieve this agility in a waterfall model, iteration can be introduced in partnership with the other four lessons to achieve development agility within the constraints of an organizational commitment to traditional system development lifecycles like waterfall. SOFTWARE DEVELOPMENT METHODOLOGIES Benefits and Challenges for Large Organizations Methodology Benefits Challenges WATERFALL Phases aligned with budget cycles Phases aligned with organizational elements and technical domains Allows comprehensive coverage of each lifecycle Allows technical subject matter expertise focus by phase Scope of phases is well-defined and easier to estimate Big bang approach takes too long before any value is delivered to the users Phases seldom revisited, so it is essential to be both correct and complete before proceeding Assumes non-volatility in requirements during Build and Test Technical module integration does not occur until near the end of the project Because testing is at the end of development, bugs are not discovered until late in the project End-user interaction is limited to the very beginning and end of the project Due to the long timeframe, stakeholders change, bringing with them different needs
Methodology Benefits Challenges AGILE SCRUM LEAN Increased time-to-benefit with functionality much earlier in the life cycle Higher value by reducing waste as little time is spent on activities not contributing to working software Integrates all members of the development team, including end-users, throughout the process, resulting in increased communication, productivity, responsiveness, and appropriateness of the solution Increased responsiveness to change Frequent delivery of the highest priority features minimizes development waste Allows for learning, adjustment, and reprioritization Provides only the most basic documentation deliverables, making traditional gate reviews and independent validation/verification challenging Requires trust between the development team, the customer, and the end-users, as well as among differently incentivized members of an integrated development team Difficult to implement in highly distributed development environments Requires substantial change to formal SDLCs present at most large organizations Presents a substantial cultural change to large organizations with a history of traditional waterfall development Plan Phase Interactive requirements workshops every two weeks using visualization techniques and prototype demonstrations Time-boxed; newly identified requirements pushed to next cycle WATERFALL (with Iteration) Build Phase Working software with every nightly build Internal demonstrations every two weeks with the end-user Requirements re-prioritized every month to deliver higher-value first Formal testing aligned with development feature milestones every two weeks Test Phase Multiple rounds of Developer Team testing followed by User Acceptance testing Partner with the end-user to triage issues
FURTHER INFORMATION To learn more about Tetra Tech s approach to agile practices in software development, please contact the author listed below. About the Author Terrence Blair is the Chief Technology Officer for Tetra Tech AMT, the aviation and information technology consulting arm of Tetra Tech. Terrence can be reached directly at Terrence.Blair@tetratech.com. About Tetra Tech Tetra Tech is a leading provider of consulting, engineering, program management, construction, and technical services addressing the resource management and infrastructure markets. Tetra Tech supports government and commercial clients by providing innovative solutions focused on water, the environment, aviation, information technology and energy. With approximately 12,000 employees worldwide, Tetra Tech's capabilities span the entire project lifecycle.