Software Development Using Agile And Scrum In Distributed .
Software Development Using Agile and Scrum in Distributed TeamsYoury KhmelevskyXitong LiStuart MadnickWorking Paper CISL# 2017-02February 2017Cybersecurity Interdisciplinary Systems Laboratory (CISL)Sloan School of Management, Room E62-422Massachusetts Institute of TechnologyCambridge, MA 02142
Software Development Using Agile and Scrum inDistributed TeamsYoury Khmelevsky Xitong LiStuart MadnickComputer Science, Okanagan CollegeKelowna, BC CanadaEmail: ykhmelevsky@okanagan.bc.caÉcole des Hautes EtudesCommerciales de Paris, FranceEmail: lix@hec.frSloan School of ManagementMassachusetts Institute of TechnologyCambridge, MA USAEmail: smadnick@mit.edu AlsoAffiliated with UBC Okanagan, CanadaAbstract—Agile software development practices, like Scrum,that allow teams to focus on delivering product and improvedcommunication has made it one of the easiest and best softwaredevelopment techniques. On the other hand, such agile methodshave been designed for collocated software development and arethus not directly applicable to distributed agile development.In this paper, we present findings from case studies and reallife distributed Agile and Scrum projects conducted since 2011,as well as the challenges and benefits the case projects reportedand unique lessons learned from them.I.I NTRODUCTIONA study that involved 58 practitioners in 23 organizationsover 4 years reported two interesting pieces of data [1]: (1)self organizing scrum teams naturally perform a balancing actbetween freedom and responsibility; cross functionality andspecialization, and continuous learning and iteration pressure,and (2) self organizing teams have its members assume somewell defined roles, such as mentor, coordinator, translator,champion, promoter and terminator. They are not prescribedexplicitly as part of any of the agile development philosophies,but they arise as part of successful use of the methodology [1].In 1995, Sutherland and Schwaber presented the first paperdescribing the Scrum methodologies [2]. They collaboratedduring the following years to merge the writings, experiences,and industry best practices into what is now known as Scrum.Scrum focuses on project management institutions where it isdifficult to plan ahead [3]. Agile software (SW) developmenthas become a popular approach to the engineering of softwaresystems in the commercial world. A project must employ Agiledevelopment methods and must also fit within an Agile productdevelopment system: The development organization must bewilling to practice refactoring, or lose the benefits of AgileSW development. The software itself must be Agile, lendingitself to rapid incremental deliveries and must be architectedaccordingly [4].Dingsoyr et al. [5] in 2012, based on their literature reviewon agile software development, found that there are ”veryfew on the Scrum development process” and explicitly callfor academic research on Scrum. Ramesh et al. [6] in 2006,on the other hand, pointed out that traditional agile methodsrely on informed processes to facilitate coordination, whichis different from what distributed software development traditionally requires (i.e., formal mechanisms for coordination).Therefore, the product provides a unique context for us toconduct a case study that evaluates the applicability of theAgile principles and Scrum practices in a real-world distributedglobal software development (GSD) project and examines theinconsistencies between theoretical assumptions behind Scrumand practical observations. Based on our experiences, we foundthat although the distributed agile development (DAD) was tobe based on ”Twelve Principles of Agile Software” [7], theywere not rigorously used by all members of the team and donot fit well into the global software development (GSD). Partsof the reasons are that ”GSD typically involves stakeholderslocated in different time zones and geographic locations, fromdifferent national and organizational cultures, using differentand, at times, unreliable technologies to collaborate” [8].Such temporal, geographical and socio-cultural distances canresult in significant communication, coordination and controlchallenges that need to be overcome for the benefits of GSDto be realized.In recent publications, we found discussions about Agileat global companies and in distributed teams [9], [10], [11],[12]. Some authors believe, “that if agile is to thrive over thenext 10 years then it not only has to work in a distributedenvironment, but it has to work well in order to deliver themost value to an organization” [9]. The following issues arewidely discussed: Many organizations in local proximity really work indistributed environment. Many organizations don’t have an “utopian situation”,when they have one team, one product owner andone location. It is common to have multi-team, multilocation, multi-business area and multi-time zone (seeSection II and Section III for examples from ourprojects) [9]. In many cases the “Agile process” is really a “Waterscrumfall”, where a “coding factory” model is present.That means you send a code specification and wait forthe code to come back. This is not a true Agile way. The biggest problems are: lack of clear (1) goals; (2)no rationale; (3) absence of context; (4) a high risk ofconfusion during start of the project. Some authors even recommend a de-Agile approachfor the distributed teams [10] by taking out processesthat don’t make sense and tweaking those that needto be modified to suit your needs. In other words,
removing the sense of being distributed (additionalcommunication responsibilities, being open and available). Team size should be from 10 to 15 people and havemix of talent at every location (no centralizing onetype of work at one location) [10]. Keep fairly equal workloads in distributed teams.SWAT (Subjective Workload Assessment Technique)can be used. Pair Programming or show-and-tell hour or at leastregular code review by other team members shouldhappen. Understanding time and cultural differences is crucial.Starting from 2005, agile practices, Scrum and ExtremeProgramming (XP) SW development methodologies were usedwithin capstone and applied research projects with remoteand local industrial clients at Okanagan College (OC) andUniversity of British Columbia Okanagan campus (UBC O)[13], [14]. We were able to employ agile principles in acommercial SW development project.The contribution of this paper consists of practical recommendations, which can be used by other companies thatare planning to use Scrum and/or Agile practices withindistributed projects. In our case study we used related researchpapers and internet publications, but we found inconsistenciesbetween theoretical assumptions and our practical experiences,for example related to special scrum training before the projectbegins (which is almost impossible due to very short projectduration and limited project budget).II.system for about 8–12 months. The Stage 2 was planedmostly for the refactoring, final testing and bugs fixing only.When the project was started, the development team foundinconsistencies between graphical design, list of requirementsand project specification, which was developed in EasternEurope in the past.A. Core Scrum roles and relation to the project team members:”A Development Team is made up of 3-9 people with crossfunctional skills who do the actual work (analysis, design,develop, test, technical communication, document, etc.). TheDevelopment Team in Scrum is self-organizing, even thoughthey may interface with project management organizations(PMOs)” [3].In the case study project: Product Owner - represented by the customer. Development Team: represented by the offshore development team of 3–4 team members and by 3–5customer’s volunteers (and advisers) in Eastern Europefor beta testing, web-site design and developmentsource code audit. Scrum Master — main contractor from the US.Ancillary roles: Stakeholders — the project customer and his advisers/volunteers, which will use the final product in thebusiness environment (from 3 to 5 stakeholders). Managers — contractor and subcontractor managersin the US and Eastern Europe. The project development manager — subcontractor in many cases sharehis role as a development team manager, beta tester,and developer.C ONTEXT OF A C ASE S TUDYThe project teams usually contained team members fromthe US, Canada, Western and Eastern Europe. The projectstructure can be shown in this way: the customers withemployees and volunteers are located in the US, Germanyand Eastern Europe; main SW development contractors arelocated in the US with employees in Canada and sometimes inEastern Europe; the offshore SW Development subcontractorwere located in Eastern Europe or in Canada.A business Case Study project was started in April and wasplanned to be finished in middle of July by using Agile projectdevelopment principles. During the first project developmentweeks, the development team found that the customer wasunable to provide graphical design for all of the elementsof the web-system, which was not included in the projectdevelopment tasks and ”generated” some new ideas ”on thefly” during the project development. In the next followingweeks, developers found many inconsistencies in the projectspecifications and project requirements. Due to such problems,the ”Stage 0” was extended from 2 weeks to almost 1 month.The project team made a decision to use Scrum practicesadditionally to general Agile Manifesto principles, to reducethe project meetings’ time and to improve performance withinteams.Originally the main contractor and offshore developmentteam planned to finish the project in two months in threeiterations (Stage 0 – Stage 2) and then support the finishedB. MeetingsDaily Scrum: The project team scheduled a 15 minutesScrum meeting mostly every day. The project team didn’t havea Daily Scrum meeting only when customer or subcontractorsasked to skip one or two meetings. The team had severalinstances when team members were tired or upset by the highamount of problems generated by this project.During the daily Scrum, the project team discusses thefollowing topics [3]: What have you done since yesterday? What are you planning to do today? Any impediments or stumbling blocks?After the meeting the project team usually had a ProductBacklog Grooming for about 60 minutes or even longer toestimate the existing backlog, refining the acceptance criteriafor individual stories, and breaking larger stories into smallerstories.Scrum of Scrums: Instead of the Backlog groomingmeeting, the team managers could have a Scrum of Scrumson-line by using Skype’s call conference (in later distributedprojects in 2013–2016 we used WebEX as well). It depended
on the project problems and development team performanceand were decided on the Daily Scrum meeting. The durationof the Scrum of Scrums could be up to 1 hour or even 1.5hours, but only customer and designated person from eachteam attended Scrum of Scrums on-line or in person.Sprint planning meeting: At the beginning of the sprintcycle, the project team hold a ”Sprint planning meeting”, butusually informally.Sprint review meeting: At the end of the Stages theproject team had a ”Sprint review meeting”. Sometimes itwas done more often or for longer periods of time, when thedevelopment team had many bugs or mistakes — at the endof a week or even several consecutive days at the end of theStages. The productivity of the project development teamincreased drastically, especially related to many hoursof Skype conferences and discussions. After Scrumimplementation, 1-2 hour online project meetings werereduced to 15-20 minutes Daily Scrums and 30-60minutes Product Backlog Grooming meetings, depends on the project problems. It’s almost impossible to have face-to-face interactions between team members in distributed teams, butregular Sprint/Agile meetings can be done by usingmodern and free VoIP technologies (Skype, WebEx,Google Talk, etc.). If team members are located on different continents,team members, especially a Scrum Master or Mentor/Coordinator, should be ready to work in earlymorning at 6 or 7 am, or late at night from 10 pmto 1 am or even at 2 am and later. We tried to useoptimal time for everybody (for example 9 pm TZ 2and 11 am Pacific Time), but in 1 month we found,that for better project performance we need to createmore comfort working time for the developers (at least5 pm TZ 2) and less comfort time for other teammembers (6 am or 7 am Pacific Time). It’s impossible to have a special ”Proper Scrum training” in the beginning of the project if the team hasnever used Scrum or Agile before, because this willrequire extra time and resources, and will increaseresistance from ”conservative” team members. Thebest approach is to train team members during theDaily Scrum meetings and/or more often sprint reviewmeetings, when everybody could suggest or advisemodifications for the development process. Supportfrom other team members during meetings is crucial. Frequent visits of the development personal fromcollaborating sites are almost impossible. Even oneintercontinental visit can cost a substantial part of theproject budget, which is unacceptable for small ormid-size projects. Multiple communication tools must be used by adistributed team. The stress should be made not onvideoconferencing, but on the project managementand project collaboration tools. In our case we foundthat shifting from verbal communication by Skypeand videoconferencing to even a very simple andfree dotProject and DropBox improved project performance and project communication, especially byusing tickets, tasks, file sharing, meetings’ minutes,meetings’ scheduling and files sharing. Traditionaltelephones were almost never used, but only for localcommunications.Sprint retrospective: All project team members discussedthe past sprint problems, suggested continuous process improvements. It went from 30 minutes to several hours. Themain questions were the following [3]: What went well during the sprint? What could be improved in the next sprint?Project Artifacts: For Product Backlog MS Excel andMS Word documents were used and for the web-site designimages developed in PhotoShop, the DropBox was used aswell. For the Sprint Backlog the dotProject was used initially,but starting from 2014 we used new SW project managementweb based tool Jira; for the Project increments or differentstages of the web-system system the GoDaddy web-hostingwas used additionally to the development versions, hostedin Eastern Europe. Instead of burn down chart the projectteam used a Gantt Chart with %% completion from dotProjector Jira. Later we moved our design, project documentationand project management process to Jira, Confluence, Slack,Bitbucket and Latex. We introduced Bamboo and Jenkinscontinues integration as well.III. L ESSONS L EARNEDIf the subcontractor never used any Agile practices inthe past, the learning curve will take several weeksto months. This learning time is very critical for theproject success and must be completed as soon aspossible with the help of experienced team members.The experienced team members should be ready forresistance from the subcontractor’s team membersagainst of new Agile practices, even if they understand the usefulness of the Agile practices and highprobability of the project success by using Agile. If a team member(s) already used Agile practices suchas XP or Scrum in the past successfully, he/she shouldbe a Mentor and/or Champion/Promoter. In the case study we found a strong resistance fromthe subcontractor’s manager during the first month ofthe project. The project was in a critical situation andthe ”Terminator” role had to be used [1] against thesubcontractor manager. After a few weeks negotiationsthe project went in the right direction again. It isstrongly advised to be ready for conflict situations,especially in the first few weeks of the project.IV.C ONCLUSION AND R ECOMMENDATIONSIn this paper we presented a case study and the followingprojects’ experiences, and lessons learned from distributedprojects on the application of Scrum and Agile practices. Wealso would like to give the following recommendations for theSW development projects in distributed environments:
It must be real collaboration and team work in distributed environment without any cultural barriers (seemore in [9]). In our case almost every one of ourteams in different projects had representatives fromdifferent countries. Different cultures have differentapproaches to the same problems/issues. It must betaken in account.Distributed projects lack the face-to-face communication, but we don’t have any other choice but toreplace it by “rich” communication channels and by“simulation” of high speed high quality face-to-facediscussions. Since 2005 (for more than 11 years) wehave regular face-to-face local meeting, weekly or biweekly telephone/skype/WebEx “rich” meetings withoverseas collaborators as well as regular local meeting,when somebody doesn’t have time for the face-to-facemeeting. We always plan at least 1 week local projectwork per year with our distributed collaborators.Do real agile with overseas or distributed collaboratorsand avoid a “coding factory”. Brainstorming and ideasexchange is crucial in true Agile.[1]Avoid “Agile but” or don’t invent hybrids or “Waterscrumfall”.[3] Scrum is based on Agile, but they are not the same.Scrum is one of the well-know agile approaches only.Some authors believe that Scrum can’t be used for distributed teams, but Agile can. In our many distributedprojects we had situations when we introduced amanager to meet our deadlines and to finish our projecton time and within budget. “Many supporters of agilesee the role of a Project Manager as defunct, anirrelevance – if you are looking to use agile in adistributed context it is a necessity” [9]. “Scrum ofscrums” really doesn’t work and it didn’t work forus in several of our distributed projects. We had tointroduce a Project Management role instead of ScrumMaster and Scrum of Scrum Master in several criticalsituations. Root cause analysis and continuous improvement,inspection and adaption are important for success. Quality control and frequent deliveries are especiallyimportant.R EFERENCES Design and development tools are important. “Poortools and a poor environment can lead to a poorproject” [9]. Provide the right tools and training [10].Some examples: WebEx, Google Docs, Slack, Jira andmany other.Reorganize teams only as a last resort, especially because communication and track of everyone’s progressin a distributed team is more difficult.Our thanks to IBM Education for supporting us with IBMRational SW Architect licenses in student projects, as well asto VMWare, Microsoft and Oracle.[2] Our thank to Amazon Web Services, Inc. for supportingour capstone software engineering and our research projectsby AWS Grants for Research and Education, as well as toAtlassian for supporting us by community licenses for Jiraproject management and Bitbucket cloud tools.Frequent deliveries and daily integration. It’s hard toachieve, but this approach gives the best results.No excuses for starting off a project with incompleteor inaccurate high-level requirements. We’ve seen fake“Agile Gurus”, who tried to convince us that Agiledoesn’t need any planning or any requirements. Lateinstead of early top-level design and high-level requirements create many problems and communicationissues in the team(s), especially a huge waste ofresources and time in the project. User Stories must besupported by additional technical documentation (UseCases, models, diagrams, requirements and specifications).Plan frequent demos and retrospective meetings.ACKNOWLEDGMENTS [4][5][6][7][8][9][10][11][12][13][14]J. Langford and R. Ortega, “Machine learning and algorithms; agiledevelopment.” Commun. ACM, vol. 55, no. 8, pp. 10–11, 2012.J. V. Sutherland and K. Schwaber, “Business object
Software Development Using Agile and Scrum in Distributed Teams Youry Khmelevsky Computer Science, Okanagan College Kelowna, BC Canada Email: ykhmelevsky@okanagan.bc.ca Also Affiliated with UBC Okanagan, Canada Xitong Li Ecole des Hautes Etudes Commerciales de Paris, France Email: lix@hec.fr Stuart Madnick Sloan School of Management Massachusetts Institute of Technology Cambridge, MA USA .
1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18
The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .
Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .
1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma
Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.
Agile Manifesto (Agile Principles) The Agile Manifesto is the foundation of most Agile Software Development methods. It has 4 core values supplemented by 12 Principles. The document was developed in 2001 by a group of 17 pioneer software engineers (www.agilemanifesto.org). Agile Software Development Methods Agile Software .
2. Quality Assurance AND Methods of Agile 3. Metrics of quality AND Agile quality assurance 4. Agile AND Quality 5. Agile Quality AND Software Development 6. Agile quality AND Agile methods The search keywords for agile particulars have been merged by using the Boolean ''OR" operator, which
AGILE TESTING For agile testers, test engineers, test managers, developers, technical leads. Ensure the production of effective and valuable software. Agile Fundamentals Agile Programming Agile Software Design Agile Fundamentals Agile Testing Agile Test Automation ICP CERTIFIED PROFESSIONAL ICP CERTIFIED PROFESSIONAL ICP-PRG CERTIFIED .
