Agile DoD Traditional DoD Organizational Structure Flexible and adaptive structures Self-organizing teams Collocated teams or strong communication mechanisms when teams are distributed Formal structures that are difficult to change Hierarchical, command-and-controlbased teams Integrated product teams that have formal responsibilities Leadership Style Facilitative leadership Leader as champion and team advocate Leader as keeper of vision Leader as primary source of authority to act Rewards System Team is focus of reward systems Sometimes team itself recognizes individuals Individual is focus of the reward system Communications & Decision Making Daily stand-up meetings, Frequent retrospectives to improve practices Information radiators to communicate critical project information Evocative documents to feed conversation “Just enough” documentation, highly dependent on product context Top-down communication structures dominate External regulations, policies and procedures drive the focus of work. Indirect communications, like documented activities and processes, dominate over face-toface dialogue Traditional, representational documents used by the PMO throughout the development life cycle to oversee the progress of the developer PMO oversight tools focused on demonstrating compliance vs. achieving insight into progress Staffing Model Cross-functional teams including all roles across the life cycle throughout the lifespan of the project Includes an Agile advocate or coach who explicitly attends to the team’s process Uses traditional life-cycle model with separate teams, particularly for development and testing Different roles are active at different defined points in the life cycle and are not substantively involved except at those times Agile culture, by contrast, is the culture of just enough. “Just enough” is, of course, contextually defined. Just enough documentation for a mobile game application versus just enough documentation for a missile navigation system is likely to be quite different, both in volume and in character. An Agile approach would dictate just enough CMU/SEI-2011-TN-002 | 23 2.5 Implications of Adopting Agile for DoD Planning Approaches Agile practitioners conceptualize a software development project as a value-seeking activity in which knowledge is continually being acquired about the product and the user needs that make it valuable. While most mature Agile development organizations recognize that a certain degree of upfront analysis is important, at the core of Agile is a fundamental belief that knowledge acquisition will and must progress throughout the course of a software development project. One group of interviewees emphasized that, unlike other programs they had worked on, they were allowed to accept that the requirements will change as a routine—rather than exception— condition. Agile encourages interaction among the entire stakeholder team to determine what is required to satisfy the current user needs. Thus, they do enough analysis so that user stories (their way of expressing requirements) assigned to the current iteration can be accomplished, but allow for continuing accumulation of data for stories that will be implemented at a later date. This approach also allows them to not waste effort on items that may change or might be interpreted incorrectly. Another group said that Agile allows them to get a product out in a timely manner because the user environment is constantly changing; they could never know all the requirements. As the users, environment, and technology change, updates and changes can be made to the original product. Non-Agile DoD programs have explicit mechanisms for addressing change, of course. However, generally speaking, those change processes, once a baseline has been posted, require a significant amount of time and effort to navigate prior to a change being actionable. This reflects a mindset of change as an exception, versus change as routine. Agile practices focus on creating a development environment that acknowledges and supports continuous knowledge acquisition. For this reason, detailed upfront requirements specifications and detailed, long-range, task-level project plans are not used within Agile development projects. Agile projects generally reflect a multi-level approach to both requirements specification and project planning.11 Rolling wave planning, an element of earned value management, is a particular approach to resource planning and management that is prevalent in DoD acquisition [Defense Acquisition Guidebook b 2011]. A time period for a wave is defined for the project (often three months, but not always), and the next wave is planned in significant detail, while waves that follow it are generally planned at a much higher level. The thinking, which is similar to that in the Agile community, is that learning occurs as we go and detailed planning beyond a certain window is counterproductive. However, where rolling wave practice departs from Agile practice is in the foundation of each. Rolling waves assume a complete and static set of requirements that will be worked off in a pre-planned fashion. Agile practice assumes that, as the developers and users learn together, requirements priorities and even the need for them will shift, and each iteration provides an opportunity to realign the developer’s priorities to the user’s needs. Interviewees working this way did not provide direct cost comparisons between using baseline change requests (BCR) and shifting requirements priorities between iterations. However, those who had worked previously in more traditional programs did state that the decreased level of formality at least provided a sense of collaboration between user and developer that was missing in other programs they had worked. 11 Note that multi-level, rolling wave planning is not unique to Agile projects; however, it is one of the practices that have become the basis of several Agile methods. CMU/SEI-2011-TN-002 | 24 2.6 Summary To sum up, Agile is a different culture, but one that can be incrementally adopted and tailored to the existing conditions within the DoD. Things like oversight, cross-acquisition/development team structure, and end-user interaction throughout development are areas where incremental steps must be taken in many settings, rather than trying to adopt all of Agile at once. In our interviews, we saw a variety of adoption approaches, several of which were explicitly incremental to ease the cultural transition. The use of Agile methods and the oversight of Agile programs require a mindset change, not just a practice change, for the DoD and other government entities. For example, a PMO that embraces the Agile principle that values operating code over extensive documentation may require a different set of CDRLs when formulating a contract. This not only requires a change in perspective, but also the creation of appropriate governance models, via tailoring DoD 5000.02 and CDRLs from such events as SRR, PDR, CDR, etc. The PMO involved may have to seek waivers from higher up the acquisition chain, and these higher-ups must also understand Agile methods if they are to understand what they are waiving. One of our reviewers cited a recent contract using Agile methods, in which they were bounded by an SDR milestone, but obtained approval to have IDRs (Incremental Design Reviews) beyond that time instead of the traditional PDR and CDR cycle. At the recent AFEI Forum on Agile in DoD, acquisition strategies that promote Agile practices via tailoring of regulations and standards were seen as one of the ways that Agile methods could more usefully be employed.12 One of the barriers to this kind of tailoring is the uncertainty of program managers as to whether the desired tailoring will be approved, since these types of tailoring reflect a different approach than is expected by DoD policy makers. In programs that wish to take advantage of the benefits seen by other Agile programs in the DoD, both the government PMO and the contractor developer need to be aware that different skills sets or skill mixes will likely be needed in programs using Agile. Agile takes a lot of strong, focused team and management oversight at the middle and low levels. To achieve the benefits of any of the Agile methods commonly in use, the DoD acquisition organization attempting Agile methods for the first time will have to and skilled in Agile methods relate to increased end-user involvement If the team can stay together, the work of sustaining Agile approaches is usually much less than the effort required to initiate them. These topics are discussed in Section 6, Moving Toward Adoption of Agile in DoD IT Acquisition. 12 NDIA/AFEI. Program, DoD Agile Development Conference. NDIA/AFEI, December 14, 2010, Alexandria, VA. CMU/SEI-2011-TN-002 | 25 3 Adopting New Management and Contracting Practices for Agile Programs In this section, we discuss the characteristics and practices that are generally associated with contracting for and managing Agile projects. The viewpoint we take is primarily that of a project or program manager who is directly involved with oversight of an Agile development team. In an acquisition program, we saw examples where a government employee filled this role, as well as examples where the person in this role was a contractor employee. We also differentiate, where appropriate, managerial behaviors of a manager on the acquisition side who is not directly supervising a development team. The topics address the adoption of Agile using management and contracting practices best suited for use with Agile programs. Practices for continued execution are not specifically addressed in this report. This could be a topic for the future. 3.1 Common Agile Management Traits The interviewees who provided source material for this report uniformly acknowledge that the Agile approach to project execution places demands upon all personnel that differ from other execution environments. The managerial role is uniquely affected by the features of the Agile approach. The Agile program manager has more direct interaction with the development teams than is typical in a development project. This is in no small part due to the flatter organizations that comprise Agile development teams. In addition, the use of iterations demands that the program manager be more aware of and supportive of short-term planning. In large organizations, there may be more than one individual designated to fulfill the span of activities, in effect a management team. Note that in the role descriptions that follow, either multiple people could hold a role, or a single individual can hold one or more of the roles. This section takes inspiration from ideas advanced by Dean Leffingwell, then alters and expands those ideas to address inserting Agile practices into DoD acquisition [Leffingwell 2008]. 3.1.1 Executing-Side Program Manager13 The managerial role for the organization executing a program exploiting Agile methods is distinguished by traits described below. Leader. The program manager provides leadership and should spend more time with the team than behind the office desk. Consistent contact in this high-touch environment fosters team communication and cohesion. The “trust factor” is essential in the Agile environment, and the ability to delegate important tasks to others is essential. It is very helpful for the program manager to have a personality compatible with these kinds of practices. Coach. The program manager acts as a coach, not a command-and-control supervisor. Instead of telling the team what to do, the coach seeds the team with ideas and allows the team to solve the 13 The executing-side manager could be a development contractor or part of an organic government team, such as an Air Logistics Center team. CMU/SEI-2011-TN-002 | 26 problem on its own. For instance, the coach might ask, “Have you thought about how to do this better?” This departure is driven by three features of this project environment: exposed to it before. people, and require less traditional supervision. Expeditor. The program manager must be vigilant in establishing an environment that fosters successful execution of individual iterations and the overall project. The discipline of the timeboxed iteration magnifies the effect of organizational and operational impediments. The more intimate involvement of the manager in the day-to-day program execution provides a basis for identifying operational impediments that reduce the probability of success, either through personal observation or by receipt of timely feedback from the development team. Champion. The program manager must deal with upper-level management and stakeholders. For some time, part of the manager’s job will be to provide adequate visibility into an execution model that will be unfamiliar, if not foreign, to upper-level management and other managerial stakeholders. The program manager is likely to find it necessary to act as the translator to effectively communicate with this constituency. In at least one of the programs we interviewed, this was seen as one of the most critical elements of the managerial task. In fact, some have said performing the champion role will be the greatest challenge while adopting Agile development methods within DoD contractor organizations. Ambassador. A key set of stakeholders are the prospective users and subject-matter experts whose sustained participation is necessary for successful execution. The program manager will need to cultivate relationships with these people and their leadership to ensure this participation. These personas should be familiar to most program managers. The difference is the perspective from which the personas are implemented. Specific Agile training or certification would make it much easier to accomplish these roles in the Agile environment. 3.1.2 Acquiring-Side Program Manager For the manager operating on the customer side, inside an acquisition organization, the above personas are still present, but with variations in emphasis. Leader. The leadership role for the acquiring-side manager requires establishing and maintaining relationships with the leadership of the executing organization. The likely geographic distribution (not a particular attribute of Agile projects, but a fairly commonplace occurrence in today’s programs) places additional demands on the acquiring organization. As such, the acquiring-side manager may delegate representative(s) to be on site with the executing organization to maintain adequate visibility into the emerging product(s). Electronic means are also effective but lack the immediacy offered by physical presence. In at least one of the programs we interviewed, the weekly presence of the acquiring-side manager was seen as a great benefit to the development CMU/SEI-2011-TN-002 | 27 team and the end users, because that individual could bring insight from the field and from the policy-making parts of the program organization to the development team in a timely fashion. Coach. The acquiring-side manager serves as a coach for those people who are the direct contacts with the program in execution, such as the testing community, information assurance personnel, operations personnel, etc.. That coaching spans the kinds of interactions the acquiring-side manager wants to have with the development team and the execution-side manager. It also includes defining the nature of the information and metrics the acquiring-side manager wishes to receive. The acquiring-side manager has a direct stake in the nature and quality of the interaction between subject-matter experts and the development team, so the coaching role extends there as well. Much of this coaching will involve helping existing personnel make the transition to the fast-tempo, high-interaction environment that typifies Agile projects. Expeditor. The acquiring-side manager has a significant challenge in efficient deployment of the people directly interacting with the development team and its management. For DoD projects, the norm for larger programs is that the development team will be geographically dispersed. Identification of the best distribution of the available staff will be an ongoing challenge for the acquiring-side manager. Securing appropriate status information that does not unduly interfere with the tempo of Agile development will be a matter of negotiation and establishment of trust between the acquiring manager and the execution manager, as well as the staff doing the day-today work. In addition, the norm is that end users and developers do not have much, if any, direct interaction. Finding and getting access for developers to the right end users in a timely fashion within a culture accustomed to separating these two groups is a challenge for DoD teams using Agile methods. Champion. The acquiring-side manager is responsible for maintaining buy-in by external funders and stakeholders. It is unlikely that these stakeholders will be familiar with the dynamics of Agile projects, which places an additional burden upon the acquiring-side manager to provide a portrayal of project status and accomplishments that is accurate and to bridge the cultural gap. In addition, the champion removes obstacles, rather than beating up the contractor for every risk that pops up or retracting award fees. As we said about the executing-side manager, some have said performing the champion role will be the greatest challenge while adopting Agile development methods within the DoD. Ambassador. The acquiring-side manager must ensure the appointment of end users or subjectmatter experts to work with the developers. These could be proxies if actual end users are not available. CMU/SEI-2011-TN-002 | 28 3.1.3 Product Owner A separate but equally important management role for the acquiring side is the product owner. The product owner will Thus, one of the product owner’s roles includes adjudicating conflicting requests for change. The product owner is responsible for the mechanism that ensures that conflicting user requested changes are resolved and that the system does not stray from its vision through a thousand little changes. 3.2 Lessons Learned Implementing Agile Given the above management behaviors that are needed for successful management of Agile projects, there are some lessons learned from our interviews characterized in Table 1 that particularly focus on management issues. We will discuss lessons in team building, increments/iterations in the larger scheme of the project, metrics, and geographic distribution. 3.2.1 Incentivizing Teams A manager’s role in team building, whether on the acquisition or execution side, is an important one and is reflected primarily in how the manager establishes trust with the development team and other stakeholders, and in the behaviors that the manager chooses to reward or punish. Honesty and open communication were key attributes for the manager that we heard over and over during interviews. For example, in an Agile project, one of the goals is to understand the team’s velocity with enough accuracy to plan iterations reliably. When this is achieved, not only does the team tend to deliver on time, they tend to do it without a lot of fuss. Rewarding the team effort that is exemplified by this case is appropriate as it reinforces one of the key tenets of Agile— collaborative teams. However, rewarding individual heroes who work abundant overtime to pull out a delivery, rather than addressing the root cause such as poor estimation of story points, will work against the team’s ability to perform effectively. Many team members said they liked being able to provide estimates that were realistic and see the success of their estimates at the end of the sprint. One reviewer stated that their first Agile implementation had a 50% increase in productivity. In addition, the manager’s annual employee survey showed amazing improvements. This manager gave the team the authority to make decisions and took on the attributes that were mentioned under the executing-side manager in Section 3.1.1. Another aspect of team building that is sometimes difficult for managers experienced in leading traditional projects is giving the team more autonomy in the selection of goals and in the selection and application of rewards. Agile teams told us that they found that the entire team understood CMU/SEI-2011-TN-002 | 29 and worked toward the selected goal. In addition, all team members understood and agreed to the expectations for each iteration. Many managers are not accustomed to allowing the team to decide how it will distribute rewards or to self-organize into the roles that need to be performed to accomplish the project goals. Successful Agile teams that we interviewed all said that a focus on team awards such as team lunches and fun activities provided positive reinforcement. One team also said that 20% of the raise pool was given to the team to allocate. One impediment to facilitating team building in a DoD environment is the common perception that team building exercises are a “waste of taxpayer dollars,” not reimbursable and thus counterproductive. However, forming productive self-supporting teams requires some amount of focused team building. Collaborative, self-organizing teams are a key tenet for Agile. Therefore, a strong argument can be made for the use of team building exercises when forming or even continuing the use of an Agile team. 3.2.2 Mastering the Iteration In Agile projects, the time box for accomplishing a useful unit of work usually refers to a 2-4 week period (iteration) where a small set of the functional requirements (expressed as user stories) will be moved through design into implementation and initial testing. These iterations have a different technical and business rhythm than most traditional projects are accustomed to accommodating and executing. From a management viewpoint in particular, the movement of small elements of functionality/capability through the entire development life cycle in less than a month presents communication issues to middle/upper management accustomed to seeing more of a “complete the requirements, then complete the design, then implement” approach. During the interviews one of the most often-cited benefits of Agile projects, for both end users and development teams, is the ability to accomplish something real in a short time, get feedback, and make course corrections soon enough to affect the overall outcome. Team members and end users get a sense of accomplishment, have an increase in team morale, and see actual usable software at the end of each iteration. The users found that they were getting what they asked for quickly and this encouraged them to continue using the product. Some environments may have constraints such as rigorous configuration management, which can delay delivery to the customer. Even in these circumstances, demonstrations can be done to show the customers what they will be receiving. DoD projects often have external requirements, like air worthiness certification or information assurance certification, that are not as easily accommodated within the iterations.14 Thus, additional time is needed to meet the external requirements. Wherever possible, time between completion of a release’s functionality and delivery to the end user is minimized. The projects we interviewed have used various methods for addressing this. Sometimes they add an iteration at the end of a release cycle to deal explicitly with certification. Sometimes the certification activities are performed outside the development iterations framework altogether. Whenever possible, certification activities are included as tasks within an iteration. Especially when users or user 14 There are myriad commands, services, DoD regulations, guidance, requirements, and reports that need to be considered depending on the project. Examples include DoD Architecture Framework, Standard Financial Information Structure, Federal Finance Management Improvement Act, service test and evaluation agency rules, and DoD Inspector General. CMU/SEI-2011-TN-002 | 30 surrogates are actively involved in the evolution of a capability, the delays that can occur due to external testing or certification, though necessary, may seem to be a hindrance.15 One interviewed program had a hybrid approach to certification. Some of the work was done before and after the iterations and some was done during the iterations. The sprint teams worked with the Information Assurance (IA) group before the iterations to define the latest security rules for their environment based on the latest guidance. Once the environment was defined, the teams would plan for their next iteration(s) within that environment.16 Their plans would be reviewed by the IA team for compliance before the iteration started and after the iteration finished. If at any time during the iteration the development team had questions about staying within the defined IA environment, the IA team would come in to assist. This process was very successful for them and they also passed an external audit of this process. From an acquisition manager’s viewpoint, managing the rhythm of the iterations means negotiating windows of opportunity for planning actors such as user involvement, certification, and independent field evaluation so that those activities will contribute optimally to the tempo of the release. The acquisition manager also has a role in designing the technical milestones review schedule and its contents. The content of the technical milestone reviews have to be correlated to the content of the planned iterations. This particular area is sufficiently challenging that Section 4 is devoted to technical milestones in an Agile project. 3.2.3 Determine Appropriate Metrics The old adage what usually gets measured, gets done is used to advantage in Agile projects. What gets measured in Agile projects, on the execution side, are usually grouped by user stories and epics—groups of related user stories) and the rate at which they are being addressed (typically called the “burndown rate”). While some of these items may never be implemented, this information could be used for trending data. estimate of the complexity of individual stories that can be aggregated and used predictively. This is usually called “velocity” in an Agile project. However, there is a good bit of variation in exactly what is collected and how it is reported within the Agile project. This metric also varies per team, so care must be taken not to misuse or misconstrue the meaning of this metric. It is more appropriate for planning purposes. versus estimated stories for a particular release to the field or end users refactored, do not follow coding standards, and are not supported with sufficient unit tests, 15 The reader can perform an internet search on Microsoft Agile Security Development Life Cycle for an approach to certifications within an Agile life cycle. A detailed discussion of this topic is not included in this technical report. 16 IA and other crosscutting special requirements define the environment in which a product is developed, integrated, and/or tested. They need to be dealt with ahead of the development effort. CMU/SEI-2011-TN-002 | 31 and the amount of code duplication.17 Less technical debt is better. If technical debt is allowed to grow too big; it could lead to unmaintainable code and eventually stop the entire development effort. The overall quality of the product is better with smaller technical debt. Measuring technical debt helps achieve good quality and avoid undesirable results. Most Agile methods are supported by tooling that simplifies the collection of the raw data that goes into establishing the baselines for these measures. Some projects are small enough to use Excel spreadsheets, but most find that either the free tools widely available across the internet or commercially available licensed tools make the collection and use of appropriate measures efficient. For information beyond determining appropriate metrics see Section 5.4.4 which describes Agile release tracking. A note of caution is appropriate for metrics. Within the DoD environment, OSD and the individual services18 use models to justify the life-cycle cost estimates. These models may use function points, RICE (reports, interfaces, conversions, enhancements or extensions) objects, or lines of code. Thus, the metrics would be different from those obtained from the Agile project using stories. Therefore, the program manager would end up keeping at least two sets of metrics by necessity. This is another disconnect (one not addressed further here) that needs to be resolved for the Agile project to run smoothly. As with any measurements, using the data to punish individuals or teams is rarely productive. This is especially true in Agile environments, where this practice goes against Agile principles, where trust is a hallmark of successful projects and appropriate use of metrics to gain insight into the development process is crucial. A special case for measurement that relates to estimation is measurement that supports a basis of estimate. In our section on cost estimation, we will discuss a frequently used measurement method in DoD projects, Earned Value Management, and its application in Agile projects. 3.2.4 Overcoming Challenges with Geographic Distribution of Projects Some agilists insist that collocation is an absolute requirement for successful Agile projects; however, experience in both industry and the DoD programs we spoke with contradict this viewpoint if geographic distribution is managed effectively. In some ways, all the good management advice related to any distributed project applies here: ensure multiple communication pathways, have guidelines for when to move discussions among different communication modes, provide an appropriate amount of face-to-face time to promote cohesive team building, and so forth. In addition, the information radiators,19 which are unique to Agile implementations, provide a good source of communication. Of course, there will be times—such 17 http://software.intel.com/en-us/blogs/2009/05/29/agile-best-practice-3-of-10-measure-and-frequently-repaytechnical-debt/ 18 An OSD model is Cost Assessment and Program Evaluation [CAPE]. For the Army, the Deputy Assistant Secretary of the Army for Cost and Economics (DASA CE] uses the cost model. 19 This term was coined around 2000 by Alistair Cockburn while standing in a Thoughtworks office, looking at all the paper on the walls around him. “Information radiator” refers to a publicly posted display that shows what is going on to people walking by. Information radiators work best when they are big, very easy to see (e.g., not online, generally), and change often enough to be worth revisiting. See http://alistair.cockburn.us/Information+radiator. CMU/SEI-2011-TN-002 | 32 as for briefings to oversight groups—when the team or at least part of the team (PM, prime contractor, and user’s representative) must be collocated. Beyond the guidance that applies to any distributed project, there are some particular issues as described by some of our interviewees that could come up when using particular Agile methods: they need to be distributed, supportive technology like webcams, telepresence software like Skype and GoToMeeting, and desktop sharing software, along with sufficient bandwidth to make it all useful, have been used in some of the programs we talked to. strategy. This division of labor follows the division of functionality, which takes advantage of the “natural” boundaries, and containment found when developing separate functionality. regression testing environments. Often an extra day needs to be added to allow transfer, processing, and return of data (programs, actual user data, test scripts, etc.). Figuring out the right points for movement back and forth of data between teams is sometimes needed to ensure everyone stays productive. for distributed teams. The physical act of moving large amounts of data to a central location for integration proved to be an initial issue for at least one interviewed project. However, in their expeditor role, interviewed managers who manage distributed Agile projects were key resources for teams in getting the right infrastructure and bandwidth for each site. Of course how a program intends to implement continuous integration and regression testing could also have security issues depending on the tools used and the security posture of the program. involved in the project. The program characterizes the conference as “an essential element of their strategic integration of the using community into their development process.” The agenda includes updating everyone on the current state of the product, its user base, release plans, customer testimonials, etc. It is a different type of interaction between the users and the developers, but one that is greatly appreciated by the entire team. Though expensive (rental of conference site, travel, time of participants), the program believes that its motivational value outweighs the cost by a good measure. The overall conference not only provided benefit to the developers in that they meet the users, but the user community also gets to meet the developers and asks questions first hand. to accomplish a specific goal. For example, when merging two companies in two different locations you might deliberately compose teams of people from both locations to start forming a single new company culture. Establishing management behaviors and infrastructure that is tuned to Agile methods is a challenge, but the managers we interviewed found the effort to be worthwhile. Many of these managers took risks with their own managers to protect the Agile culture that they were building. The payoffs in terms of user satisfaction and productivity were unanimously considered CMU/SEI-2011-TN-002 | 33 successful. This “protecting the team and team culture” mentality is a critical part of being an Agile leader.
[psystic-tables id=4]
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]su
