[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"doc-seo-239720-105":3,"detail-sidebar-cat-1-en-105":81,"doc-detail-239720-en":126},{"code":4,"msg":5,"data":6},0,"ok",{"site_id":7,"language":8,"slug":9,"title":10,"keywords":11,"description":12,"schema_data":13,"social_meta":74,"head_meta":76,"extra_data":78,"updated_unix":80},105,"en","agile-software-development-approach-for-ad-hoc-it-projects-scrum-adaptation-for-volatile-teams","Agile software development approach for 'ad-hoc' IT projects - Scrum adaptation for volatile teams","","Restrictive Scrum assumptions make traditional effectiveness questionable when projects deviate from typical execution conditions. The study presents an adapted software development approach for academic and commercial IT projects hindered by unsystematic participation of project members and unstable internal communication. ‘Ad-hoc’ settings increase both project management complexity and the need to preserve end-product quality. Multicyclic action research guides modifications to Sprint practices and documentation to streamline knowledge sharing.",{"@graph":14,"@context":73},[15,34,56],{"@type":16,"itemListElement":17},"BreadcrumbList",[18,23,27,31],{"item":19,"name":20,"@type":21,"position":22},"https://docshare.wps.com","Home","ListItem",1,{"item":24,"name":25,"@type":21,"position":26},"https://docshare.wps.com/template/","Template",2,{"item":28,"name":29,"@type":21,"position":30},"https://docshare.wps.com/template/presentations/","Presentations",3,{"item":32,"name":10,"@type":21,"position":33},"https://docshare.wps.com/template/agile-software-development-approach-for-ad-hoc-it-projects-scrum-adaptation-for-volatile-teams/239720/",4,{"url":32,"name":10,"@type":35,"image":36,"author":41,"headline":10,"publisher":44,"fileFormat":47,"inLanguage":8,"description":12,"dateModified":48,"datePublished":49,"encodingFormat":47,"isAccessibleForFree":50,"interactionStatistic":51},"DigitalDocument",{"url":37,"@type":38,"width":39,"height":40},"https://docshare.wps.com/thumbnails/agile-software-development-approach-for-ad-hoc-it-projects-scrum-adaptation-for-volatile-teams/239720.png","ImageObject",442,249,{"name":42,"@type":43},"Gelato","Person",{"url":19,"name":45,"@type":46},"DocShare","Organization","application/pdf","2026-11-03","2026-09-11",true,{"@type":52,"interactionType":53,"userInteractionCount":55},"InteractionCounter",{"@type":54},"ViewAction",11,{"@type":57,"mainEntity":58},"FAQPage",[59,65,69],{"name":60,"@type":61,"acceptedAnswer":62},"Why is standard Scrum considered difficult for 'ad-hoc' IT projects?","Question",{"text":63,"@type":64},"Standard Scrum relies on restrictive, precise conditions such as regular daily meetings, stable sprint constraints, and consistent team presence. It also pressures teams to deliver results quickly, which can undermine software quality in volatile cooperation settings.","Answer",{"name":66,"@type":61,"acceptedAnswer":67},"What major changes does the study propose to Sprint implementation?",{"text":68,"@type":64},"The approach evolves Daily Scrum into Weekly Scrum, allows extending Sprint length, and permits switching team members during a Sprint when deadlines fail. It also ensures at least two team members share responsibility for a single Product Backlog Item at all times.",{"name":70,"@type":61,"acceptedAnswer":71},"How does the approach handle progress tracking compared with Burndown Charts?",{"text":72,"@type":64},"It excludes the Burndown Chart and instead relies on Development Team members updating their working time to support knowledge and tracking under the project’s volatility.","https://schema.org",{"og:url":32,"og:type":75,"og:title":10,"og:site_name":45,"og:description":12},"article",{"robots":77,"canonical":32},"index,follow",{"doc_id":79,"site_id":7},239720,1791742379,{"code":4,"msg":82,"data":83},"success",[84,87,92,97,102,107,112,117,122],{"id":55,"doc_module":22,"doc_module_name":25,"category_name":29,"show_sort_weight":85,"slug":86},90,"presentations",{"id":88,"doc_module":22,"doc_module_name":25,"category_name":89,"show_sort_weight":90,"slug":91},12,"Resumes",80,"resumes",{"id":93,"doc_module":22,"doc_module_name":25,"category_name":94,"show_sort_weight":95,"slug":96},14,"Invoices",70,"invoices",{"id":98,"doc_module":22,"doc_module_name":25,"category_name":99,"show_sort_weight":100,"slug":101},15,"Posters",60,"posters",{"id":103,"doc_module":22,"doc_module_name":25,"category_name":104,"show_sort_weight":105,"slug":106},16,"Social Media",50,"social-media",{"id":108,"doc_module":22,"doc_module_name":25,"category_name":109,"show_sort_weight":110,"slug":111},17,"Forms",40,"forms",{"id":113,"doc_module":22,"doc_module_name":25,"category_name":114,"show_sort_weight":115,"slug":116},18,"Letters",30,"letters",{"id":118,"doc_module":22,"doc_module_name":25,"category_name":119,"show_sort_weight":120,"slug":121},21,"Paper Templates",5,"papers-templates",{"id":123,"doc_module":22,"doc_module_name":25,"category_name":124,"show_sort_weight":4,"slug":125},158,"General","general-158",{"code":4,"msg":82,"data":127},{"doc_id":79,"user_id":128,"nickname":42,"user_avatar":129,"doc_module":22,"category_id":55,"category_name":29,"doc_title":10,"doc_description":12,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":55,"is_deleted":4,"is_public":22,"is_downloadable":22,"audit_status":22,"page_count":135,"language":136,"language_code":8,"site_id":7,"html_lang":8,"table_of_contents":137,"faqs":138,"seo_title":139,"seo_description":12,"update_tm":140,"read_time":141},19241457091524,"https://us-avatar.wpscdn.com/davatar_276721f389ce27ea32af1340a28f341c","Agile software development approach for 'ad-hoc' IT projects  \nMichał Kuciapski  \nDepartment of Business Informatics, University of Gdansk  \nPiaskowa 9, 81-864 Sopot Poland [michal.kuciapski@ug.edu.pl](michal.kuciapski@ug.edu.pl)  \nBartosz Marcinkowski  \nDepartment of Business Informatics, University of Gdansk  \nPiaskowa 9, 81-864 Sopot Poland [bartosz.marcinkowski@ug.edu.pl](bartosz.marcinkowski@ug.edu.pl)  \nAbstract:  \nRestrictive Scrum assumptions make the effectiveness of this approach debatable in projects deviating from typical execution conditions. This article delivers a comprehensive software development approach for both academic and commercial Information Technology (IT) projects effectuated by teams that are hampered by significantly unsystematic participation of project members and mercurial internal communication. The nature of ‘ad-hoc’ projects imposes another level of difficulty in terms of both managing the conduct of such a project and ensuring the quality of the end product. Multicyclic action research enabled a gradual adaptation of the Scrum approach to support such project conditions. This study introduces major alterations to Sprint implementation and minor enhancements within the documentation process to streamline knowledge sharing among Development Team members. Proposed key alterations include the evolution of Daily Scrum towards Weekly Scrum, the possibility of extending Sprints length, the eventuality to switch team members during Sprint due to substantial failure to meet deadlines, having at least two team members responsible for a single Product Backlog Item (PBI) at all times, as well as exclusion of Burndown Chart in favor of Development Team members updating their working time. Positive validation of enhancements in mixed settings confirms that the generic Scrum framework can be adapted to support highly volatile projects. The proposed approach is suitable not only for carrying out software development initiatives that rely heavily on the skills of external experts and/or volunteers. It also supports traditional Scrum teams that seek to reduce their exposure to risk arising from organizational changes.  \nKeywords:  \nproject management; agile; software development; systems engineering; Scrum; adaptation.  \nDOI: 10.12821/ijispm110402  \nManuscript received: 15 April 2023  \nManuscript accepted: 5 August 2023  \nCopyright © 20 2 3 , IJISPM . General permission to republish in print or electronic forms, but not for profit, all or part of this material is granted , provided that the International Journal of Information Systems and Project Management (IJISPM ) copyright notice is given and that reference made to the publication , to its date of issue, and to the fact that reprinting privileges were granted by permission o f IJISPM .  \n1. Introduction  \nChallenges that most modern business entities face when launching Information Technology (IT) projects, put pressure on both global development teams and management staff to adapt novel techniques, approaches , and tools [1] – and thus decrease failure rates. Leveraging the strengths of various existing processes more effectively owing to the adaptability of Agile Methods (AMs) contributed to establishing the dominance of the latter [2] . That said, the leading agile approach to project management, i.e. Scrum, necessitates a fairly restrictive and precise application of underlying principles throughout the development process [3] – which often cannot be facilitated by companies [4] . Daily meetings at a specific time and duration, minimum and maximum constraints on the duration of individual Sprints, presence at meetings required from all team members as well as significant experience in implementing projects using this framework required from local programming teams, in fact, constitute the underlying problem behind the nonnegligible share of IT projects. Moreover, being obliged to deliver demonstrable results in a short timeframe, regardless of their s","cbCailqtdukDJPUg","https://ap.wps.com/l/cbCailqtdukDJPUg","pdf",1152835,24,"English","# Introduction\n## Motivation for adapting Scrum\n# Methods\n## Multicyclic action research\n# Proposed Scrum adaptations\n## Sprint practice changes\n## Documentation and knowledge sharing\n## Burndown chart replacement\n# Validation and suitability\n## Positive validation in mixed settings\n## Applicability to volatile and changing teams","[{\"question\":\"Why is standard Scrum considered difficult for 'ad-hoc' IT projects?\",\"answer\":\"Standard Scrum relies on restrictive, precise conditions such as regular daily meetings, stable sprint constraints, and consistent team presence. It also pressures teams to deliver results quickly, which can undermine software quality in volatile cooperation settings.\"},{\"question\":\"What major changes does the study propose to Sprint implementation?\",\"answer\":\"The approach evolves Daily Scrum into Weekly Scrum, allows extending Sprint length, and permits switching team members during a Sprint when deadlines fail. It also ensures at least two team members share responsibility for a single Product Backlog Item at all times.\"},{\"question\":\"How does the approach handle progress tracking compared with Burndown Charts?\",\"answer\":\"It excludes the Burndown Chart and instead relies on Development Team members updating their working time to support knowledge and tracking under the project’s volatility.\"}]","Agile software development approach for 'ad-hoc' IT projects - Scrum adaptation for volatile teams | PDF",1789152377,8]