i am going to ask you to mark some work. forst i will give you the marking rubric, then as a second prompt, the work.
the rubric:
Marking Rubric for Research Assignment/Literature Review

Research Skills (20%)

Criteria	Poor (0-5)	Fair (6-10)	Good (11-15)	Excellent (16-20)
Literature Review	Incomplete or poorly conducted literature review with limited sources and/or lack of academic sources.	A basic literature review with some academic sources but lacking depth and analysis.	A well-conducted literature review with a majority of academic sources and thorough analysis.	An outstanding literature review with a strong focus on academic sources, comprehensive analysis, and clear synthesis of information.
Survey Design & Data Collection	The survey is poorly designed, lacks clarity, or has irrelevant questions. Insufficient data collected.	The survey has basic design, but could be improved. An acceptable amount of data collected.	The survey is well-designed, clear, and relevant. A good amount of data collected.	The survey is outstanding, well thought-out, and highly relevant. A substantial amount of data collected.

 
Communication Skills (20%)

Criteria	Poor (0-5)	Fair (6-10)	Good (11-15)	Excellent (16-20)
Clarity and Organization	The report is unclear, disorganized, and difficult to follow.	The report has a basic structure, but could be improved for clarity and organization.	The report is clear, well-organized, and easy to follow.	The report is exceptionally clear, well-organized, and easy to follow.
Writing Quality and Grammar	Numerous grammar, spelling, and punctuation errors. Poor writing quality.	Some grammar, spelling, and punctuation errors. Acceptable writing quality.	Few grammar, spelling, and punctuation errors. Good writing quality.	Almost no grammar, spelling, or punctuation errors. Excellent writing quality.

 
Final Report (60%)

Criteria	Poor (0-10)	Fair (11-20)	Good (21-30)	Excellent (31-40)	Outstanding (41-50)
Abstract	Incomplete or poorly written abstract that does not summarize the research effectively.	A basic abstract that provides a general overview of the research, but could be improved.	A well-written abstract that effectively summarizes the research.	An excellent abstract that provides a comprehensive and clear summary of the research.	An outstanding abstract that is concise, clear, and highly effective in summarizing the research.
Introduction	Incomplete or poorly written introduction with unclear rationale and objectives.	A basic introduction with a general background and objectives, but could be improved.	A well-written introduction with clear rationale, background, and objectives.	An excellent introduction that provides a comprehensive and well-structured overview of the research.	An outstanding introduction that is engaging, concise, and highly effective in setting the context of the research.
Literature Review	Incomplete or poorly conducted literature review with limited sources and/or lack of academic sources.	A basic literature review with some academic sources but lacking depth and analysis.	A well-conducted literature review with a majority of academic sources and thorough analysis.	An excellent literature review with a strong focus on academic sources, comprehensive analysis, and clear synthesis of information.	An outstanding literature review that demonstrates exceptional understanding and synthesis of relevant literature.
 
Methodology	Incomplete or poorly described methodology with unclear survey design, data collection, and analysis.	A basic methodology section that describes survey design, data collection, and analysis, but could be improved.	A well-written methodology section with clear descriptions of survey design, data collection, and analysis.	An excellent methodology section that provides a comprehensive and well-structured description of the research process.	An outstanding methodology section that demonstrates exceptional understanding and execution of the research process.
Results	Incomplete or poorly presented results with unclear data analysis.	A basic presentation of results with some data analysis, but could be improved.	A well-presented results section with clear data analysis.	An excellent results section with comprehensive data analysis and clear presentation.	An outstanding results section that demonstrates exceptional understanding and presentation of the data analysis.
Discussion	Incomplete or poorly written discussion with unclear or irrelevant insights.	A basic discussion that provides some insights, but could be improved.	A well-written discussion with relevant and insightful analysis.	An excellent discussion that provides a comprehensive and well-structured analysis of the research findings.	An outstanding discussion that demonstrates exceptional understanding and synthesis of the research findings.
 
Conclusion	Incomplete or poorly written conclusion that does not summarize the research effectively.	A basic conclusion that provides a general summary of the research, but could be improved.	A well-written conclusion that effectively summarizes the research.	An excellent conclusion that provides a comprehensive and clear summary of the research.	An outstandingconclusion that is concise, clear, and highly effective in summarizing the research and its implications.
References	Incomplete or poorly formatted reference list with limited or inappropriate sources.	A basic reference list with an acceptable number of sources, but could be improved in formatting or source selection.	A well-formatted reference list with a majority of academic sources and proper citation style.	An excellent reference list with a strong focus on academic sources, comprehensive coverage, and consistent citation style.	An outstanding reference list that demonstrates exceptional understanding of academic sourcing and citation practices.
Appendices	Incomplete or poorly organized appendices with irrelevant or missing documents.	A basic set of appendices with some relevant documents, but could be improved in organization or content.	A well-organized set of appendices with relevant documents that support the research.	An excellent set of appendices with comprehensive and well-structured supporting documents.	An outstanding set of appendices that demonstrates exceptional understanding of the role and presentation of supporting documents.
Total Score: ______ / 100


the work:

 
Contents
Literature Review	2
1 Introduction	2
2 The Inception of Agile	2
3 Investigation of methodologies	2
Conclusion	3
Business Survey	4
Final Report	5
Bibliography	6

 
Literature Review

1 Introduction
Agile as a methodology began as a discussion at a ski resort in Utah, wherein seventeen IS (information systems) professionals came together to evaluate the state of product development in the software industry. Collectively, they produced the Agile Manifesto (Beck et al., 2001), a list of twelve principles that outlined their thoughts on how product development should be conducted. This list was succinct in its wording, and broad in scope leading many to see the application of this new approach to their own projects. Unfortunately, the breadth and lack of specificity also meant the manifesto is open to interpretation, leading to somewhat of a dilution of the meaning of “agile” (Kuhrmann et al., 2022). This can even be seen among the authors of the Agile Manifesto who have published several similar, yet distinct means to handle agile style development. (Beck, 2000; Cockburn, 2004; Schwaber and Beedle, 2002). This study will seek to distil what agile means to the modern developer by reviewing where the methodology came from, how agile methodologies differ, and how agile is implemented in the modern development cycle using industry examples.
2 Agile as a framework
Agile at its origin follows twelve principles, as given by the Agile Manifesto (Beck et al., 2001):
1.	Continuous delivery of valuable software.
2.	Accept change at any point in development.
3.	Deliver frequently.
4.	Businesspeople and developers’ work should be integrated.
5.	Management should trust developers to produce work.
6.	Discussions should be face-to-face.
7.	Progress is gauged through volume of working code.
8.	Development should be sustainable.
9.	Technical excellence and good design should be upheld.
10.	Focus on simplicity.
11.	Teams should be self-organized.
12.	Evaluations should be regular, and properly adhered to.
These points outline what agile is and should be reference point for any conversation on agile. It is worth noting that at no point in this manifesto do the authors outline a structure for how agile should be conducted. As such, it can be raised that there is no true agile methodology, but rather a framework wherein methodologies that are agile in nature can be developed to suit the needs of the project. This leads on to the following section wherein such methodologies (hence to be called Agile methodologies), will be explored in terms of their adherence to the ideals of the manifesto, to compare what is labelled as agile against what it was designed to be.
3 Investigation of methodologies
There are several methodologies seen to be agile in the modern Information Systems world. Extreme Programming (XP)(Beck, 2000), Crystal (Cockburn, 2004), Scrum (Schwaber and Beedle, 2002; Takeuchi and Nonaka, 1986), Feature-driven development (Palmer and Felsing, 2002), and Lean (Cook and Semouchtchak, 2004). These five methodologies are some of the most common approaches seen to be agile. As each methodology is described, they will be evaluated for their successes and failures, both in terms of their adherence to agile ideals, and their structural soundness.
3.1 Extreme Programming (XP)
Extreme programming (also written as eXtreme Programming or just XP), is a methodology produced by one of the authors of The Agile Manifesto Kent Beck. The structure of the methodology involves evaluating the most important features of a project, and cycling through a process of planning, discussion and development (Wells, 2009). Pair programming is encouraged to promote technical excellence and face-to-face discussion. Furthermore, the methodology encourages listening to feedback and having “courage” in face of criticism, to boost the acceptance of change in a project. Systematic review of this methodology by Shrivastava et al. (2021) found that Extreme Programming methodologies resulted in software with a “low fault rate” as problems encountered while developing were viewed as “a medium to acquire skills,” rather than failings. This likely contributed to the motivation observed by Shrivastava and their team.
3.2 Crystal development
Crystal development, much like agile, is less of a methodology on how to handle the individual steps in a project, but a framework for small size teams to rationalise how to organise and being to structure their own workspace. Cockburn (2004) recommends a process called “methodology shaping, wherein a project manager evaluates the experiences of the team members and collates a system that suits the strengths of the team afforded from their experience. For example, if a team has a more individualistic traits, the manager might suggest that more intensive documentation is necessary, such that information can pass easily between individuals who perhaps do not work well in programming situations. Given the nature of this design, wherein structure is inherently undefined and malleable, the study of Crystal style development as a methodology is complex, and underexplored. However, research by Tripp, Rienemschneider and Thatcher (2016) demonstrates that the higher the degree of agility, that is flexibility in a given project, the higher the degree of job satisfaction. Given that this system brings the concept of self-organising teams to the forefront of consideration during early project design stages, it’s clear to see why this style would be popular among developers. Mangers, and new developers to the team, may find this structure unwelcoming however, as the lack of focus on documentation, and freedom to the team could lead to disorganization. 
3.3 Scrum
Scrum is a four-stage agile methodology that’s designed to follow a cyclical flow, akin to the flow of game states in Rugby (Takeuchi and Nonaka, 1986; Schwaber and Beedle, 2002). After the initial creation of the project, the four step cycle is:
-	Planning
-	Development
-	Review
-	Retrospective
The review, retrospective and planning stages, take place during a daily “scrum” which is a standing meeting wherein team members come together to discuss the progress of the project and seek help on issues they may have encountered the previous day. This structure builds a strong understanding of how the team is progressing, as each member is fully aware of how each workday will be laid out, and they hear how production in other areas is progressing.
3.4 Feature-Driven development
Feature-Driven development (FDD) is a heavier methodology compared to the others discussed in this review, as it recommends a higher degree of documentation. Palmer and Felsing (2002) suggest that a team should outline the project scope accurately at the inception of the project to decrease the impact of common agile problems like scope creep as explored by Aizaz et al. (2021), who describe scope creep as being a key element in the downfall of many development projects. This methodology focuses then on building the outlines features one at a time, until the project is fulfilled. This goal oriented philosophy lends itself to complex projects with interlocking features, and helps reduce confusion as the project expands through development.
Modern Agile Overview
In the current realm of software development, intense globalisation and competition has been driving for high-output development whereby new features can be quickly applied in order to keep a product relevant in a world governed by dopamine (Macit, Macit and Güngör, 2018), with examples in social media development, app development, and games development. Following games development, we can see how agile methodologies reflect the current cycle of consumerism. Fortnite and Overwatch 2 are key examples of iterative design cycles, where existing models are now recursively updated to add new content before previous elements have time to grow stale for users (Keighley, 2018). This method is highly energy consuming, however, and maintaining focus on a growing and evolving cycle, can be to the detriment of other projects as shown by Blizzard cancelling Overwatch 2’s “player versus environment” style gameplay as it took too much away from the main game to make production worthwhile (Blizzard Entertainment, 2023), which shows how agile methodologies are effective, but can require a high level of focus to continue to be sustainable.

Limitations
This review evaluates many processes from an agile perspective, but it powerfully important to note that the agile perspective, while currently viewed as the most effective framework for software development, there may be other frameworks that provide a more effective style for software development. Hence, structures or behaviours criticised in this review may be beneficial in another situation or style.
Conclusion
Agile as shown in its initial conception, is a set of ideals, and not truly a methodology. Methodologies that spawned from this set of ideals, and practices within these methodologies can all be agile provided that they follow the concept outlined by the Agile Alliance in that ski resort in Utah. Furthermore, this review has shown that adherence to a given methodology can be to the detriment of other elements in a project or company. Kuhrmann et al. (2022) concluded that agile has a wide range of definitions in a modern context, and it is the conclusion that of this review that truly agile development should not follow one methodology, but meet the needs of the project as a whole, both pre-emptively, and as new issues arise throughout the project.
 
Business Survey 

This section of the report is dedicated to the design and use of a survey to investigate the use of agile methodologies in local business. Participants in the study were found using linkedin, and were asked if they would be willing to participate in a study for a class project. Thirty-one individuals were asked to participate, twenty-one of whom were happy to participate, and 10 of whom did not reply to correspondence.

The questions asked we as follows:

1.	What is your job title?
2.	What Information Systems area do you work in?
3.	What does your job involve?
4.	To your knowledge, is agile a part of your daily work? (Yes or No answer)
o	If not, do you think your workplace would benefit from following agile methodologies?
o	If yes, what agile methodology do you use and how does it help your work?
5.	Would you describe the projects your work on as flexible to change? (YES or NO answer)
6.	How often do you meet with a representative of the customer for your project?
7.	How often do you reflect on team efficacy?
8.	How do you evaluate progress in the projects you develop?
9.	Do you have stand up meetings, and how often do you have them?
10.	Do you like stand-up meetings?
These questions were designed to discover how likely certain jobs were to use an agile work style, to evaluate if they enjoyed the process, and weather or not they felt it helped the to work process. 
Data Analysis
Frequency of Type
Figure one and Figure Two shows the frequency of types of programmers who responded to the study. As software developers, and software engineers are the highest rate of responders. 
This graph does not dive us direct insights into agile in the workplace, but will help contextualise the data further into this study.


Frequency of methodology








In Figure 3 the frequency of different methodologies is compared. Where any responder referred to agile methodologies but did not name a specific structure their answer was simplified to “agile,” to reflect their meaning. It’s possible they were using a Crystal style of agile whereby a system is designed explicitly for a project.
Regardless, here we can see Scrum and Kanban are the most popular agile methodologies responders found that these methodologies gave them a great deal of focus, and team spirit. 
It is worth noting that that non-agile responses are highly represented in this graph style, but the ratio of agile to non-agile  is 16:5, making it clear that agile was much more popular than non-agile methodologies in this study.
Stand-up meetings
 
Here, Figure 4 shows that software developers were less likely to enjoy stand up meetings than other types of developer. It is probable that due to the low sample size of this study the numbers of other kinds of developers that do not like stand-up meetings. Further studies should consider a larger number of developers in their studies and cater to a wider range of individuals. 
Bibliography
Aizaz, F., Khan, S.U.R., Khan, J.A., Ur-Rehman, I. and Akhunzada, A. (2021). An Empirical Investigation of Factors Causing Scope Creep in Agile Global Software Development Context: A Conceptual Model for Project Managers. IEEE Access, 9, pp.109166–109195. doi:https://doi.org/10.1109/access.2021.3100779.

Beck, K. (2000). Extreme Programming Explained: Embrace Change. [online] Google Books. Addison-Wesley Professional. Available at: https://books.google.co.uk/books?hl=en&lr=&id=G8EL4H4vf7UC&oi=fnd&pg=PR13&ots=jbAHxvnSun&sig=u-B6kgdaU57rS7p5fPmX8-i3P14&redir_esc=y#v=onepage&q&f=false [Accessed 20 May 2023].

Beck, K., Grenning, J., Martin, R.C., Beedle, M., Highsmith, J., Mellor, S., van Bennekum, A., Hunt, A., Schwaber, K., Cockburn, A., Jeffries, R., Sutherland, J., Cunningham, W., Kern, J., Thomas, D., Fowler, M. and Marick, B. (2001). The Agile Manifesto. [online] Agilemanifesto.org. Available at: https://agilemanifesto.org/principles.html.

Blizzard Entertainment (2023). Overwatch 2 Dev Chat - Creating Starwatch, PvE Updates, & The 2023 Roadmap - playoverwatch on Twitch. [online] www.twitch.tv. Available at: https://www.twitch.tv/videos/1821513814 [Accessed 20 May 2023].

Cockburn, A. (2004). Crystal Clear Preface Crystal Clear A Human-Powered Methodology For Small Teams, including The Seven Properties of Effective Software Projects.

Cook, J. and Semouchtchak, V. (2004). Lean Object-Oriented Software Development. 69(2), p.12.

Cooper, R.G. and Sommer, A.F. (2019). New-Product Portfolio Management with Agile. Research-Technology Management, 63(1), pp.29–38. doi:https://doi.org/10.1080/08956308.2020.1686291.

Keighley, G. (2018). Fortnite Developer Interview. [online] www.youtube.com. Available at: https://www.youtube.com/watch?v=iP9Ajqza6lA&t=89s [Accessed 20 May 2023].

Kettunen, P. (2009). Adopting key lessons from agile manufacturing to agile software product development—A comparative study. Technovation, 29(6-7), pp.408–422. doi:https://doi.org/10.1016/j.technovation.2008.10.003.

Kuhrmann, M., Tell, P., Hebig, R., Klunder, J., Munch, J., Linssen, O., Pfahl, D., Felderer, M., Prause, C.R., MacDonell, S.G., Nakatumba-Nabende, J., Raffo, D., Beecham, S., Tuzun, E., Lopez, G., Paez, N., Fontdevila, D., Licorish, S.A., Kupper, S. and Ruhe, G. (2022). What Makes Agile Software Development Agile? IEEE Transactions on Software Engineering, 48(9), pp.3523–3539. doi:https://doi.org/10.1109/tse.2021.3099532.

Macit, H.B., Macit, G. and Güngör, O. (2018). A RESEARCH ON SOCIAL MEDIA ADDICTION AND DOPAMINE DRIVEN FEEDBACK. Mehmet Akif Ersoy Üniversitesi İktisadi ve İdari Bilimler Fakültesi Dergisi, [online] 5(3), pp.882–897. doi:https://doi.org/10.30798/makuiibf.435845.

Palmer, S.R. and Felsing, J.M. (2002). A practical guide to feature-driven development. Upper Saddle River: Prentice-Hall Ptr.

Perez, L. (2018). Blizzard’s production methodology | Game Production. [online] Available at: https://leonardperez.net/blizzards-production-methodology/.

Schwaber, K. and Beedle, M. (2002). Agile Software Development with Scrum. Pearson.

Shrivastava, A., Jaggi, I., Katoch, N., Gupta, D. and Gupta, S. (2021). A Systematic Review on Extreme Programming. Journal of Physics: Conference Series, 1969(1), p.012046. doi:https://doi.org/10.1088/1742-6596/1969/1/012046.

Takeuchi, H. and Nonaka, I. (1986). The new new product development game. Journal of Product Innovation Management, 3(3), pp.205–206. doi:https://doi.org/10.1016/0737-6782(86)90053-6.

Tripp, J., Rienemschneider, C. and Thatcher, J. (2016). Job Satisfaction in Agile Development Teams: Agile Development as Work Redesign. Journal of the Association for Information Systems, 17(4), pp.267–307. doi:https://doi.org/10.17705/1jais.00426.

Wells, D. (2009). Extreme Programming: A Gentle Introduction. [online] Extremeprogramming.org. Available at: http://www.extremeprogramming.org/.
‌