ContentslistsavailableatScienceDirect
The Journal of Systems and Software
journalhomepage:www.elsevier.com/locate/jss
Satisfaction and its correlates in agile software development
Martin Kropp
a, Andreas Meier
b, Craig Anslow
c, Robert Biddle
d,∗aUniversity of Applied Sciences Northwestern Switzerland, Windisch, Switzerland
bZurich University of Applied Sciences, Winterthur, Switzerland
cVictoria University of Wellington, Wellington, New Zealand
dCarleton University, Ottawa, Canada
a rt i c l e i n f o
Article history:
Received 30 November 2018 Revised 23 December 2019 Accepted 10 February 2020 Available online 13 February 2020
a b s t r a c t
Inthispaperweaddressthetopicofsoftwaredevelopmentteammemberssatisfactionwiththeirdevel- opmentprocess.Wepresentanin-depthanalysisoftheresultsofanationwidesurveyaboutsoftware developmentinSwitzerland.We wantedtofindoutifsatisfaction relatestothe applieddevelopment method,and to the useofvarious practices,and impacts onbusiness, teamand software issues. We foundthathighersatisfactionisreportedmorebythoseusingAgiledevelopmentthanwithplan-driven processes.Weexploredthedifferentperspectivesofdevelopersandthosewithamanagementroleand foundahighconsistencyofsatisfactionbetweenAgiledevelopersandAgilemanagement,anddifferences withthoseusingworkingplan-drivenmethods.Wefoundthatcertainpracticesandimpactshavehigh correlationstosatisfaction,andthatcollaborativeprocessesarecloselyrelatedtosatisfaction.Wethen exploredtherelationshipbetweensatisfactionandvariousotherperspectives.Ourresultsinthisanalysis areprincipallydescriptive,butwethinktheycanbearelevantcontributiontounderstandthechallenges foreveryoneinvolvedinAgiledevelopment.
© 2020PublishedbyElsevierInc.
1. Introduction
In the last decade Agile software development methods have been widely used in industry and become mainstream, as re- cent studies show Kropp and Meier (2015); VersionOne (2017). The studies typically report “managementofchanging priorities”,
“faster time to market”, “team morale”, “team productivity” and
“peopledevelopment” astopbenefitsfromperformingAgileprac- tices. While thevery firstprinciple ofthe AgileManifestobegins with“Ourhighestpriorityistosatisfythecustomer...”AgileMan- ifestoSignatories(2001),studiesalsoshowthatAgileteammem- bers themselves report stronger satisfactioncompared with their experience withplan-driven approaches(e.g.WhitworthandBid- dle,2007).However,notmuchisknownaboutthemostpowerful reasons for the satisfaction.We explore potential reasons in this paper.
Weexaminethefollowingresearchquestions:
RQ1:Howdoestheappliedsoftwaredevelopmentmethodre- latetosatisfactionofteammembers?
∗ Corresponding author.
E-mail addresses: martin.kropp@fhnw.ch (M. Kropp), meea@zhaw.ch (A. Meier), craig@ecs.vuw.ac.nz (C. Anslow), robert.biddle@carleton.ca (R. Biddle).
WewantedtofindoutifAgiledevelopmentleadstohighersat- isfactionthantraditionalplan-drivenapproaches.Thisquestionhas alsodrivenearlierresearch,aswediscusslater,thoughsuchinter- est wasmore commonwhen Agile methods were new. We also wanted to findout if the view on satisfactionof management is similartothatofindividualprofessionals.WedefinethetermsAg- ile and plan-driven according to Boehm and Turner Boehm and Turner(2003).
RQ2:Howdoessatisfactioncorrelatetotheappliedpractices?
Mostimportantly,wewantedtofindoutwhichpracticesrelate moststronglytosatisfaction.
RQ3: Does satisfaction depend on the impacts achieved with thedevelopmentmethod?
Wealsowantedtofindoutifandhowsatisfactionrelatestothe resultsachievedwithAgility.Forthiswe wereaskinghow Agility influencescertainbusinessaspects (e.g.time-to-market),teamas- pects(e.g.teammorale),andsoftwareaspects(e.g.softwarearchi- tecture). In thispaper we use the term “impacts” for theseout- comesofaprocess.
Thegoalofouranalysiswasadeeperunderstandingaboutthe effects ofAgile developmentandto get indicatorsabout thehu- manaspectsofAgilesoftwaredevelopment.
https://doi.org/10.1016/j.jss.2020.110544 0164-1212/© 2020 Published by Elsevier Inc.
To addressour research questionswe analyze theresults ofa nationwide study of Agile software development in Switzerland, conductedin 2016. In the study we conducted two independent surveys,oneforcompanyrepresentatives(i.e.typicallyupperman- agement),andanotherforindividualprofessionals.
In the next section, we review earlierwork on satisfaction in softwaredevelopment, especially that witha focus onAgile pro- cesses.Wethenoutlinethenatureofoursurvey,thesourceofour studydata, andthe main results concerning satisfaction.The re- sultsare thenexplored in moredetail, investigatingrelationships inthedatainordertobetterunderstandthepotentialreasonsfor satisfactionordissatisfaction.Inparticular,weexplorehowdevel- opment practices and various impacts relate to satisfaction. We then explore several other issues, including personal experience, stress,andpotentialhindrancestosuccesswithAgilemethods.We thendiscussourresultsandpresentourconclusions.
ThispaperisanextendedversionofonepresentedattheACM International Conference on Evaluation and Assessment in Soft- ware Engineering (EASE), in Christchurch, New Zealand, in 2018 Kroppet al.(2018).The currentpaperhasmoredetail,especially inSection5,whereaswell astechnicalpractices, bothcollabora- tive andplanningpractices are now discussed,with Figs.8b and 8c.InSection 6.3,wenow presentoursurvey resultsabouthin- drances to the development process, with Tables 9 and 10, and Figs.12and13.
2. Relatedwork
The first empirical studyon satisfaction inAgile development wasconductedbyMannaroet al.(2004).Theirfocus wasonEx- tremeProgramming(XP),wheretheysurveyed55XPand67non- XPprofessionalsusingtheGoal-Question-Metrics (GQM)approach (Basili, 1993).Theyfound that satisfactionwasgreater amongXP professionals than others on a number of measures, not only in general, butalso on a variety of specific issues, such as reduced stress,increasedproductivity,andbetterattitude.
In 2006, Melnik and Maurer presented results of a large (n=756)online survey (MelnikandMaurer, 2006), alsobased on theGQMapproach;theyalsodiscussedalargesurveythathadre- centlybeenconducted by Computerworld magazine.Theyapplied statistical inference and found evidence that Agile practitioners were more satisfied than others, and also that more experience withAgile methodsincreasedthat effect.Theyalsoreportedthat theeffectwasfoundbothforprogrammersandmanagers.
In2007,TessemandMaurerpresentedresultsofacasestudyof satisfactioninalargeAgileteamatacompanyproducingsoftware forthepetroleum industry (Tessem andMaurer, 2007). The team usedScrum,butwithsome practices(such aspair-programming) fromXP. Thestudywasbasedoninterviews withteammembers andconsideration of the general Job CharacteristicsModel (JCM) ofHackmanandOldham(1980).Thisstudyalsofoundstrongsup- portforsatisfactionwithAgilemethods,andpointedtoalignment withfiveelementsoftheJCM,includingthepositiveeffectsofau- tonomy,of variety in work, of good communicationwith others, ofsignificanceofthework, andofaddressing “complete” unitsof work(e.g.userstories).
Tripp and Riemenschneiderhaveaddressed the issueof satis- factioninAgiledevelopmentlookingfortheoreticalunderpinnings (Tripp et al., 2016; Tripp and Riemenschneider, 2014). They ex- ploredsatisfactionin Agiledevelopmentwith HackmanandOld- ham’s JCM, taking a quantitative approach to see how well re- sults from an Agile development survey match the model. They firstusedregressionandfactoranalysis(TrippandRiemenschnei- der, 2014). They focused on Coding standards, Daily stand-up, Refactoring,Pairprogramming,Unittesting,Iterativeplanning,and Automatedbuilds.Theydidfindevidencethat theAgilepractices
relate to mostelements ofthe JCM, though interestingly did not findevidenceforthe“autonomy” element.Theirlateranalysisap- pliedthemoresophisticatedapproachofStructuralEquationMod- eling(Trippetal.,2016).TheapproachdistinguishesAgileproject management practices and Agile software-development practices, and suggests how each relates to the JCM. The project manage- mentpracticesincludedwereDailystand-upmeeting,Iterativede- livery,Retrospectives, andBurndown(charts).The softwaredevel- opment practices included were Automated (unit) testing, Auto- mated builds,Continuous integration,Coding standards, Refactor- ingandPairprogramming.Thefindingsofthestudysuggestedthat projectmanagement practices directlyinfluencesatisfaction,soft- waredevelopmentpracticesdosupportsomeelementsoftheJCM, butdonotdirectlysupportsatisfaction.Theauthorshighlightthe interdependence ofthepractices, andalso considerthat the “au- tonomy” element of the JCM may not align well with the team emphasisinAgiledevelopment.
This interplay of “technical” and“collaborative” practices also features in studies of other aspects of Agile development. For example, following their field studies of collaboration in 6 Ag- ile teams, Robinson andSharp make thepoint that collaboration works as well as it does because the practices have a structure toaddressimportanttechnicalissues(RobinsonandSharp,2010).
Following theanalysis oftheir quantitative studyofperformance inAgileteams,(Woodetal.,2013) makeasimilar point:itisnot merelythatteamworkleadstobetterperformance,butratherthat theteamworkworkswiththetechnicalpractices.
Dybå and Dingsøyr (2008) provide a literature review about empirical studies of Agile software development. They mention studiesthatreportimprovedcustomersatisfactionwhenusingAg- ile methodologies. They also report about satisfaction from the developer perspective, mentioning a higher satisfaction with the productandcustomercollaboration.
Lindsjørn et al. (2016) analyze the relationship between of Hoegl and Gemuenden’s Teamwork Quality measure (TWQ) Hoegl andGemuenden(2001) on variousaspects ofsoftware de- velopment,andreportastrongpositiveimpactofteamworkqual- ityonworksatisfaction.
In ourstudywe use abroader rangeof practices (more tech- nicalpractices,collaborationpracticesandplanningpractices)and alsosetsatisfactioninrelationtotheimpactsinbusiness,software, andteamaspects.Wetakeadescriptiveapproach,andexplorevar- iousconcreteissues.
3. Studysetup 3.1. Studybasis
Ourstudywasbasedonanationwide onlinesurveyconducted byusinSwitzerlandin2016.Thesurveyisabouttheusageofde- velopmentmethodsandpracticesintheITindustry,andaboutthe impactsofapplyingAgilemethodsonprojects.Moredetailisavail- able about the survey instrumentand the general results in the surveyreportKroppandMeier(2017).
ThesurveyaddressedbothAgileandplan-drivencompanies,as wellasbothAgileandplan-drivenITprofessionals,oranyhybrids.
There were in fact two independent surveys:one for companies, andoneforindividualITprofessionals.
Inthecompany surveyweaddressrepresentativesofthecom- panyor thedevelopmentdepartment of acompany, i.e.typically upper management level. To ensure a company was represented only once in the company survey, we sent personalizedlinks to onemanagementrepresentativeofeachcompany.
The IT professional survey was anonymous, and we invited widerparticipation. Wesent invitationswitha linktothe survey viaemailandthroughprofessionalsocialmedia likeLinkedInand
Table 1
Distribution of the roles and sizes of the companies in the survey of company representatives (top), and survey of individual professionals (bottom).
Survey of Company Representatives
Role % Size %
CEO 34% Micro enterprise ( ≤9) 25%
CTO 17% Small enterprise (10–49) 37%
Development Manager 11% Med. enterprise (50–249) 19%
Team Leader 10% Large enterprise ≥250) 19%
CIO 7%
Project Manager 6%
Designer / Architect 2%
Software Developer 2%
Product Manager 1%
Researcher 1%
Other 9%
Survey of Individual Professionals
Role % Size %
Senior Software Developer 17% Micro enterprise ( ≤9) 12%
Software Developer 12% Small enterprise (10–49) 26%
Project Manager 14% Med. enterprise (50–249) 14%
Team Leader 10% Large enterprise ≥250) 48%
Designer/Architect 10%
Others ( < 10% each) 37%
Table 2 Survey responses.
Company Survey Individual Survey Impressions (gross) 1399 529
Response rate 18.16% 62%
Completion rate 10.15% 31%
XING(acareer-orientedsocialnetworkingsitepopularinGerman- speakingmarkets).Participants were typicallydirectlyinvolvedin software development, andwe describe the demographics inthe sectionbelow.
Thequestionswerethesameforbothsurveys,withoneaddtion fortheprofessionals.Forthatsurvey weaddedaset ofquestions (called “MyAgile”)abouttheir personal perspectiveon variousis- sues.
3.2. Participantdemographics
Weemailed1399companiesdirectlywithpersonalaccesscode forthecompany representative,andabout50001 IT professionals inSwitzerlandwithan anonymouslinktothesurvey.142compa- nies and 185IT professionals filled out the complete survey.The addresses of the companies and the professionals were collated from the participating IT associations SwissICT2 and SWEN,3 as well asfrom our own institutionaldatabases. Table 2 showsthe details about the survey responses. The impression value of the IT professionalsurveyindicatesthe numberofpeoplevisitingthe surveywebsite.
Table 1 (top) shows the demographics of respondents in the survey ofcompany representatives. Itshowsthat 34% ofthe par- ticipants were Chief Executive Officersand 17% were Chief Tech- nologyOfficers.“Other” includesroleslikeBusinessAnalysts,Agile coach, founder,owner, andCFOs. Thetable alsoshowsthedistri- bution of the sizes of the participating companies following the
1We do not know the exact number, since these mailings were partially done by partner associations.
2www.swissict.ch .
3http://www.swen-network.ch .
Table 3
Distribution of participants per company in survey of individual professionals.
Participants per Company Number of Companies
1 44
2 6
3 3
4 2
5 1
7 1
8 1
9 1
80 N/A
official categories of the Swiss Statistical Office.4 More than 60%
aremicroandsmallenterprises.Amongthelargeenterprisesthere werefourwithmorethan10,000employees.
Table1(bottom)showsthedemographicsoftherespondentsin thesurveyofindividualprofessionals.Thesepeopletypicallyhave roles much more directly involved with software development, withthelargestcategoriesofrolesbeingSeniorSoftwareDevelop- ers(17%),SoftwareDevelopers(12%),ProjectManagers(13%),Team Leader(10%),andDesigner/Architects(10%).Wehadahighnum- berof“Others” (each <10%)),whichincluderoleslikeQATesters, UXDesigners,ScrumMasters,AgileCoaches,ProductOwners,and alsosomemanagersofsmallcompanies.TheITprofessionalswere alsoworkingmostlyinacompany,withthecompanysizesshown inthetable,butwereparticipatingandspeakingforthemselves.
Fromthe 182participatingprofessionals,102 participantspro- videdthecompanyname.Theprofessionalparticipantscamefrom 59differentcompanies.Table3showsthe distributionofpartici- pantspercompany.Thefirstrowshowsthattherewere44compa- nieswithoneparticipant;29participantscamefromonly4com- panies (two of those were in the financial domain). For 80 par- ticipantswedon’t knowfromwhichcompanythey are.We must thereforebecautiousaboutthepotentiallackofrepresentativeness inourresults.
The main categories ofthe companies are IT Services/IT Con- sulting (30%), Software Industry/Development (28%). Public Ser- viceandFinance/Insurancecompaniesmake 8%each.Nextcomes Telecommunicationwith7%.The restare 4%andbelow. Thepar- ticipation is a reasonable reflection of the character of software developmentin Switzerlandaccording to theofficial governmen- talstatisticaloffice.
3.3.Studyquestionsandanalysis
Thesurvey instrumentquestionsandgeneralresultsareavail- ableinfull aspartofthe generalreport KroppandMeier(2017). The questions and our analysis were principally based on Likert scales, and wastherefore a quantitative approach based on self- reportedexperienceandperception.Qualitativeanalysiswasmini- mal,andlimitedtowrite-inanswerstosomequestionswhereour categoriescouldnotbeexhaustive.
Throughoutthequestionnaire, weaskedparticipantsaboutthe nature of the software development process in their workplace.
Somequestionswerebroad,suchaswhethertheprocesswasmore plan-driven,ormoreagile,andhowsatisfiedtheywerewiththeir process.Wealsoincludedquestionsaboutexperience,self-ratings, role,andcompanybackground.
The survey questionaboutsatisfactioncame very early in the survey,andaskedasimpledirectquestion:“Howsatisfiedareyou
4http://www.bfs.admin.ch/bfs/portal/en/index/themen/06/02/blank/key/01/
groesse.html .
Table 4
Agile Practices : technical, collaborative, and planning. Agile Impacts : business, team, and software. We asked about practices first, then impacts, in the order shown in each column. Participants responding with the level they experienced, a scale of 1–5.
Practices Impacts
Technical Practices Business Impacts
Unit testing Time to market
Coding standards Manage changing priorities Automated builds Alignment between IT Refactoring & business objectives Continuous integration Project visibility Software Craftsmanship Handling of project risk
DevOps Development process
Clean Code Mgmt of distributed teams Behavior Driven Development Requirements management Acceptance Test Driven Dev. Delivery predictability Test Driven Development
Automated acceptance testing Continuous delivery
Collaborative Practices Team Impacts Dedicated product owner Team productivity On-site customer People development Daily stand-up Effectiveness of meetings Retrospective Impediment management Open work area Engagement of product owner Team-based estimation Team morale / motivation Collective code ownership Stress at work
Pair programming Working overtime Single team
Self-organizing team
Planning Practices Software Impacts
Release planning Product / software innovation Iteration planning Software quality
User stories Software maintainability
Taskboard Engineering discipline
Burndown charts Software architecture
Story mapping Defect rate
Prioritized backlogs Short Iterations
withyourcurrentmethodology?” Asthesurveyprogressed,profes- sionalswereaskedaboutarangeoftheirexperiencesintheirsoft- waredevelopmentenvironment. Therewere severalsets ofques- tions about practices: first technical practices, then collaboration practices,andlastlyplanningpractices(Table4left).Eachofthese sets comprised several questions.Later, there were questionsets aboutimpacts,meaningwaysinwhichtheprocessinluencedout- comes: firstbusiness impacts, then team impacts, andthen soft- wareimpacts(Table4right).Weacknowledgethatinsome cases thesecategorizationsaremoredistinctthanideal:somemeasures couldwell feature inseveralcategories.All thisgaveusinforma- tion about how widespread the practices and experiences were.
Beyond this, however, by considering theseaspects together, we hopedtogain some insightabouthow they mightbe connected.
Forexample, we might expect that the practices of UnitTesting andTestDrivenDevelopmentmightberelatedtosuchimpactsas SoftwareQualityandDefectRate.
The mainbases forourquestionswere ourearlierSwissAgile StudiesKroppandMeier(2012,2015).Wehavechosenthoseprac- tices that are typically seen as “agile” practices(from other sur- veys,ownexperiences,discussionswithcompanies).Wewerealso influenced by the study by Version One VersionOne (2017).It is possiblewehadinadvertentlymissedsometopics,butexperience withtheearlierSwissAgileStudiesallowedtheadditionoftopics suggestedinfeedback.
4. Basicfindings
Inthissectionwe presentresultsaboutthedistributionofap- pliedmethodologiesandsatisfaction.
Fig. 1. Percentage of companies and individual professionals doing agile on a scale from pure agile to pure plan-driven.
Fig.1showstheresultsofthecompanyrepresentativesandin- dividualprofessionalstothequestion:1.1Isyourcompanycurrently practicing plan-driven or agile software development? The partici- pantscouldchooseonascalefrom(pure)Agile,mostlyAgile,both, mostlyplan-driven,and(pure)plan-driven.Aggregated,85%ofthe companies and80% of the professionals answered that they ap- plyAgiledevelopment,atleasttosomeextent;however,only13%
for both, companies and professional,responded that they apply only Agiledevelopment. Thesurvey questionconcerning satisfac- tionasked1.3Howsatisfiedareyouwithyourcurrentmethodology?
Possible answers were on a scale from1 (unsatisfied) to 4(very satisfied).Wehavechosen a4-pointLikertscaletoforce achoice andavoidequivocation. Fig.2showsthesatisfactionresultsofall participatingcompaniesandallindividualprofessionals.Inthesur- veyofcompanies,mostrepresentativesrespondingindicatedsatis- faction. Inthe survey ofprofessionals, however, the results were balancedbetweenunsatisfiedandsatisfied.We speculatethatthe differencebetweencompanyrepresentativesandindividualprofes- sionals may stem from the representatives wanting to present a morepositiveviewoftheirorganization,ormayindicatesomede- tachmentfromtheactualexperienceofsoftwaredevelopment.
Wewere especially interestedto explorewhetherAgiledevel- opmentisassociatedwithmoresatisfaction.Fig.3showstheanal- ysis of the above question divided into three participation cate- gories. We aggregatedthe “pure Agile” and “mostly Agile” com- paniesintoone“Agile” group,the“pureplan-driven” and“mostly plan-driven” intoa “plan-driven (PD)” group andkept the“both”
groupstandalone.
Fig.3 showsa very highsatisfaction rate, bothfor companies andthe individual professionals, withvery similar values.In the
“Both” categorythecompanies stillreport highsatisfaction,while theprofessionalsarenotquitesosatisfied.However,inthe“plan- driven” categorycompanies, i.e.companyrepresentatives, still re- portahighlevelofsatisfactionwiththemethodology(71%),while only16%oftheprofessionalsreporttobesatisfiedorverysatisfied.
But40%oftheplan-drivenindividualprofessionalsreporttheyare unsatisfiedwiththemethodology.
To investigate further, we can compare the level of satisfac- tion (1–4)reportedwith thelevel ofagility (from 1: plan-driven to5: Agile).ThisisshowninFig.4,ontheleft, whereeachlevel ofAgilityisshownonthe horizontalaxis,andthedistributionof satisfaction responses for each is shownby a boxplot.5 The self- reportedlevelofAgilitymaynotbeaccurate,sowealsoshow(on
5Although the Likert data is ordinal, we use boxplots to show distribution in a compact manner. The thick line indicates the median, the coloured box indicates the inner quartiles, the whiskers indicates the outer quartiles, and circles show out- liers. Diamond markers show the mean.
Fig. 2. Distribution of reported satisfaction, on a scale from 1 (unsatisfied) to 4 (very satisfied): Company representatives (left) and individual professionals (right).
Fig. 3. Satisfaction with the methodology aggregated to agile (Agile: pure agile and mostly agile), hybrid, plan-driven (PD: mostly plan-driven, pure plan-driven) for company representatives (“comp”) and individual professionals (“prof”), hence “Agile Comp”, “Agile Prof”, “Hybrid Comp”, “Hybrid Prof”, “PD Comp”, “PD Prof”.
Fig. 4. Satisfaction levels by level of agility claimed (left) 1–4, and mean level of technical practices by level of agility (right) 1–5 claimed. Together these show that satisfaction is related to level of agility, and that the claimed level is indeed based on the level of actual technical practices used. (The boxplots show the medians as heavy black lines, inner quartiles as coloured boxes, outer quartiles as whiskers, and the means as diamonds. Numbers at the top show number of particpants in that level.).
the right ofthe figure)how the level ofAgility compares to the meanlevel reportedforanumberofAgile technicalpractices.As we can see,thisdemonstrates a strongrelationship, suggestinga linkfromthepractices,toperceptionofAgility,tosatisfaction.
Thecompanysurveydatawasprovidedbyrepresentativeswho were mostly managers, typically senior managers. However, the surveyofprofessionalsalsoincludedanumberofpeoplerespond-
ing whogave job titlesindicating amanagement role. We there- foreexploredthelevelsofsatisfactionbysuchmanagerscompared withdevelopers.Wecountedasmanagersanyonewith“manager”
(e.g.product manager, projectmanager) or “coach” in their title, 62 inall; we counted as developers anyone with“developer” or similar in their title, 64 in all. The results are shown in Fig. 5 illustrating that the level of satisfaction rises with the level of
Fig. 5. Satisfaction levels by level of agility, for developers (left), and managers (right), both taken from the survey of professionals, showing the relationship between satisfaction and agility is true for both.
claimedAgileadoption,bothforprofessionalswithamanagement role, and those who are developers. We also explored the man- ager/developerdistinction in many other aspects of the data for individualprofessionals,andfoundfewdifferences.
5. Potentialreasonsforsatisfaction
Inthissection,weexplorethepotentialreasonsforsatisfaction, usingthe datafromanswers to other questionsin thesurvey. In particular, we use the answers from the survey of professionals, becausetheywere moredirectlyinvolvedwithsoftwaredevelop- ment,andtheywereansweringforthemselvesalone.Weomitthe answersfromthecompanies,i.e.management,here,becausethey mighttendtoclaimmorepositivesatisfactionthanindividuals,as Fig.3indicates.
In a survey ofthis nature, we actually cannot detect reasons, orcauses,forsatisfaction,butmerelyanswersthatexhibit aclose relationship.The survey questionsfollow aLikert scale approach, andso allowdetectionofsimilar patternsusingordinalstatistics.
Weidentify the similaritieswe find,and discusshowthese rela- tionshipsmightarise.
Toexaminethe relationshipbetweensatisfactionandother is- sues,wecomparedtheanswersforsatisfactionandforotherissues onaperson-by-personbasis,whereeachpersonrespondedtothe samequestions.Wecomputedcorrelationstatistics,comparingsat- isfactionanswerswiththematchinganswersforotherquestions.A correlationshowsthatwhenonefigureislow,soistheother,and similarlyforhigh. Tocompute thecorrelation,weuseSpearman’s non-parametric“rho” (
ρ
)method,ratherthanPearson’sr,becauseourLikertscale datais ordinal,andthisapproach supports more conservative results. A rho approaching 1 is an extremely close match,arhoapproaching −1isextremelyclosebutopposite,and arhoapproaching 0is avery poormatch.Note thatin ourdata, ourprimary referentisthe satisfactionquestionwhichwasrated ona 1–4 scale, while ourquestions about practices andimpacts wereratedona1–5scale.Thismeansthatthemaximumcorrela- tioncoefficientis0.8ratherthan1.
We alsocalculatedsignificance,theprobability that sucha re- sultmightoccurby chance,anddismissedresultsabove analpha levelof0.05.
Table 5, in the upper section, shows the highest correlations ofsatisfaction withvarious answers aboutsoftware development practices.Wesortedtheresultsindecreasingorderofrho,somore highlycorrelatedanswersareshownfirst.(Moreprecisely,inorder todetectanyreversecorrelations,wesortbyabsolutevalueofrho, butreportthetruevalue).Inthetable,wecanseethatthehighest correlationforsatisfactionwithpracticescomes fromthecollabo-
Table 5
Satisfaction correlations for Agile practices and impacts. Technical practices are pre- fixed TP, collaborative practices with CP, and planning practices with PP; business impacts with BI, software impacts with SI, team impacts with TI.
# Practices Questions rho p.value
1 CP Self organizing team 0.446 < .001
2 CP Collective code ownership 0.375 < .001
3 PP Story mapping 0.306 < .001
4 PP Short Iterations 0.299 < .001
5 CP Single team integrated development and testing 0.293 < .001
6 TP Software Craftsmanship 0.275 0.001
7 PP Prioritized backlogs 0.258 < .001
8 CP Team based estimation 0.247 < .001
9 TP Refactoring 0.245 < .001
10 TP Acceptance Test Driven Development ATDD 0.235 0.001
# Impacts Questions rho p.value
1 BI Time to market 0.333 < .001
2 BI Management of distributed teams 0.289 0.001
3 BI Handling of project risk 0.261 0.001
4 BI Development process 0.249 0.002
5 SI Software architecture 0.239 0.003
6 TI Stress at work 0.224 0.007
7 BI Ability to manage changing priorities 0.218 0.006
8 BI Delivery predictability 0.216 0.008
9 TI People development 0.213 0.009
10 BI Project visibility 0.193 0.019
rative practiceof a self-organizing team,followed by that ofcol- lectivecodeownershipandStorymapping,andthesearetheonly practiceswith
ρ
>0.3.Moreover,thetop5arealleithercollabora- tivepracticesorplanningpractices.Although3technicalpractices arein thetop10,the patternseemsclear:it iscollaborationand planningpracticesthatmostcloselymatchsatisfaction.Movingfrompracticestoimpacts, weusethesametechnique, withthe resultsshownin thelower section ofTable 5.Here the mosthighcorrelated answer isabout time tomarket. This could be an indicationthat fast time to market might generatehigher satisfaction. Interestingly, the second most highly correlated an- swerisaboutmanagement ofdistributedteams.Thismightseem odd,becauseAgilemethodsareoftenregardedaspooronthisas- pect,butthefindingsimplymeansthatwhenmanagementofdis- tributedteams is done well,satisfaction ishigh. Note alsorow5 inlowersectionofTable5,Softwarearchitecture,thehighestand only“SoftwareImpact” measureinthe top10.Row 6isStressat work:we reverse-codedthisaspect,soahighresultmeans lower stress: it makes sense that thisis related with highsatisfaction.
Overall, it is interesting that 7 of the top 10 are business im- pacts.Thissuggeststhatsuccesswithbusinessaspectsmighthave
Fig. 6. Satisfaction levels corresponding levels for most correlated practices (top) and impacts (bottom).
astrongimpacton,orisnecessaryfor,softwareprofessionals’sat- isfaction.
Consideringthepracticesandtheimpactstogether,itistempt- ing toseea generalpicture:satisfactionishighlycorrelated with collaborativeandplanningpractices,togetherwithsuccessinbusi- nessaspects.However,thisisnotthewholestory.Referringagain toTable5,wecan seethat eventhehighestcorrelationsareonly inthe rangeof.3 or.4,andsonowhereneara perfectcorrelation.
This isnot surprising,because software developmentiscomplex, and we should not expect anyone practice orimpact to lead to perfect satisfaction.Rather, it makes moresense that several as- pectswouldbenecessaryforhighsatisfaction.Moreover,consider- ation ofonlycorrelation isquitelimited, andwillmiss some im- portant patterns,suchasclosematches forpartofadistribution, butdivergenceelsewhere.
The relationships over the range of responses between these mostcorrelatedresponsesandsatisfactionareshowninFig.6.For each levelof responseaboutthe practiceorimpact, therangeof responsesforsatisfactionisshown.Fig.6a,forexample,showsthat each level of response about Self-organizing teams is associated witharangeofsatisfactionresponses,butthecentralpartofrange (the inner quartilesrepresented bythe coloured box)steadilyin-
creaseswiththelevel ofresponse aboutSelf-organizingteams. A similar pattern is shown in each of the sub-figures, although is lessstronginFig.6d,perhapsbecausemanagementofdistributed teamsisnotimportantinallenvironments.
5.1. Dominantissues
Toexplore this, we considered several approaches.For exam- ple,instudiesofcomplexprocesses,theapproachindicatedmight be multiple regression,where satisfaction is the dependent vari- able(DV),andthepracticesandimpactsaretheindependentvari- ables(IVs),anda formularelatingthemissought. We feel,how- ever,thatthisismoresuitable forunderlyingcontinuousphysical processes. Accordingly, we took an approach that looks forcriti- calpointsinthe datathataffectsatisfaction.Todothis, we used createaRegressionTreeBreimanetal.(1984)usingRecursivePar- titioningTherneauandAtkinson(1997)6Inthisapproach,theanal- ysisbeginswiththewholedataset,anddetermineswhichIV,and atwhat point,bestdistinctly dividestheDV.Thus weobtaintwo
6An updated version of this document is available at: https://cran.r-project.org/
web/packages/rpart/vignettes/longintro.pdf .
Fig. 7. Recursive partition trees for satisfaction factors in practices (left) and impacts (right). Nodes show implied satisfaction level and % of data, leaves limited to 10%. Tone density of nodes indicates levels of satisfaction: darker means higher.
sets,onewithlowersatisfaction,andonewithhigher.Theprocess isthenappliedrecursively.
We applied this approach first to the practices, and obtained thetreesshowninFig.7onthelefttree.Aswemightexpectfrom theearliercorrelation analysis, theprimary factor isthe collabo- rativepracticeofaself-organizing team.Thetreeissplitbetween resultsforthat questionona ratingof3.5(on theLikertscale of 1–5),with thelower tothe left, and thehigher to the right. On theright, wenext see,againaswemightexpect fromthecorre- lations,the factorofcollective codeownership. Where itis ator above3.5,thenextfactoristhecollaborativepracticeofretrospec- tives,andthatgivesthehighestresultforsatisfaction:ameanre- sultof3.1.We canexploretheother branchesforthetree,tosee theeffectsofotherfactors.Ontheleftsideofthetreewecansee thefactorsrelatedtolowsatisfaction:thelackofuserstoriesand storymapping appears stronglyrelated to low satisfaction.Over- all,the impression is similar towhat we expected fromthe cor- relations,collaborative practices are paramount, though technical practicesalsoplayarole,andwenowhavemoredetailtoidentify whichcombinationslead to thebest results.There isone impor- tantcaveat.Inthetree,notethattheright-handbranchindicating highersatisfaction comes fromlower emphasis onretrospectives.
Thetreeontherightshowsthepatternforimpacts.Herewe see thattheprimaryfactoristimetomarket,andforlesserlevelsthe importantissuesarestress,productivity,andriskmanagement.
5.2.Lowvs.highsatisfactionexperiences
Toexplore thereality oflowandhighsatisfaction,wedivided participantsintotwogroups,thosewithsatisfactionlowerthanthe median,andthosewithsatisfactionhigher.Wethenlookedatthe rangeofresponsestootherquestionstoseehowtheydifferedbe- tweenthetwogroups.Inthisway,wehopetogainunderstanding ofhowvariousissuesdiffertogether,ratherthansimplylookingat eachissueindividually.Wefocussedonresponsesaboutpractices, distinguishing the responses from participants with lower satis- factionfromthosewithhighersatisfaction.Tocomparethese,we createdboxplotsshowingthedistributionofparticipantresponses aboutuseofeachpractice.Foreachpractice,we showone setof boxplotsdepictingtheresponsesfromparticipantswithlowersat- isfaction(lightercolour) andanother forthosewithhigher satis-
faction(darkercolour),asshowninFig.8.Thisapproachhighlights thedifferentpatternsofresponsesbetweenthetwogroups.
Fig.8a showsthesedistinctions fortechnicalpractices.Ascan be seen, the median response for every question isthe same or higherforthehighsatisfactiongroup.Weseethat forsomeprac- tices the distributions are very similar: e.g. unit testing is high in both. For some practices, however, there was a stark differ- ence:e.g. refactoring,continuousintegration, softwarecraftsman- ship,cleancode,test-drivendevelopment,andcontinuousdelivery.
Thesewouldseemtorelatetocodequality.
Fig. 8 b showsthe differences for collaborative practices. The distinctionsare mostclearforan openarea, collectivecodeown- ership, team integrated testing, and of course a self-organizing team.Allthoseappearto relatetocohesionwithin theteam.Per- hapssurprisingly,practices suchasan on-sitecustomer andpair- programmer show little difference between groups. The striking reasonisthatneitherpracticeiswidelyadopted.
Fig. 8 c shows the differences forplanning practices. Release planning, iteration planning, user stories, and burndown charts show little difference. The largest distinctions are fortaskboards, prioritizedbacklogs,andshortiterations.Perhapsthethemeisone ofasenseofprogress.Onemightexpectburndown chartstoalso supportthat,butusewaslowforbothgroups.Itmightbethatthe popularity of taskboards means people feel little need for burn- downcharts.
Consideringallthesepatternstogethersuggestssatisfactionre- latestoconcernforquality work,teamcohesion,andsupportfor tracking progress. None of theseare surprising,and indeed they reflectfindings fromqualitative studies,e.g. (WhitworthandBid- dle,2007).Whatmightbeseenasmoresurprisingisthat,despite widespread emphasis onsuch characteristics fromAgile software developmentadvocacy,manyofourparticipantsseem toworkin environmentswheretheyarelacking.
6. Otherperspectives 6.1. “MyAgile”
In the survey, professionals were also asked questions about their personal perspective on Agile processes, “My Agile”: see Table6.Wehavepresentedtheseresultsinmoredetailelsewhere
Fig. 8. Results for questions about Practices, showing those in low (lighter colour) vs. high (darker colour) satisfaction groups.
Fig. 9. Results for “My Agile” questions 1–13 from Table 6 .
Table 6
“My Agile” questions, where each question was ranked on a Likert scale of 1–5.
# My Agile
1 I pay more attention to technical excellence 2 My work life balance has improved 3 Release is not a nightmare anymore
4 We have developed a culture of mutual respect
5 I feel much more committed/dedicated to the team and to the work
6 I have more fun at work 7 I think my work is more valued
8 We have a team environment which is honest and trusting 9 Team members take the initiative to accomplish tasks more
often
10 The team has been empowered to make decisions about how to do their work and execute on those decisions without outside interference
11 We have a culture of servant leadership
12 We have a team environment which allows for mistakes 13 The team is encouraged to be creative and to experiment
with new ideas
Biddleetal. (2018),and hereoutline the relationshipwith satis- faction.Weacknowledgethatthe“MyAgile” questionsthemselves areproblematic, inthat they presume experience of a changeto Agilefromsomethingelse,andmaysuggestitwouldbeapositive change.
The questionwe askedwas: Towhat extentdoyou agree with thefollowingstatements? Theparticipantscould chooseonascale from“completelydisagree”,to“completelyagree” witha 1–5scale.
Thegeneralresultsforeachquestionareshownintheboxplotsin Fig.9. One thing we can immediately see isthat the resultsare fairly consistent, withevery scale showing thesame median, al- thoughsomedistributionsareverytight(e.g.“morefunatwork”.) Weexplored therelationshipwithsatisfactionusingtherecur- sivepartitionapproach,obtainingthetreeshowninFig.10.Aswe canseehere,twofactorsstandout.Thedominantfindingisarela- tionshipbetweensatisfactionandthefactor“Ipaymoreattention totechnicalexcellence”:showingtheimportanceofqualitytopro- fessionals.
Fig. 10. Satisfaction factors in answers to “My Agile” questions.
Wewereinterestedintherelationshipbetweentheresultsfor thesequestionsandthoseforthepractices,sowecalculatedpair- wise correlationsfor each ofthe “MyAgile” questions with each ofthepracticesquestions.WeusedthesameSpearman’s correla- tiontechniqueasdescribedinSection5,andreportthetop10sig- nificantcorrelationsinTable7.As canbe seen,weseeseveralof thesamefactorswe havehighlightedbefore.Inparticular,having aself-organizingteamisthepracticemoststronglylinked tohigh scoresinthe“MyAgile” questions,thoughsometechnicalpractices alsoappearinthetop10.
Considering the relationship with satisfaction, we looked for differencesinthe“MyAgile” topicswithforparticipantswithlow andhighsatisfaction.Wedidfindsome relationship,butverylit- tle.WeagaincalculatedtheSpearman’scorrelationcoefficient be- tween each scale and the satisfaction results, but only found a fewcorrelations,allunder
ρ
=.25.Whilepersonalexperienceand overall satisfaction concernsimilar issues, we found little insight emergingfromouranalysis.Table 7
Correlations between “My Agile” questions and practices (top 10 significant).
# My Agile Practice rho p.value
1 The team has been empowered to make decisions about how to do their work... CP Self organizing team 0.378 < .001 2 I feel much more committed dedicated to the team and to the work CP Pair programming 0.371 < .001 3 The team is encouraged to be creative and to experiment with new ideas CP Self organizing team 0.362 < .001 4 Team members take the initiative to accomplish tasks more often CP Self organizing team 0.355 < .001 5 We have a culture of servant leadership CP Self organizing team 0.321 < .001 6 We have a team environment which allows for mistakes CP Self organizing team 0.317 < .001
7 I think my work is more valued TP Software Craftsmanship 0.309 0.001
8 I think my work is more valued PP Story mapping 0.300 < .001
9 We have a team environment which allows for mistakes CP Pair programming 0.299 < .001 10 We have developed a culture of mutual respect CP Self organizing team 0.298 < .001
Fig. 11. Reported stress by managers (left) and developers (right), on a scale from 1 (unstressed) to 5 (very stressed).
Fig. 12. Results for “Hindrances” questions 1–10 from Table 9 .
6.2. Stress
In this paper our focus is on satisfaction, but in other anal- ysis of the same survey, we addressed the subject of stress Meier etal.(2018).Inthesurvey wedirectlyaskedITprofession- als about their stress at work. They answered on a scale from 1 (significantly less stressed) to 5 (significantly more stressed).
Fig. 11displays histogramsof the results,showing separately re- sponses fromparticipants withtitles indicating a manageral role from those with titles indicating development work. As we can
see there is a range of answers, withmost developers reporting aneutrallevel,andmostprofessionals withmanagementrespon- sibilities reportingsomewhat less. Although theseresultsare not extreme, they dosuggest some reason forconcern,withsizeable numbers reporting they are more stressed or significantly more stressed(levels4and5).
Toexplorehowthepracticesandimpactsrelatedtothestress, we looked for correlations. To compute the correlation, we use againSpearman’s correlation measure. Ourspeculation wasa re- lationshipbetweencollaborativeprocesses overall,andstress.We
Fig. 13. Results for questions about Hindrances, showing those from low (lighter colour) vs. high (darker colour) satisfaction cases.
Table 8
Stress correlations for impacts.
Question rho p.value
1 SI Defect rate -0.439 < .001
2 TI Team morale motivation -0.413 < .001 3 SI Software architecture -0.374 < .001
4 SI Software quality -0.362 < .001
5 BI Requirements management -0.353 0.001 6 SI Engineering discipline -0.337 0.001 7 SI Software maintainability -0.335 0.001 8 TI Engagement of customer product owner -0.333 0.001 9 BI Ability to manage changing priorities -0.323 0.002 10 TI Effectiveness of meetings -0.321 0.002
Table 9
Agile Hindrances topics, which participants were asked to rate on a Likert scale of 1–5.
Hindrances Scale
1 Ability to change organizational culture 1–5 2 General organizational resistance to change 1–5 3 Availability of personnel with necessary agile experience 1–5
4 Lack of management support 1–5
5 Project complexity or size 1–5
6 Business / user / customer availability 1–5 7 Concerns about the ability to scale agile 1–5 8 Perceived time and cost to make transition 1–5 9 Concerns about loss of management control 1–5
10 Regulatory compliance 1–5
thereforecalculated a composite score based on all collaborative practices,andcompareditwiththestress data.Wedidnotfinda strongconnection:
ρ
=−0.16,p=0.05.We then explored each of the practices, and each of the im- pacts,calculatingthe correlation of each individually withstress.
As described in our earlier papers (Kropp et al., 2016; Meier et al., 2018) we had determined a hypothesis, so in this analy- sis we modifiedp-levels with the Bonferronicorrection for mul- tipletests,andusedanalphalevelof0.05.Forpractices,wefound theonlypracticewithasignificanteffectwasthe“Self-Organizing Team” collaborativepracticeshowing
ρ
=−0.27,p=0.02(Bonfer- ronicorrected). On furtherinspection, we found thisrelationship was strongest for those with management responsibilities, withρ
=−0.54.Exploring impacts, we found a more diverse picture. Table 8 showsthe top 10 correlations, ranked by |
ρ
|. The p-levels againreflect Bonferroni correction formultiple tests, andwe omit any resultsaboveanalphalevelof0.05.
As can be seen, the impacts that play a role are varied, with software, business, and team impacts all involved. Perhaps most notably,severalsoftwareimpacts(SI)ratehighly:lowerdefectlev- els,goodsoftwarearchitecture,andoverallsoftwarequalityareall associatedwithlower stress.ThebusinessImpacts(BI)alsorelate togoodprocessoutcomes,such asrequirementsmanagementand ability tomanage changing priorities. Team Impacts(TI) reflect a positiveenvironment, suchasgoodmorale, anengagedcustomer, andeffective meetings. Looking at differencesbetweenmanagers and developers,we found most ofthe impact relationshipscon- cernedmanagers,butitwasdeveloperswhomosthighlyratedlow defectrates, abilityto manage changingpriorities, andmoraleas mostrelatedtoreducedstress.
Consideringthesefindings,itseemsreasonabletodirectlycon- sider the relationship between stress and satisfaction. We might expect,forexample,thatmore stressisinverselyrelatedtosatis- faction.WecalculatedSpearman’s correlationcoefficient forthese two ratings, however,and found
ρ
=−0.22,p=.007.So there is asignificantnegativecorrelation,butat0.22itisnotverystrong.We speculate that stress alone is not the determining factor. As suggestedinsomeearlierwork(e.g.WhitworthandBiddle,2007), workmightbestressfulbutalsosatisfying.
6.3. Hindrances
Anothersection inour survey concerned potential hindrances toAgilesoftwareprocesses.Theseissuewereintroduced withthe questionHow much do thefollowing aspects hinder you to further adopt agilesoftwaredevelopment in your company?The issues are showninTable9.Participantswereaskedtorespondonfivepoint Likertscale,with“Notatall” being 1,and“VeryStrong” being5.
TheresponsesaresummarizedinFig.12,wheretheresponsesfor eachtopicareshownasboxplots.Ascanbeseen,eightoftheten topicsreceivedamedianscoreof2(“Alittle”),andthetwoothers received amedianscore of3.However, theranges shownonthe boxplotsindicatewidedifferences.
Tohighlighttherelationshipbetweensatisfactionandthepos- siblehindrances, asinSection 5.2, we separatedthe participants into two groups with lower and higher satisfaction ratings, and thenlookedatthetenhindranceratings.ThisisshowninFig.13, wherethetwoboxplotsareshownforeachissue:lighterforthose that are associated with lower satisfaction,and darker for those
Table 10
Satisfaction correlations for Agile hindrances.
Question rho p.value
1 HI General organizational resistance to change -0.440 < .001 2 HI Lack of management support -0.399 < .001 3 HI Ability to change organizational culture -0.374 < .001 4 HI Concerns about loss of management control -0.342 < .001 5 HI Availability of personnel with necessary agile experience -0.282 < .001 6 HI Concerns about the ability to scale agile -0.268 < .001 7 HI Perceived time and cost to make transition -0.237 0.002
8 HI Regulatory compliance -0.182 0.016
associatedwithhighersatisfaction.Thisallows ustoseethepat- tern ofdifferences betweenthe two groups, andallow the over- alldistinctionsbecomemoreclear.Aswemightexpect,almostall hindranceissuesshowarelationshipwithsatisfaction:hindrances will necessarily hinder something. Onehindrance doesstand out dramatically, with theleftmost boxplot pair onthe graph: “Abil- ity to change organizational culture”. For this hindrance, lower satisfactionpartipantsratedthisasreallyproblematic(median4:
“Strong”),whereashighersatisfactionparticipantsratedthisnotas muchofanissue(median1:“Notatall”).
We then looked forcorrelations between satisfaction andthe potential hindrances.These are shownin Table10. As beforethe table showstheordinal correlation coefficient, Spearman’srho
ρ
,indecreasingorderbyabsolutevalue,andonlyshowingthosewith p<0.05.Again, because satisfaction was rated1–4 andthe hin- drances1–5,the maximumcorrelation is0.8. All correlationsare negative, notsurprisinglyshowingan increaseinhindrance isre- latedtoadecreaseinsatisfaction.Inparticular,thefourstrongest (negative) correlationsall show a commonpattern: General orga- nizationalresistanceto change,Lackofmanagementsupport, Ability tochangeorganizationalculture,andConcernsaboutlossofmanage- ment control.This is exploratorypost-hoc analysis, so we do not correct formultipletests, though mostvalues wouldbe well be- lowthealphalevel.
7. Discussion
Ourresearch questionswere abouthow satisfaction relatesto thedevelopmentapproach,tospecificpractices,andtospecificim- pactsperceived.
Inourfindingsdescribedintheprevioussections,wefirstno- ticedconfirmationthat,forindividualprofessionals,Agiledevelop- mentisassociatedwithgreatersatisfactionthanplan-drivendevel- opment.Wethenexplored whythismightbe.Wewantedtofine thepracticesandtheimpactsmostcloselyrelatedsatisfaction.
Whenwelookedatpractices,weconsideredthreekinds:tech- nical, collaborative, and planning practices. What we found was thatthestrongestrelationshipwithsatisfactioncamefromcollab- orative practices: self-organizing teams, andcollective codeown- ership.Thetechnicalpractices,suchassoftwarecraftsmanshipand storymapping,dohaveaneffect,butatlesserlevels.Overall,this suggeststhatself-organizing teamsandcollective codeownership need tobetakenvery seriously,otherwise satisfactionmightsuf- fer.
Forimpacts,weenquiredaboutbusinessimpacts,teamimpacts, andsoftwareimpacts. Thedominantfactorwe foundwasabusi- nessfactor:timetomarket.Itseemsthatteamsfindsatisfactionin delivering quickly.Atlesserlevels,teamimpacts suchasavoiding stressandmaintainingproductivitywereseentobeimportant.Al- thoughoursurveyofprofessionalshadmostlydevelopersandlow- level managers, it is interesting to see that business impacts are seenassoimportant:thisappearstoshowthekindofpositivere- lationshipbetweensoftwaredevelopmentandbusinessgoals that Agilemethodsemphasize.
After ourmain analysis, we considered several other perspec- tives,basedon other parts ofoursurvey. The“My Agile” section sought tofindout thepersonal feelingsabouttheprocess.When we lookedatthe factorslinked to satisfaction,thedominantone that emerged wasa concern fortechnical quality.We found this interesting, becausetechnical topics didnot appear so important inouranalysisofpracticesorimpacts.Wethenlookedatstress,a topicwehadexaminedindetailearlier.Thatanalysisshowedthat manyissues relatedtosatisfaction were alsorelatedto stress, so wewonderedwhethersatisfactionwasprincipallyrelatedtostress.
Thatturnedoutnottobeclear:perhapssomestressiscompatible withsatisfaction. Finally,we examined hindrances.In the survey wehadaskedaboutarangeofpotentialhindrances,andouranal- ysisshowedsome arestronglyassociatedwithlowsatisfaction.In particular,thestrongestassociationsallconcerneddifficultieswith managementprocess.
Thispicture suggestssome clear considerations forpractition- ersand educators. Perhaps the most important lesson relates to collaborativepractices:ifweexpectAgilemethodstolead tosat- isfaction,they cannotbe ignored, andmustbe supported. Ased- ucators ourselves,we havealreadybeeninfluenced to emphasize the importance of these practices, even beginning to offer spe- cificcourses(AnslowandMaurer, 2015;Meieretal.,2016;Kropp etal.,2016;Martinetal.,2017;Kroppetal.,2017;Lundqvistetal., 2018). Thiscanbe challengingbecauseoflimitedopportunties to engagewithrealbusinessrequirements,andlimitedtimeforitera- tionsandchange.Forpractitioners,asourresultsabouthindrances show,thechallengesmayrelatetoorganizationalsupport.Inpar- ticular,therole ofself-organization seems critical,andsostudies ofthisareimportant:suchastheworkofHodaetal.(2013).
Forresearchers,thereare avarietyofchallengesraisedby our study.Onearisesfromtheanomalousfindingaboutretrospectives discussedintheprevioussection:atsomepointtoomuchempha- sis isrelated toreduced satisfaction.So we cannot regard collab- orative practices asalways beneficial — or perhaps that in some casespracticeslikeretrospectivesneedtobeconductedwithmore care.Morebroadly,thereisaresearch challengeidentifiedby the dichotomy ofpracticesandimpacts withlittleemphasis ontech- nicalissues,butpersonalfeelingislinked toabilitytofocusmore ontechnicalissues.Onepossibilityissimplythatprofessionalsfeel they know how to address technical quality,but identify collab- orative practices are the key way to ensure time for such con- cerns.Lastly,weshould againconsidertheassociationofsatisfac- tion, self managingteams, and thehindrances related to organi- zationalmanagement.The AgileManifestowasarticulatedalmost twodecadesago,andthepersistance ofdifficultieswithmanage- mentpracticesshouldbecauseforseriousreflection.
Ourstudyhasseverallimitationsthat representthreatstova- lidity. Considering internal validity first, andof particular impor- tanceto thetopicofthispaper, isthat we cannotassume corre- lationreflectsacauseandeffectrelationship.However,ourresults meanweare nowabletoidentifypotential causeandeffectrela- tionshipstoexplore morespecificallyinlater studies.Anotheris- sueis that ourfocus on Agile practices may bias participants to
