Sustainment of existing software-intensive systems—corrective maintenance and evolution of capability—is a large part of the software activity performed by or on behalf of the US Department of Defense [Defense Acquisition University 2011c]. Agile methods have been successfully used in sustainment as well as new developments in commercial industry, and in fact, some of the program offices that we interviewed either started as sustainment projects or transitioned into sustainment projects during the course of the project’s life cycle. One of our reviewers commented, “Agile is perfect for continuous maintenance, [including] many of the NASA Deep Space systems.” Among other benefits, one reviewer commented that, for programs they had worked in an Agile fashion for both development and sustainment, “…there is very little change in process or planning artifacts when a product transitions from development to sustainment. This can save an enormous amount of time and money.” There is also, generally, alignment between a sustainment effort’s periodic releases for patches and the short iterations used in Agile methods. In sustainment contexts for IT systems with long life, contracting mechanisms tend toward service contracts, in which the contracted element is the staffing of a set of skills anticipated to be needed to sustain the software at a certain capacity. Projects we interviewed in these kinds of sustainment contexts found estimating and tracking using Agile methods and measurements to be useful to the customer as well as the development team. This is because of the strong communication between 36 One of our reviewers who has used AgileEVM noted, “This is fine as long as the iterations are short. When an iteration is longer than about three weeks, it will be important to calculate percent complete of an iteration based on percent of story points planned for the iteration that are complete to this point in the iteration. This is a type of “information radiator” that can be implemented that basically shows current percent complete of the iteration.” CMU/SEI-2011-TN-002 | 64 end users and the development team that resulted in a deep understanding of the priorities of the user community being served and a commitment to providing as much value as possible. In service contracts of less than $20 million EVM threshold, where Agile methods were in use, the use of story point estimation and the formulating of iterations based on product backlog (often consisting of requests and defect reports from the field) were consistently in use. Much of the content in Section 5.4, Contract Execution and Monitoring, applies equally well to sustainment situations as to new start situations. The biggest difference in sustainment is that an architecture for the system has been defined and implemented. Depending on how well it has been communicated to the sustainment team, there may be constraints on the team’s ability to evolve the product to serve end-user needs. This is because the team also needs to adhere to the architectural constraints that are often in place to meet security or other non-functional requirements that may not be obvious to a team taking over an implemented product. In this situation, there may be iterations that are needed from time to time that are expressly focused on evolving the architecture to address new infrastructure or quality attribute requirements. From an estimation process viewpoint, these iterations are likely to be estimated using either non-user technical stories, or some other estimation method, such as ideal days. CMU/SEI-2011-TN-002 | 65 6 Moving Toward Adoption of Agile in DoD Information Technology Acquisition 6.1 Why Change to Agile Methods? Changing the practices of an organization is rarely easy. The further the new practices and their methods are from current practice, the more difficult, time-consuming, and resource-consuming the change is. In Section 1, we pointed out several of the reasons that acquisition and development organizations are adopting Agile methods. Our interviewees exhibited a wide variety of reasons for considering Agile methods. The ones who experienced the greatest success were those for whom the change was important in a particular, rather than a general way. Where the motivation for change was less particular and more general, the changes did not stick as well, nor were the expected benefits realized. The two biggest reasons we have seen within DoD for moving to Agile are improve outcomes, it is likely to be cancelled. mission-critical enough to warrant a different acquisition approach. In the programs that we interviewed, there were other motivations for beginning the change to Agile practices. For the organizations that have been using Agile methods for some time, we heard some common themes that characterized their continuing motivation for change, including functionality the end user needed approach The above themes were seen among both developers and acquirers. However, all the organizations agreed that their culture and practices needed to change if they wanted the benefits they were seeking from adopting Agile methods. The next section discusses a way to gauge the size of the needed adjustment. 6.2 Understanding the Scope of Change 6.2.1 How Big a Challenge is Your Adoption of Agile Practices? Paul Adler, a well-known researcher in the field of organizational behavior, has postulated a continuum of change that predicts how difficult it will be for an organization to change its practices. In its simplest version, it looks at factors that indicate increasing level of difficulty, and correlated with that, time to change. The least impacting change tends to be a skills change, followed by procedural change, structural change, strategy change, and the most difficult and CMU/SEI-2011-TN-002 | 66 time-consuming, culture change. See Appendix G for elaboration of these factors and their effect on time and complexity of change efforts. It is clear in our interview population and other experience that different organizations adopt Agile practices to different levels in terms of Adler’s progression. All projects we interviewed at least had skill and procedure changes. Many of them incorporated structure changes due to different kinds of interactions with users than in the past. Some also changed their business strategy, and several of them changed their culture to be more amenable to Agile practices. In the book Becoming Agile, the authors differentiate “doing agile” versus “being agile” [Sidky 2009]. From Adler’s viewpoint, they differentiate “being Agile” as involving the culture change to adopting the values of the Agile manifesto published in 2001 [Adler 1990]. We discussed Agile cultural norms in Section 2. In that section, we introduced some of the differences between Agile culture and more traditional development cultures. We will address that knowledge, as well as other elements that affect the pace and success of change, in this section. 6.2.2 Adoption Assumptions Table for Agile Methods As part of a readiness and fit assessment (RFA) for adopting Agile methods, a series of adoption factors that include those from Adler have been articulated. RFA can help you to understand how far away your own organization’s practices, values, and culture are from what is typical in an organization that has embraced Agile practices and culture [Garcia 2006]. Cultural expectations related to an environment that has successfully adopted Agile methods are divided into two columns. The first lists expectations of what would be seen in a development organization adopting Agile methods. The second lists expectations of what would be seen by customers (or in the DoD case, acquirers) of a solution being built using Agile methods. This is a starting point list based on our observations of Agile projects in the DoD context. The kinds of behaviors and attributes that are listed in Table 5 are ones that we have seen in at least some of the DoD programs that were adopting Agile methods. Some of the content of this table reflects that of Table 2, which focuses on the cultural aspects explicitly. However, Table 2 only focuses on acquisition personnel. By providing both developer and acquisition personnel expectations, we hope to help acquisition program offices understand the cues they are getting from their development contractors. As more DoD projects adopt Agile practices, we expect Table 4 to evolve, since particular instantiations of these factors depend on both the product and environmental context. Refer to Section 6.2.3.3 for information on how to use Table 4 in a readiness and fit assessment. CMU/SEI-2011-TN-002 | 67 Table 4: Adoption Expectations for Agile Culture, Practice, and Skill for Developers and Acquirers Adoption Factor Agile Culture Expectations— Developer Agile Culture Expectations— Customer/Acquirer Business Strategy (What types of business strategy are typical in this environment?) -customer-centric vs. technology-centric business strategy -value to customer is paramount -incremental delivery is supported -ongoing solution vs. single point product is needed/supported Reward System (What are the types of behaviors that are rewarded or punished?) -team performance is emphasized more heavily than individual -mentoring is rewarded -candor/truth is rewarded, not punished -solving problems that are not directly tied to your iteration goals is NOT rewarded -heroics are not encouraged -early functioning software release is rewarded vs. documents being “finished” Sponsorship (What level and types of sponsorship behaviors are needed for adoption to succeed?) -requires local engineering management sponsorship and senior management buyin that is sufficient to allow changed practices -vision for change is shared by sponsor and teams -engineering and senior management are willing to adopt “time box” approaches to managing -willingness to permit access to enduser subject matter experts throughout the development life cycle -willingness to be an active partner in the co-creation of the software solution Values (What cultural norms are exhibited in the activities and decisions of the organization?) -keep everything —software, documentation, overhead—as simple as possible -sharing of information vs. “knowledge is personal power” -learning is valued -fail fast, learn fast is encouraged -self-reflection via activities like retrospectives are encouraged -strong team-based values -shared team understanding of what “done” means -developer isolation is frowned upon -metrics used for course correction, not punishment of individuals -“gold-plating” is discouraged -bloated software is discouraged -minimizing waste is important CMU/SEI-2011-TN-002 | 68 Table 4: Adoption Expectations for Agile Culture, Practice, and Skill for Developers and Acquirers (cont’d.) Adoption Factor Agile Culture Expectations— Developer Agile Culture Expectations— Customer/ Acquirer Skills (What skills and knowledge are prevalent in the individuals in the organization?) -working well with peers (especially for pair programming) -translating user scenarios (stories) into test cases -working directly with end users or surrogates -different roles working together across boundaries (i.e.., testers and developers working together from the beginning of the cycle) -strong verbal communication skills -ability to move on when product is sufficiently “done” -strong verbal communication skills -facilitative leadership skills -conflict resolution skills when dealing with diverse stakeholders -ability to recognize when product is sufficiently “done” to move on -working effectively with end users or surrogates Structure (What kinds of structural mechanisms are used that contribute to the organization’s success?) -colocation; use of collaboration technology to compensate when colocation is not feasible -team roles are flexible -layering of teams when projects get too large for a single team; sometimes this becomes a hierarchy, sometimes it is a set of peer teams -porous boundaries between acquisition and development staff -support for a strong user (surrogate) presence throughout development iterations and at release History (How necessary is successful change history to the adoption of this set of practices?) -history of successful management changes is helpful in getting teams sufficient time to demonstrate new approach to senior management -“burning platform” motivation is often useful in allowing teams to try something different from past practice -understanding that “silver bullets” don’t work is useful Work Practices (What work practices distinguish this technology or methodology from others?) Note: Not all of these work practices are present in all variations of Agile methods. -test-driven development -user scenarios creation -pair programming -daily builds; continuous integration -strong version control -project retrospectives -iteration-based release management -daily standup meetings -collaborative planning among team, customers, and management -use of velocity as a primary measure of team progress -active participation in construction and evolution of a product backlog -active participation in progress reviews and demonstrations -active participation in construction and evolution of user stories -collaborative planning among team, customers, and management -construction of contracting vehicles that support practices (see above) and deliverables typical of Agile methods CMU/SEI-2011-TN-002 | 69 In earlier sections of this document, we explored some of the above attributes as well as others that play a role in adopting Agile within a DoD context. As more development organizations adopt Agile practices (some of the literature argues that Agile development has already reached a tipping point in the software industry and is becoming the dominant approach), more DoD acquisition organizations are likely to try to benefit from Agile [Leffingwell 2008]. The recent report to Congress responding to the 804 section requirements of FY 2010, although it does not explicitly call out Agile, embraces many of the tenets of Agile, as we have discussed in the early sections of this report [OSD 2010]. The further organizations are from the attributes in the adoption expectations table above, the more difficult the transition to Agile practices will be. The 804 Implementation Task Force has started studying the DoD and service-level acquisition regulations to find or establish better support for responsive, iterative acquisition practices. Although the task force has found some supportive rhetoric, it also has found regulations that are more easily interpreted to prohibit some of the Agile attributes listed above; however, these interpretations are not codified into regulations.37 For IT systems at least, changes in regulations that make it easier to adopt Agile methods are being contemplated, according to the 804 report [OSD 2010]. 6.2.3 Approaches for Successfully Adopting Agile Practices In interviewing projects that have adopted Agile, we consistently asked, “Did your approach to adopting Agile methods have to be different from your approach to adopting other new practices (e.g., new testing methodologies)?” The consistent answer to this question was, “No, the same things you have to pay attention to for any adoption must be paid attention to for adopting Agile practices.” In this section, although we will address some more general organizational change management approaches, we will include, where we have seen it, how these approaches were expressed in our interviewed projects. There were a variety of approaches that the programs we interviewed took for adopting Agile practices. Most exhibited awareness of cultural issues, adopter populations, and finding or building the right adoption support mechanisms for their environment, even though they might not have expressed their journey in exactly those terms. The change management topics we will focus on below are typical of the things that must be dealt with in adopting Agile practices: 6.2.3.1 Understanding Your Adopter Population When adopting new practices, it is crucial that you understand the characteristics of the people— both as individuals and groups—you are trying to influence to adopt. Geoffrey Moore, a marketing researcher and business consultant, leveraged prior research that indicated that groups are differentiated in terms of their propensity to adopt a new technology, and can be characterized 37 Boston, J., et al. EX INVEST proposal to Office of the Secretary of Defense. 2010. CMU/SEI-2011-TN-002 | 70 in terms of the types of communication and implementation mechanisms they need to feel comfortable with the technology [Rogers 2003]. He noted that, in conjunction with the adopter groups that had been previously defined, a “chasm” appeared to exist between two of the groups, from the viewpoint that getting a technology adopted by one group was more than incrementally different from the next [Moore 2002]. Figure 13 shows Moore’s version of the adopter populations curve. Figure 13: Geoffrey Moore’s Adaptation of Rogers’ Adoption Populations Curve38 The chasm appears between the Early Adopters and Early Majority groups. These two groups are very different in terms of the kinds of communication and implementation mechanisms that will influence them to adopt the new practices or technology. We observed most of the current DoD adopters of Agile to be Early Adopters, although when some programs began their adoption, they were even farther to the left. (For example, some of them were willing to put together their own tools for managing their product backlog and to measure and monitor their velocity.) Where we saw Early Adopter attitudes in the development staff and the acquisition staff, Agile methods had sufficient support to achieve successful use. The Early Majority adopters, on the other hand, are looking for a more explicitly proven benefit and prefer technologies or practices that are supported by training and tools. However, they are still willing to tailor practices to their own environment or domain. Where we have seen the most conflict in DoD programs in transition toward Agile methods is one where Early or Late Majority acquisition staff had been rotated into a program that had been previously staffed with Early Adopter acquisition and development staff using Agile methods. In particular, plans that had been made for iterative mini-PDRs were reversed by the acquisition staff to a more traditional “one big PDR” event. As some of the recommendations from the 804 Report to Congress are implemented, we hope that more communication and implementation support mechanisms will be made available to Early and Late Majority acquisition staff. 38 The y-axis, not shown in these figures, represents the percentage of people typically in each group. CMU/SEI-2011-TN-002 | 71 What this meant to our interview population is that they have been instrumental in terms of finding ways to “work Agile” in an environment that demands artifacts and evidence based on working traditional. In other sections, particularly the Technical Milestones section of this report, we have elaborated some of the ways in which Early Adopters have made Agile methods successful in the DoD acquisition context. However, successful adoption across a wide spectrum of appropriate DoD programs will not occur until more communication and implementation support mechanisms are available to the Early Majority adopters (e.g., DAU courses on how to implement Agile methods in an acquisition program, or other similar guidance). Late Majority (or Conservative) adopters will wait until it is inconvenient to not adopt a new set of practices. The Agile methods proponents are still several years away from penetrating the Late Majority software development community. Evidence of this shift will be when there are Agile variants specific to different domain sectors (like banking) and when Agile methods are the dominant approach being taught at the undergraduate level in software engineering. All of the programs we interviewed exhibited either Innovator or Early Adopter characteristics in their leadership teams, where adoption style will make a huge difference. We are starting to encounter programs that have more traditional middle management even though the senior leadership is interested in adopting Agile methods. Where middle management exhibits more early- or late-majority characteristics, versions of Agile methods with more packaging will have to be used to help them make the transition. For example, an appendix to 5000.02 or Air Force Instruction (AFI) acquisition life cycle regulations that provides explicit guidance on contents and sequencing of technical milestones in a program using Agile would be a part of such packaging, along with tailoring guidance for known variations of program types. Support in terms of policies that visibly drive toward Agile methods is another example of more packaging for Agile approaches. 6.2.3.2 Understanding the Cycle of Change A precept of organizational change is that any change—positive or negative—takes effort and time to incorporate into an individual’s mental models and into a group’s behavioral norms. Even for changes that we perceive as positive, there is a series of steps that we invariably go through (usually faster for positive changes) before achieving the results that are desired from a change in behavior. Virginia Satir’s elaboration of this change cycle has been adopted by well-known consultants and change practitioners in the software industry and is cited explicitly in some Agile literature [Weinberg 1997]. Figure 14 illustrates the basic phases of Satir’s change cycle. CMU/SEI-2011-TN-002 | 72 Figure 14: Satir Change Model The Old Status Quo is disrupted by the introduction of a foreign element—a change that will require different skills, procedures, etc., and will presumably improve overall performance. This precipitates a stage of highly variable performance, as the individual or group tries to accommodate the change within its current frame of reference (for a positively perceived change) or tries to reject it (for a negatively perceived change). Chaos continues until the individual or group discovers a transforming idea. The transforming idea is something that allows the individual to perceive some intended benefit from the change and incorporates some idea of how to connect the change to his or her own behavior and values. It is easy to think that, at this point, the New Status Quo, complete with improved performance, will be reached. However, a stage of integrating and practicing the new behavior, and fine-tuning it to meet the individual’s context, will be needed before the New Status Quo, with its associated benefit in performance, can actually be reached. As a whole, DoD’s adoption of Agile is centered in the Old Status Quo and Chaos sections of the graph, with a few programs that are in Integration and Practice, and a handful at best where Agile is the New Status Quo. In our interviews, we saw evidence of this cycle. It was common for organizations to phase in their adoption of Agile methods over at least a couple of years, allowing staff to get accustomed to a new set of practices (e.g., pair programming) before adding in another set (e.g., continuous integration). When this kind of phasing is done, while conscious of where the individuals generally are in relation to the Satir cycle, the Chaos stage can be minimized. In most organizations, the optional point to add in a new practice is shortly after a New Status Quo has been achieved. At that point, the new behaviors are fairly embedded, but have not become so ingrained that they are difficult to modify if needed. However, piecemeal adoption of Agile methods, if not paced wisely, has also resulted in lack of full adoption and lack of benefit realized. In some cases, we saw an organization that was well on its way into Integration and Practice but was thrown back into Chaos when a new foreign element was introduced. In particular, backsliding was seen when they were asked to continue achieving the success they were seeing with Agile practices while maintaining the familiar technical milestone events of a single PDR CMU/SEI-2011-TN-002 | 73 and single CDR. From a Satir viewpoint, the solution to this dilemma is to find a transforming idea that allows both approaches (Agile and traditional PDRs) to coexist. If there is insufficient trust between the different parties advocating for the conflicting practices, finding that transforming idea could easily fail. We observed that failure firsthand in one of the programs with which we were involved. 6.2.3.3 Understanding Your Adoption Risks Once you have some ideas about your motivation for change, the scope of the change, and the population you want to adopt the change, you can get more specific about identifying the particular adoption risks you are likely to face when adopting Agile development and acquisition approaches. One effective way of identifying adoption risks is to use Table 4, introduced in Section 6.2, as a basis for analyzing how closely your current organization exhibits the kinds of attributes that are typically seen in Agile environments. This method has been successfully used in other areas, including CMMI adoption and complex commercial off-the-shelf software adoption (like enterprise resource planning (ERP) software) [Garcia 2006]. We briefly summarize below an organizational evaluation method called Readiness & Fit Analysis. For additional detail on applying Readiness & Fit Analysis (RFA), refer to Chapter 12 in CMMI Survival Guide: Just Enough Process Improvement. By surveying or interviewing potential Agile team members, you can get an estimate of how close the organization’s attributes are to the Agile attributes in Table 4. Usually a 1-to-5 scale is used. The results can be aggregated by group and reported via a histogram or kiviat (radar chart) diagram to get an overall perception of fit. Beyond the summary visualization, it is extremely valuable to ask participants, via either a survey or workshop or interview, for specific issues they see in a particular topic area that would impede adoption or, conversely, specific strengths they see that would improve the chances of successful adoption. These opportunities for leverage, issues, and risks (participants will naturally identify some of each) can be grouped into similar themes (which may or may not reflect the categories in the expectations table—often they do not), and mitigation planning can be done to address the issues. There are dozens of adoption support mechanisms that can be acquired or developed to help an organization through an adoption of new practices. The mechanism used across the majority of our interviewed programs was external training and consulting. Sometimes this was conducted by the iconic agilists in the field (one group hired Ken Schwaber, a well-known and prolific agilist, as its consultant/trainer). Agile consultants and trainers usually addressed four particular areas of the assumptions table for Agile methods: practices, skills, sponsorship, and values. Other transition mechanisms used included facility changes (substitution of team rooms for individual cubicles), changes to program-level management directives, formation of Agile methods communities of interest, and lunch-and-learn activities where individuals from the team chose a topic about which to become more knowledgeable. The most obvious of the four areas focused on by Agile consultants is practices. Training is a standard way of transferring knowledge about what practices are relevant to a particular situation and how to execute them. Successful use of practices depends, of course, on appropriate skills. The skills needed to adopt Agile methods, in terms of individual techniques, can be acquired through basic training. However, a more complete training series that includes education on Agile culture and values provides a basis for helping team members on an Agile program make CMU/SEI-2011-TN-002 | 74 decisions that are consistent with the Agile culture even if the situation was not exactly the same as those covered in the class. At least one of our interviewed organizations took this extra step with its training approach. Another program used team coaching from the consultant during a real project as a way to help the team recognize, transition, and apply the values of an Agile culture. Both approaches worked for the groups involved. The other role a good Agile consultant played in some of the programs we interviewed was as coach to the sponsors of the Agile methods adoption. Early-adopter sponsors often understand the broad concepts and goals of a set of methods like Agile methods, but may not be as certain as to how their typical behaviors will enable or create barriers for adoption. A good Agile consultant can be very useful in pointing out alternative behaviors for the sponsors that will be more productive in an Agile setting. At least one of the programs successfully used its consultant in that role. 6.2.3.4 Building Transition Mechanisms to Mitigate Adoption Risks We introduced the concept of communication and implementation support mechanisms in section 6.2.3.3. They are both examples of the more general category of transition mechanisms. Deciding which mechanisms must be built, and at what point in an adoption of new practices, is a common issue, regardless of the technology or practices being adopted. The timing of training, in particular, can have an effect on adoption pace. Training delivered too early cannot be acted on before the skills dissipate. Training delivered too late rarely is successful in refocusing negative impressions of the practices, especially ones that require new skills. A model we have found useful for almost two decades in figuring out what adoption support mechanisms to build when is based on the adoption commitment curve, illustrated in Figure 15. Figure 15: Adoption Commitment Curve [Conner 1983] Contact Names Awareness Buzzwords Understanding Concepts Trial Use Possibilities Time Adoption Unintended Uses Institutionalization Synergy Commitment CMU/SEI-2011-TN-002 | 75 This curve expresses, in general, the difference in commitment that is needed by an individual or group to adopt a new technology or set of practices. The early, “easy” stages—contact, awareness, and understanding—primarily rely on communication mechanisms to help people move forward. The latter, “hard” stages—trial use, limited adoption, and institutionalization—rely on implementation support mechanisms that tend to be more specialized to the technology and the organization than the types of communication mechanisms that are used earlier in the adoption. For Agile methods, some candidate transition mechanisms that might be useful at each stage of adoption in the DoD are proposed in Table 5. These are based on our team’s interviews with DoD programs and our knowledge of Agile patterns of adoption, and have not been reviewed for their ease or difficulty to implement in DoD or service regulations and directives. They are suggestive, more than exhaustive or complete. Table 5: Candidate Transition Mechanisms for DoD Adoption of Agile Methods Keyed to Adoption Commitment Curve Stages Contact/ Awareness Understanding Trial Use Adoption Institutionalization Articles in Crosstalk, Defense Acquisition News, and other publications on programs successfully using Agile methods Course modules in DAU acquisition courses discussing when and how to use Agile methods in DoD acquisition Standard language for Milestone Decision Authorities to use to except programs using Agile methods from waterfall practices that conflict with Agile methods Standard reporting templates for oversight reports expected in an Agile acquisition Language changes to DoD 5000.02 and service regulations that make clear when to use Agile methods and provide guidance on making Agile methods effective within an acquisition Conference tracks and workshops that highlight the benefits and risks associated with adopting Agile practices Conferences and workshops that focus on implementing Agile concepts in a DoD acquisition environment Provisions for programs attempting Agile methods for the first time to get continual direct access to their enduser communities Guidance on use of story points and other Agile estimation mechanisms in GAO Estimation Best Practices Guide Citation of the successful use of Agile methods in programs that are held up as models for DoD acquisition success (obviously only if the use of Agile methods is true!) The adoption commitment curve helps to explain why training can sometimes be too early in an adoption cycle. Training is primarily used as an awareness-building mechanism (one-day Agile methods overview, for example), or as an understanding-building mechanism (five-day Agile methods course where students exercise all the skills associated with that particular method on case study projects or their own). When skills-focused training is used as an initial event, it is usually overkill—the potential adopters have not had sufficient exposure, contact, and awareness to the practices or technology to “make it their own.” Most of the programs we interviewed used external training, primarily of the skill-building type, to jumpstart their Agile teams. Some of them used general training as a way to build awareness of the coming change with both managers and development staff. Others used conferences, readings, and guest speakers at meetings as a way to build awareness of Agile methods before embarking on skill-building training. Coupling the adoption risks list generated via RFA with the adoption commitment curve is a powerful way of planning “just in time” adoption support mechanisms for your Agile adoption. As we gain more insight into adoption of Agile methods across a broader range of DoD programs, CMU/SEI-2011-TN-002 | 76 it may be possible to better characterize typical mechanisms that have been successful in different acquisition settings. 6.2.4 Organizational Change Management Summary Although it is easy to say that Agile methods do not require any different methods for addressing organizational change, it is not so easy to actually apply those methods in demanding project settings, just as it is not easy to do so for other practices or technologies. Someday there may be a “GAO Best Practices Guide for Adopting Agile Methods,” similar to the GAO Guide for Estimation. In the meantime, we leave you with the following advice: or acquire them before you get too far into your adoption. There is a starter list of resources for Agile adoption in Appendix 1, several of which are focused on organizational change management. CMU/SEI-2011-TN-002 | 77
Marie New York I have been affected severally with late delivery of assignment but since I hired an EssayBark writer, my assignment reaches me before the expiry of the agreed deadline. Some tasks proved to be difficult since they required me to express my original ideas after carrying out an extensive research. This used to give me sleepless nights and occasionally used to turn down my friends invites to parties. However, EssayBark.com came at a time I needed them most and their services proved to be of high quality. Leon Ireland If it were not for EssayBark.com, I don't think I would be where I am today. 90 percent of my success came from this company and I can say without any fear of contradiction that they are the best essay writing company in the whole world. Sam UK Nothing seemed to work my way until I hired EssayBark.com. I can now confidently say that I enjoy my Environmental Science Course because the ideas provided by the writers have simplified all the technicalities of the subject. It seems that your writer understood the subject well. I believe she has a doctorate in the subject. Thanks to all of them for treating me personally. Brown Johannesburg, South Africa Since I started hiring EssayBark.com I learned that investing in your future is more important than any monetary investment. The knowledge provided in my political science essays by your writers helped me defend my thesis professionally in front of my teachers. I am highly obliged to your writers. Tom Sydney, Australia I sometimes lack words to describe how happy I am since I met you guys. You are a gift to many as the essays provided by your writers are original, accurate, and timely. Samara Madrid, Spain Meeting EssayBark.com, to me is fate. I had never dreamt of getting an A in my English literature course but you made my dream come true. Thank you so much. Andrew London Since I started working with Essaybark.com life has never been the same again. I can comfortably say that my grades have greatly improved and I no longer have to worry about failing. Paul Dublin My experience with Essaybark.com was one of a kind. They completely erased all my worries and as per now, I feel like am a master of all difficult topics which used to give me sleepless nights. Thanks a lot for opening my eyes. Layla United Arab Emirates When I decided to join MBA, I wasn’t sure how I was going to handle those essays which required creative writing skills because I was literary very poor in it. However, my problem was solved by Essaybark.com. Apart from helping me with my assignments, they gave me free advice on how to polish my writing skills. My future is now bright all thanks to Essaybark.com. Martha Singapore My worry with most companies offering writing services had been originality but since I started engaging Essaybark.com, all I get is quality and original work, delivered within the specified time frame. If you are looking for quality and non-plagiarized work, I recommend this site for you.
[wpadm-chat]
