AStructuredApproachtoAdoptingAgilePractices: TheAgileAdoptionFramework

AhmedSidky DissertationsubmittedtotheFacultyofthe VirginiaPolytechnicInstituteandStateUniversity inpartialfulfillmentoftherequirementsforthedegreeof DoctorofPhilosophy in ComputerScienceandApplications Approved: ___________________________________________ JamesD.Arthur,Chair _____________________________________ _____________________________________ OsmanBalci ShawnBohner _____________________________________ _____________________________________ ManuelA.PrezQuiones LindaWallace May24,2007 Blacksburg,Virginia Keywords:SoftwareEngineering,AgileDevelopment,AgileAdoption, OrganizationalChange,AgileReadiness,AgilePractices,AgilePotential,AgileLevel

AStructuredApproachtoAdoptingAgilePractices: TheAgileAdoptionFramework
AhmedSidky

ABSTRACT

Many organizations aspire to adopt agile processes to take advantage of the numerousbenefitsthatitofferstoanorganization.Thosebenefitsinclude,butare not limited to, quicker return on investment, better software quality, and higher customersatisfaction.Todatehowever,thereisnostructuredprocess(atleastthat is published in the public domain) that guides organizations in adopting agile practices.Toaddressthissituation,wepresenttheAgileAdoptionFrameworkand theinnovativeapproachwehaveusedtoimplementit.Theframeworkconsistsof twocomponents:anagilemeasurementindex,anda4Stageprocess,thattogether guide and assist the agile adoption efforts of organizations. More specifically, the SidkyAgileMeasurementIndex(SAMI)encompassesfiveagilelevelsthatareused toidentifytheagilepotentialofprojectsandorganizations.The4Stageprocess,on theotherhand,helpsdetermine(a)whetherornotorganizationsarereadyforagile adoption, and (b) guided by their potential, what set of agile practices can and should be introduced. To help substantiate the goodness of the Agile Adoption Framework, we presented it to various members of the agile community, and elicitedresponsesthroughquestionnaires.Theresultsofthatsubstantiationeffort areencouraging,andalsosuggestfurtheravenuesforimprovement.

 DEDICATION

TothepeopleIlovethemostmyparents. Dad,thecoreofthisworkisnamedafteryou:SAMI

iii

ACKNOWLEDGEMENTS

First andforemostIam gratefulandthankful toAllah (God) who blessed me with guidance, good health, and good friends that supported me all through my life. I thank Him for giving me patience and helping me through all the tough times and especially, during the writing of this dissertation. I am also forever grateful to my belovedparentsandsisters,whohelpedmethrougheverystepofmylifetillIhave reached where I am today. The Prophet Mohamad (Peace be Upon Him) said: He who doesnt thank people doesnt thank Allah.1 Below I express my thanks and gratitudetothepeoplewhohavehelpedmecompletethiswork. I have been fortunate to work with Dr. James Arthur. Dr. Arthur exemplifies dedication,perfectionandprofessionalism.Throughouthissupervisionofmywork, he did not act as an advisor only. Rather, he was a close friend who stood by me throughthickandthin.Iwillneverforgetthetimeswesharedtogether,especially eatingSushi. IwouldalsoliketothankDr.OsmanBalci,Dr.ShawnBohner,Dr.ManuelPrez,and Dr.LindaWallaceforservingonmycommittee.Theirhelpandguidancewasvital forthecompletionofthiswork.Also,IamgratefultoDr.SaraThorneThomsenfor helpandadvicethroughoutthewritingofthisdissertation. It has been a blessing to work with the Software Engineering Research Group. My colleagues were very supportive and collaborative. They made the lab a pleasant andfunplacetostudyanddoresearch.Specialgratitudegoestomydearfriendand research partner: Amine Chigani. I would also like to extend my thanks to Ramya RavichanderandShvethaSoundararajan.
1

AbuDawud,Book41:4793 iv

 I would like to thank all my friends, across the globe, who have supported me through encouragement and prayers. At the same time, I would like to mention a specialgroupoffriendswhowenttheextramileandreallysacrificedtimeoreffort forme.Theseare,ZakiBarzinji,TamerDesouky,JamilRenno,KhaledAdjerid,Imad Sheikh,IdrisAdjerid,Dr.MazenArafeh,Dr.EhabElShawarby,OmarHossino,Abdel Shakoor.ThosewhoIforgottomention,pleaseforgiveme. Moreover,IamgratefultothewonderfulMuslimcommunityinBlacksburgandthe United States that had a significant impact on my life. The Muslim community especially the Virginia Tech MSA, VTMUGS and MSA National provided me with moral,spiritualandemotionaladviceandsupportandwerethereformewhenever Ineededthem. LastbutnotleastIamgratefultothecomputersciencedepartment,facultyandstaff and fellow graduate students who were an essential part of my overall learning experience. Yetagain,allthanksandgratitudegoestoAllahonly. (ElHamdelAllah) v

TABLEOFCONTENTS

1.

INTRODUCTION.........................................................................................................................1 1.1. BACKGROUND................................................................................................................................1 1.1.1 TheHistoryofAgility............................................................................................................. 1 1.2. THEAGILEADOPTIONWAVE.......................................................................................................... 3 1.3. MOTIVATIONFORTHEAGILEADOPTIONFRAMEWORK...................................................................... 4 1.4. PROBLEMSTATEMENT.................................................................................................................... 5 1.4.1 IntroducingStructureintotheAgileAdoptionProcess........................................................7 1.4.2 MeasuringandAssessingAgility........................................................................................... 7 1.4.3 AccommodatingProjectandOrganizationalCharacteristics ..............................................8 1.4.4 EffectivelyGuidingtheAgileAdoptionEffort....................................................................... 8 1.5. SOLUTIONAPPROACH..................................................................................................................... 9 1.5.1 Stage1:IdentificationofDiscontinuingFactors................................................................10 1.5.2 Stage2:ProjectLevelAssessment....................................................................................... 11 1.5.3 Stage3:OrganizationalReadinessAssessment.................................................................. 11 1.5.4 Stage4:Reconciliation........................................................................................................ 12 1.6. ORGANIZATIONOFTHISDISSERTATION.......................................................................................... 12

2.

PROCESSIMPROVEMENTANDTHEAGILEADOPTIONFRAMEWORK.................................13 2.1. THEIDEALMODEL..................................................................................................................... 14 2.1.1 OverviewoftheIDEALModel.............................................................................................. 15 2.1.2 IDEAL,SCAMPIandCMMI................................................................................................... 18 2.2. SPILIFECYCLEMODELSFORAGILEDEVELOPMENT....................................................................... 20 2.2.1 ChallengeswithSPIModelsforAgility................................................................................ 20 2.2.2 IDEALandAgility................................................................................................................. 21 2.3. RESEARCHSCOPE:THEAGILEADOPTIONFRAMEWORK................................................................... 23

3.

THEAGILEADOPTIONFRAMEWORK:THE4STAGEPROCESS............................................26 3.1. MOTIVATIONANDCHALLENGES..................................................................................................... 27 3.1.1 TheNeedtoConductaPreAssessment.............................................................................. 28 3.1.2 DesiredState:ProjectorOrganization?.............................................................................. 29 3.2. OVERVIEWOFTHESIDKYAGILEMEASUREMENTINDEX(SAMI)......................................................31 3.3. STAGE1:DISCONTINUINGFACTORS............................................................................................... 37 3.3.1 DeterminingtheDiscontinuingFactors.............................................................................. 38 3.3.2 AssessthePresenceofDiscontinuingFactors..................................................................... 40 3.3.3 MakeGo/NogoDecision..................................................................................................... 43 3.4. STAGE2:PROJECTLEVELASSESSMENT......................................................................................... 45 3.4.1 ProjectLevelAssessment:BackgroundInformation..........................................................46 3.4.2 EstablishingaTargetAgileLevel........................................................................................ 48

vi

3.4.3 LimitingFactors:OrganizationalPerspective.................................................................... 49 3.4.4 LimitingFactors:PracticePerspective............................................................................... 51 3.5. STAGE3:ORGANIZATIONALREADINESSASSESSMENT..................................................................... 54 3.5.1 OrganizationalAssessment:BackgroundInformation ......................................................55 3.5.2 AccomplishingtheOrganizationalReadinessAssessment.................................................57 3.6. STAGE4:RECONCILIATION ............................................................................................................ 62 4. THESIDKYAGILEMEASUREMENTINDEX.............................................................................69 4.1 BACKGROUNDINFORMATIONABOUTMEASUREMENTINDICES..........................................................69 4.2 AGILELEVELS.............................................................................................................................. 72 4.2.1 IdentifyingtheLevelsofAgility........................................................................................... 74 4.2.2 DeterminingtheOrderoftheLevelsofAgility.................................................................... 76 4.3 AGILEPRINCIPLES........................................................................................................................ 81 4.3.1 TheRelationbetweenAgileLevelsandAgilePrinciples .....................................................82 4.3.2 Identifyingthe5AgilePrinciplesusedintheSAMI............................................................83 4.4 AGILEPRACTICES......................................................................................................................... 86 4.4.1 PopulatingAgileLevel1withAgilePractices ..................................................................... 90 4.4.2 AgilePracticeswithinAgileLevel2.................................................................................... 97 4.4.3 AgilePracticeswithinAgileLevel3.................................................................................... 99 4.4.4 AgilePracticeswithinAgileLevel4.................................................................................. 105 4.4.5 AgilePracticeswithinAgileLevel5.................................................................................. 109 4.5 INDICATORS............................................................................................................................... 114 4.5.1 IntroductiontoIndictors................................................................................................... 114 4.5.2 OrganizationoftheIndicators.......................................................................................... 117 4.6 TAILORABILITYOFTHE5LEVELSOFAGILITY ................................................................................ 120 4.6.1 IncorporatingBusinessValues.......................................................................................... 121 4.6.2 ReorganizingPracticesbasedonExperientialSuccess....................................................121 5. SUBSTANTIATINGTHEAGILEADOPTIONFRAMEWORK...................................................123 5.1. THESUBSTANTIATIONAPPROACH............................................................................................... 124 5.1.1 Procedureforgatheringfeedback ..................................................................................... 124 5.1.2 OverviewofSurveyQuestionsandParticipants...............................................................126 5.1.3 Participants........................................................................................................................ 129 5.2. QUANTITATIVEFEEDBACK.......................................................................................................... 132 5.2.1 ResultsconcerningtheSidkyAgileMeasurementIndex(SAMI)......................................132 5.2.2 Resultsconcerningthe4StageProcess............................................................................ 141 5.3. QUALITATIVEFEEDBACK............................................................................................................. 147 5.3.1 TheSidkyAgileMeasurementIndex................................................................................. 148 5.3.2 TheDiscontinuingFactors(Stage1)................................................................................. 152 5.3.3 OtherComments................................................................................................................ 153 6. CONCLUSION..........................................................................................................................156 6.1. 6.2. 6.3. 7. MAINCONTRIBUTIONS ................................................................................................................ 158 FUTUREWORK.......................................................................................................................... 161 SUMMARY..................................................................................................................................164

REFERENCES..........................................................................................................................165

APPENDIXA:INDICATORS.................................................................................................................171 APPENDIXB:EMPTYANDCOMPLETEDSURVEYS...............................................................................235 VITA..................................................................................................................................................236

vii

LISTOFFIGURES
FIGURE1.IDEALMODEL......................................................................................................................16 FIGURE2.CMMIANDSCAMPIRELATIVETOIDEAL................................................................................19 FIGURE3.AGILEADOPTIONFRAMEWORKRELATIVETOIDEAL ..................................................................25 FIGURE4.THE4STAGEPROCESSFORAGILEADOPTION...........................................................................26 FIGURE5.COMPONENTSOFTHEAGILEMEASUREMENTINDEX(INDICATORSARENOTSHOWN)...................................32 FIGURE6.STAGE1:DISCONTINUINGFACTORS..........................................................................................37 FIGURE7.SAMPLEINDICATORSFORDISCONTINUINGFACTORS...................................................................42 FIGURE8.HIERARCHYOFINDICATORSFORDISCONTINUINGFACTORS.........................................................43 FIGURE9.STAGE2:PROJECTLEVELASSESSMENT....................................................................................46 FIGURE10.CRYSTALFAMILYOFMETHODOLOGIES ....................................................................................47 FIGURE11.STAGE3:ORGANIZATIONALREADINESSASSESSMENT...............................................................55 FIGURE12.ORGANIZATIONALCHARACTERISTICSASSESSEDFORAGILEPRACTICESINLEVEL1.......................59 FIGURE13.ORGANIZATIONALREADINESSASSESSMENTRESULTS...............................................................61 FIGURE14.STAGE4:RECONCILIATION....................................................................................................63 FIGURE15.RECONCILIATION(ORGANIZATION>PROJECT)........................................................................64 FIGURE16.RECONCILIATION(ORGANIZATION=PROJECT).........................................................................64 FIGURE17.RECONCILIATIONSTAGE(ORGANIZATION<PROJECT)..............................................................65 FIGURE18.PARTOFTHEORGANIZATIONALREADINESSASSESSMENTRESULTS............................................66 FIGURE19.PLANNINGSPECTRUM..........................................................................................................70 FIGURE20.AGILELEVELS......................................................................................................................80 FIGURE21.LAYOUTOFAGILELEVELSANDPRINCIPLESWITHINSAMI........................................................85 FIGURE22.EMPTYMATRIXOFTHE5AGILELEVELSAND5AGILEPRINCIPLES.............................................85 FIGURE23.AGILELEVELSPOPULATEDWITHAGILEPRACTICESCATEGORIZEDWITHINAGILEPRINCIPLES........89 FIGURE24.AGILELEVEL1UNPOPULATEDWITHPRACTICES.......................................................................90 FIGURE25.AGILELEVEL1POPULATEDWITHONLYONEAGILEPRACTICE....................................................91 FIGURE26.AGILELEVEL1AFTERPOPULATEDTHREEAGILEPRINCIPLES .....................................................94 FIGURE27.AGILELEVEL1POPULATEDWITHAGILEPRACTICES.................................................................96 FIGURE28.AGILELEVEL2POPULATEDWITHAGILEPRACTICES.................................................................97 FIGURE29.AGILELEVEL3POPULATEDWITHAGILEPRACTICES...............................................................100 FIGURE30.AGILELEVEL4POPULATEDWITHAGILEPRACTICES...............................................................106 FIGURE31.AGILELEVEL5POPULATEDWITHAGILEPRACTICES...............................................................110 FIGURE32.ORGANIZATIONALCHARACTERISTICSASSESSEDFORPRACTICEINAGILELEVEL1.......................118 FIGURE33.OVERALLRESULTSFORTHESAMI........................................................................................133 FIGURE34.RESULTSOFTHESAMICATEGORIZEDBYYEARSOFEXPERIENCE.............................................134 FIGURE35.RESULTSOFTHESAMICATEGORIZEDBYROLES....................................................................135 FIGURE36.RESULTSOFTHEAGILEMEASUREMENTINDEXFROMAGILEEXPERTS........................................140 FIGURE37.OVERALLRESULTSFORTHE4STAGEPROCESS......................................................................141 FIGURE38.RESULTSOFTHE4STAGEPROCESSCATEGORIZEDBYEXPERIENCE ............................................142 FIGURE39.RESULTSOFTHE4STAGEPROCESSCATEGORIZEDBYROLE.....................................................143 FIGURE40.RESULTSFORTHE4STAGEPROCESSFROMAGILEEXPERTS....................................................147

viii

LISTOFTABLES
TABLE1.ORGANIZATIONALPROCESSIMPROVEMENTMODELS...................................................................14 TABLE2.THE5AGILELEVELSINDECSENDINGORDER...............................................................................33 TABLE3.THESIDKYAGILEMEASUREMENTINDEX(SAMI)POPULATEDWITHAGILEPRACTICESANDCONCEPTS................36 TABLE4.ASSESSMENTTABLEFORTHEDISCONTINUINGFACTOR:INAPPROPRIATENEEDFORAGILITY............41 TABLE5.NOMINALVALUESFORAGGREGATEDINDICATORS.......................................................................43 TABLE6.ASSESSMENTRESULTSFORDISCONTINUINGFACTORS..................................................................44 TABLE7.THESAMIWITHLIMITEDAGILEPRACTICESUNDERLINED..........................................................52 TABLE8.THESAMIWITHNONLIMITEDAGILEPRACTICESUNDERLINED...................................................58 TABLE9.AGILEVALUESREPRESENTEDBYAGILELEVELS ............................................................................76 TABLE10.THE5AGILELEVELSINORDER...............................................................................................78 TABLE11.COCKBURN'SLEVELS............................................................................................................103 TABLE12.SAMIPOPULATEDWITHAGILEPRACTICES............................................................................113 TABLE13.SAMPLEINDICATORSTOBEANSWEREDBYTHEDEVELOPER......................................................116 TABLE14.SAMPLEINDICATORSTOBEANSWEREDBYTHEMANAGER.........................................................116 TABLE15.READINESSASSESSMENTTABLE(RAT)FORCOLLABORATIVEPLANNING...................................119 TABLE16.TWOPAGESURVEYQUESTIONSABOUTTHESIDKYAGILEMEASUREMENTINDEX........................127 TABLE17.TWOPAGESURVEYQUESTIONSABOUTTHE4STAGEPROCESS .................................................128 TABLE18.PARTICIPANTINFORMATIONONROLESANDAGILEEXPERIENCE...............................................130 TABLE19.CATEGORIZATIONOFPARTICIPANTSBYTHEIRROLESANDYEARSOFEXPERIENCE.......................131

ix

1. Introduction
This dissertation presents the Agile Adoption Framework. This framework is a structured approach to guide and assist the process of introducing agile practices into organizations. The present chapter provides a brief history of agile practices and the problems organizations can face when opting to move toward agility. The discussionofthehistoryandproblemsmotivatesthecreationoftheAgileAdoption Framework.

1.1. Background
The work presented in this research is primarily within the area of software engineering.Morespecifically,thisresearchfitswithintheareaofsoftwareprocess improvement and organizational change. This section presents a brief history of agilitystartingwiththepioneeringworksuptothecurrentresearchinthefieldof agileadoption.Wealsoidentifytheinsufficiencythatmotivatedthecreationofthe AgileAdoptionFramework.

1.1.1 TheHistoryofAgility
The main goal of Software Engineering consists of the establishment and use of sound engineering principles and methods to obtain economic software that is reliable and works on real machines [15]. These governing engineering principles and methods form the software development process. After realizing the significanceofsoftwaredevelopmentprocessesinproducinggoodsoftware,many efforts arose to identify the most suitable software development methodologies. OneofthepioneersinthisquestwastheSoftwareEngineering Institute(SEI).The SEIintroducedtheCapabilityMaturityModelforSoftware(CMMorSWCMM)tothe software development community in 1986. The CMM is a process maturity frameworkthathelpsorganizationsimprovetheirsoftwareprocessthroughasetof recommendedpracticesinanumberofkeyprocessareas[40].

Withtheendofthetwentiethcenturyandthebeginningofanewmillennium,the software market presented new challenges to the software development industry. Some of these challenges are pressure for accelerated product development, minimumtimetomarket,customersdemands,andreducedbudgets.Traditionalists using the Capability Maturity Model (CMM) and the improved Capability Maturity Model Integration (CMMI) preferred extensive planning, codified processes and otherrigorousmeanstomakedevelopmentmoreefficientandpredictable.Hence, theyweregraduallyleadingthedevelopmentprocesstowardsperfection[19].Many believedthatthetraditionalistsapproachofferedthebestsolutionfortheproblems ofthesoftwareindustry;butothersdidnot. Seventeen practitioners sympathetic to finding an alternative to the detailed plan drivendevelopmentapproachconvenedinFebruary2001[45].Theoutcomeofthis meeting,TheManifestoforAgileSoftwareDevelopment[18],declares: We are uncovering better ways of developing software by doing it andhelpingothersdoit.Throughthisworkwehavecometovalue: Individualsandinteractionsoverprocessesandtools Workingsoftwareovercomprehensivedocumentation Customercollaborationovercontractnegotiation Respondingtochangeoverfollowingaplan Thatis,whilethereisvalueintheitemsontheright,wevaluethe itemsontheleftmore. The creation of this manifesto brought to light many different agile development processes and methods and helped many others emerge. A short list of the well known agile methods includes Extreme Programming (XP), Scrum, the Dynamic Systems Development Method (DSDM), Agile Modeling (AM), Adaptive Software Development(ASD),LeanDevelopment(LD),CrystalMethodsandFeaturesDriven Development(FDD).Manyothersexist. 2

1.2. TheAgileAdoptionWave
Atfirst,organizationswereskepticalaboutadoptingagilesoftwaremethodologies. Information technology (IT) executives were asking the agile community why shouldweadoptagilepractices?Theagilecommunityprovided atangiblehands on answer exemplified by the numerous pilot projects and smallscale transitions thatoccurredinorganizations.Theresultswereimpressiveandempiricalevidence showed that embracing agile practices yielded many benefits [85],[76], [12], [11], [61],and[59],including: Earlyreturnoninvestment Shorttimetomarket Improvedquality Enhancedclientrelationships Betterteammorale

Thenumeroussuccessstorieshighlightingthebenefitsreapedbyorganizationsthat havesuccessfullyadoptedagilepracticeshaveprovidedasufficientanswertothose whoweredoubtfulaboutadoptingagilepractices.Thequickandwidepublication ofthesesuccessstorieshavecausedtheagileadoptionwavetogrowstrongerand progressfaster. Manyanticipatedandnoticedthewaveofagileadoption.InCorporateITLeadsthe SecondWaveofAgileAdoption,areportreleasedonNovember30,2005Forrester Researchnoted: Agile software development processes are in use at 14% of North American and European enterprises, and another 19% of enterprises are either interested in adopting Agile or already planningtodoso.Earlyadoptersofagileprocesseswereprimarily smallhightechproductcompanies.Butasecondwaveofadoption is now underway, with enterprise IT shops taking the lead. These

shopsareturningtoagileprocessestocuttimetomarket,improve quality, and strengthen their relationships with business stakeholders. Other surveys and published research, such as the Agile 2006 survey by Digital Focus,theStateofAgileDevelopmentsurveyconductedbyVersionOne,andtheAgile Adoption Rate survey conducted by Scott Ambler, all show evidence that agile adoptionisontherise.

1.3. MotivationfortheAgileAdoptionFramework
Withthegrowthofagileadoption,thequestionof whytoadoptagilepracticeswas quickly being replaced with how to adopt agile practices [46]. The tone of those interestedinAgileshiftedfromaskingaboutexampleswhereagilityworks,ordoes not, to asking for guidance and assistance on how to implement agility in their particularcases. Although it was possible to point to numerous successful agile adoptions, these successstoriescannotbegeneralized.Manyofthemweretoonarrowlyfocusedata specific organization. These success stories cannot provide useful guidance and assistancetoanotherorganizationwithadifferentsetofneeds.However,themere presenceofsuchsuccessstoriestriggeredpeopletoaskifthesameapproachwould work at their organization. Thus, the need for a set of generic guidelines to help identify the right agile practices for an organization considering moving to agility became evident. These guidelines also needed to warn of possible pitfalls in adopting certain agile practices, outline the order in which practices should be adoptedandprovideanswerstomanyotherquestionsrelatedtoagileadoption. Even though consultants or agile coaches could provide answers to many of these questions, it is important to realize that such answers were based on their own experiences.Inmanycases,theknowledgeofagilecoacheswaslimitedtothetype and size of projects they were involved with. Typically, after the completion of a

project, consultants reflect on what worked and what failed. They would then retune their adoption approach for their next project. Some of them had even captured these skills in publications and have suggested to the agile community somesuccessfulpractices,orwhattobecarefulofwhenadoptingagility[71,46,67, 19]. These contributions are valuable and do provide those seeking to adopt agile withsomelevelofguidanceandassistance.However,thisadviceisnotstructured inastructuredapproachofthesortreallyneededtoguideeffortsoforganizationsin adoptingagilepractices. Like consultants, researchers have developed a limited number of approaches to help and guide people with agile adoption. For example, Bohem designed a frameworktoguideagileadoptioneffortsbasedontheassessmentofvariousrisks. Bohemsframeworkisveryhelpfulasitprovidesthoseseekingtoadoptagilewitha waytocarefullybalanceagilityanddiscipline.WhileBohemsworkishelpful,one of its drawbacks related to agile adoption is that it addresses agility in its generic form,insteadoffocusingonactualpractices.Organizationsseekingtoadoptagility stillneedsometangibleapproach.Theyarestillrequiredtoidentifytheactualagile practicesthatarethebestfitfortheirorganizationbeforeattemptingthemoveto agility. With the agile adoption wave growing, and with the absence of structured and disciplinedguidanceandassistancefromtheagilitycommunity,thereisaneedfora new approach to help address the concerns surrounding how to adopt agile practices.

1.4. ProblemStatement
This research addresses the current absence, at least in the public domain, of a structured approach to guide agile adoption efforts. Furthermore, a rigorous formalization of what constitutes agility is also missing. Organizations aspiring to become agile want to know when they are considered agile, as well as what it meanstobeagile.Moreover,guidelineshighlightingwhatis neededtohelpagile

adoption efforts succeed are unavailable. These guidelines are essential for determining if any activities or tasks are overlooked during the adoption process. The lack of a structured approach for agile adoption causes organizations to questionhowtoidentifytherightpracticestoadopt,howtodetermineiftheyare readyforagile,whatthenecessarypreparationsforagileare,andwhatthepotential difficultiesthatcoulddevelopduringtheadoptionprocessare. The contributions consultants and researchers have made are valuable, and have developed the foundations for guiding agile adoption efforts. However, the lack of structure in some approaches and the lack of focus on agile practices (a problem Bohems approach exemplifies) prevent these contributions from ultimately providingstructuredguidanceandassistancetoorganizationsonhowtoadoptagile practices. Furthermore, because of the narrow focus of these approaches, even whentheyprovidesomeguidance,itisnotcomprehensiveenough,becauseitonly treatsasmallaspectoftheadoptioneffortordrawsontheprocessusedatasingle organization with specific parameters and expectations. Therefore, what the agile industryneedsisasetofrepeatableguidelines(aframework)thatagilecoachescan usetodetermineanorganization'sreadinessforembarkingonthejourneytoward agilityandtoguidetheactualadoptionprocess. To develop a framework that can provide organizations with comprehensive guidance and structured assistance for their agile adoption journey, a number of issues have to be addressed. Among the most important and challenging of these issuesarehowto: introducestructureinacomplexandunpredictableprocesslikethatofagile adoption measureandassessagilityindependentofagilemethods accommodate project and organizational characteristics influencing agile adoptionefforts

ensure that the framework guides the adoption effort in an efficient and effectivemanner.

Thenextsectionsbrieflyelaborateoneachoftheseissues.

1.4.1 IntroducingStructureintotheAgileAdoptionProcess
Transitioningorganizationstoagilityisanunpredictableprocess.Thisismainlydue to several aspects of the organization including, but not limited to, its structure, people,culture,andmanagementpractices.Allofthesefeaturescanaffecttheeffort atanypointinthejourneytoadoptingagility.Hence,akeyissuethatariseswhen developing a framework to guide and assist with adoption efforts is how to encompass the efforts of such an organizationwide change phenomenon within a comprehensivestructuredframework.Someofthemanyquestionsarisingfromthis issueare: how to develop a framework that provides enough structure to guide and assistagileadoptioneffortswhilenotdictatingthem how the framework can determine the agile practices most suitable for the organizationtoadopt how to capture the order in which agile practices should be adopted in the organization how the framework should handle situations where the organization is not readyforcertainagilepractices.

1.4.2 MeasuringandAssessingAgility
Measurement and assessment are substantial components of many process improvement efforts, including the move to agility. Therefore, a measurement approachisneededwhenanalyzingthecurrentagilityoftheprocessandidentifying its agile potential. The main challenge is how to measure or assess agility for a projectororganizationindependentofaparticularagilemethodology.Someofthe factorscontributingtothischallengeare:

identifyingasuitablemeasurementscaleforagility determiningtheaspectsofthedevelopmentprocessthatneedtobeassessed toconcludeitsagility finding a way to aggregate the assessment results of all these different aspectsinamannerthatenablestheassessortodeterminetheagilityofthe projectororganization.

1.4.3 AccommodatingProjectandOrganizationalCharacteristics
Agile processes accommodate and adapt to different situations and environments, andthetransitiontoagilityshouldbenodifferent.Althoughtheframeworkguiding agile adoption needs to be repeatable, it also needs to accommodate the changing natureofprojectswithinanorganization,justasagileprocessesaccommodatethe changingnatureofrequirementsinaproject.Eachsoftwaredevelopmentprojectis unique and surrounded by unique characteristics. In light of this, another challengingissueishowtodevelopaframeworkthatcanaccommodatetheunique characteristics of each project within the organization. Some of the challenges relatedtothisissueare: addressing adoption efforts related to individual projects without overlookingtheoverallorganization howtodifferentiatebetween,andhandle,projectcharacteristicsthatcanbe changed,aswellasthosethatcannotbecausetheyareoutside theprojects and/ororganizationscontrol. dealing with scenarios where a projects ability to adopt agile practices is differentfromanorganizationsabilitytoadoptagilepractices.

1.4.4 EffectivelyGuidingtheAgileAdoptionEffort
Effectiveness is a key principle of agile development processes. To uphold this principlewhentransitioningorganizationstoagilitybringsaboutanotherchallenge: howtoensurethattheframeworkisguidingthetransitiontoagilityinaneffective

manner. Ensuring that such a complex process (i.e. agile adoption) is conducted effectivelyischallengingduetoanumberoffactors,including: determining if the organization is ready for transitioning to agility before committing any resources to the adoption effort. It is clearly ineffective to waste time, effortandmoneyon tryingto transitionanorganization that is notreadyforagility. Ensuringbeforestartingtheactualadoptionprocessforaparticularpractice thattheorganizationisreadytoadoptthatpractice;againcommittingtime, effort and money trying to introduce a practice into an organization that is notreadyforthepracticeisineffective designing the framework in a way that it assesses and measures only the aspectsoftheorganizationthatarenecessaryandsufficient,andavoidsany extraeffortsthatdonotdirectlycontributetotheadoptioneffort.

1.5. SolutionApproach
The Agile Adoption Framework presented in this dissertation is a structured and efficient approach to guide agile adoption efforts within projects without overlooking the organizational aspect of the adoption process. The Agile Adoption Framework tackles the four issues mentioned in the previous section through its uniquedesign and structure.Theframeworkhastwomain components: the Sidky Agile Measurement Index (SAMI) and a 4Stage process that utilizes SAMI to determine which, and to what extent, agile practices can be introduced into the organization. Thefirstcomponent,SAMI,servesthreeimportantpurposes. It serves as a tool to measure and assess the agile potential of an organization independent of any particular agile method (e.g. XP, Scrum etc)

It provides a scale for identifying the target agile level for a project aspiringtoadoptagility. The measurement index helps the coach organize and group the agile practices in a structured manner based on essential agile qualities and businessvalues.

It provides a hierarchy of measurable indicators used to determine the agilityofanorganization.

However,SAMIbyitselfdoesnotguideorganizationsadoptingagilepractices.The second component of the Agile Adoption Framework, the 4Stage process, uses SAMItoguideorganizationsbyidentifyingtheagilepracticesthataremostsuitable for their environment. Each of the four stages within this component of the framework (4Stage process) are carefully sequenced and designed to ensure that theadoptionprocessisconductedinahighlyeffectivemanner.Thefourstagesare: Stage1:IdentificationofDiscontinuingFactors Stage2:ProjectLevelAssessment Stage3:OrganizationalReadinessAssessment Stage4:Reconciliation

The 4Stage process introduces the structure into the agile adoption process because each stage has clearly defined inputs, outputs and objectives. The next sections elaborate briefly on each of the four stages while showing how they help providestructuredandefficientguidanceandassistancetoorganizationsadopting agilepractices.

1.5.1 Stage1:IdentificationofDiscontinuingFactors
SinceadoptingagilepracticesisessentiallyatypeofSoftwareProcessImprovement (SPI),theorganizationneedstoundergoapreassessmentphasebeforeitmakesthe decisiontostarttheinitiative.Therefore,theobjectiveofthisfirststageistoidentify whetheranorganizationiscapableofembarkingonthejourneyoftransitioningto

10

agility. This is accomplished by providing organizations with a means to decide whether or not to proceed with agile adoption initiatives. Conducting such an assessmentbeforeanyeffortisputintotheadoptioninitiativeisefficientbecauseit saves the organization from committing valuable time and resources to a SPI initiativethatisdestinedtofail.ThisstageiscompletedwheneitheraGoorNogo decisionmadeatthebeginningoftheagileadoptioneffort.

1.5.2 Stage2:ProjectLevelAssessment
Stage 2 starts once a Go decision is made from Stage 1. The main objective of this stageistoidentifythehighestlevelofagilitythata projectcanachieve.Stage2hasa projectlevel focus because each project in an organization is unique. This implies that each project in the organization can function at different levels of agility. Therefore, in this stage, the focus is on identifying and assessing the existence of projectlevel factors, especially those outside the organizations control, that have the potential to jeopardize the success of the adoption of agile practices. This assessment process is accomplished by utilizing the assessment indicators identified within SAMI. This stage ends once a target agile level (from SAMI) is identifiedforaprojectaspiringtoadoptagilepractices.

1.5.3 Stage3:OrganizationalReadinessAssessment
TheinputneededforStage3istheprojectstargetagilelevel,whichisdetermined in Stage 2. The objective of Stage 3 is to determine the extent to which the organization isready to support the adoption of the projects target agile level. To determine this, an assessment is conducted, using SAMI, that looks at how accommodatingthedifferentcomponentsoftheorganization(i.e.developers,tools, cultureetc) are for the adoption of the agile practices contained within the projects target agile level. By identifying what each agile practice needs for its successful adoption, and then determining whether the organization meets these needs, the organization is able to discover the necessary preparations it needs to

11

undertaketoadoptthedesiredagilepractices.Theoutputofthisstageisthelevelof agility(fromSAMI)theorganizationisreadytoadopt.

1.5.4 Stage4:Reconciliation
TheReconciliationstagebeginsafteratargetagilelevelfortheprojectisidentified (fromStage2)andanorganizationalreadinessagilelevelisdetermined(fromStage 3).Theobjectiveofthisstageistoreconcileanydifferencethatmayexistsbetween thesetwolevels.Duringthisstage,thedifferencesbetweenthepracticestheproject wantstoadopt(i.e.theprojectstargetagilelevel)andthepracticestheorganization can adopt (i.e. organizations readiness level) are resolved. By resolving these differences (if any), this stage results in determining the set of agile practices that aremostsuitablefortheorganizationtoadopt. The Agile Adoption Framework assists the agile community in supporting the growing demand from organizations that want to adopt agile practices. However, the framework is only one essential ingredient; the other is an agile coach who knowshowtoapplythatframework.Suchapersoncanbeanagileconsultanthired to facilitate the process, or an inhouse employee with sufficient training in agile methodsandtheuseoftheframework.Theremainderofthisdissertationpresents in detail how the different components of the Agile Adoption Framework are designedandutilizedtoprovideguidanceandassistancetoorganizationsonhowto transitiontoamoreagilesoftwaredevelopmentprocess.

1.6. OrganizationofthisDissertation
Thenextchapter,Chapter2,discussesthenotionofSoftwareProcessImprovement (SPI) and its relation to the Agile Adoption Framework. Chapter 3 presents the structure and details of the Sidky Agile Measurement Index (SAMI). Each of the stages in the 4Stage process is then presented in detail in Chapter 4. Chapter 5 presents industry feedback regarding the framework. Finally, Chapter 6 provides concludingremarksabouttheAgileAdoptionFramework.

12

2. ProcessImprovementandtheAgileAdoption Framework
Sinceadoptingagilepracticesisessentiallyaprocessimprovementeffort,itisuseful totheunderstandingofthecomponentsoftheAgileAdoptionFrameworktodiscuss some generic process improvement frameworks and models. This chapter, therefore,focusesontheconceptofsoftwareprocessimprovementanditsrelation toadoptingagilepractices. This chapter also puts the Agile Adoption Framework in perspective in terms of overall process improvement efforts. Edward Deming, one of the pioneers of applyingstatisticalprocesscontrolinindustry,hasdescribedprocessimprovement asacontinuouscycleofsixsteps[83]: 1. Understandthestatusofthedevelopmentprocess 2. Developavisionofthedesiredprocess 3. Listimprovementactionsinorderofpriority 4. Generateaplantoaccomplishtherequiredactions 5. Committheresourcestoexecutetheplan 6. Startoveratstep1 Demings steps essentially provide a skeleton for process improvement efforts. Deming is even more famous for the cycle he created. ShewartDemings cycle consistsoffoursteps(Plan,Do,Study,Act)thatcapturethe sameprinciplesashis six steps, but at a higher and more generic level. ShewartDemings Cycle can be appliedtoprocessimprovementeffortsinanydomain. Instead of building the discussion in this chapter around ShewartDemings Cycle, the focus is on a more detailed model (influenced by Deming) that was originally developed for Software Process Improvement (SPI) efforts. A number of different improvement models are used to support continuous, topdown SPI in

13

organizations. Some of these are the Quality Improvement Paradigm (QIP) [14], IDEAL(acronymforInitiating,Diagnosing,Establishing,ActingandLearning)[66], and ISO/IEC 15504 Part 7 [52]. Table 1 shows the different phases of all the mentioned organizational process improvement models and their relation to the ShewartDemingCycle[74].
ShewartDeming Cycle QIP IDEAL ISO/IEC15504 Examineorganizations Needs

Characterizeandunderstand Initiating Plan Setgoals Diagnosing

Chooseprocesses, methods, techniques and Establishing tools Do Check Act Execute Analyze Packageand storeexperience Acting

Initiateprocessimprovement Prepareandconduct processassessment Analyze results and derive actionplan Implementimprovements Confirmimprovements Sustainimprovementgains Monitorperformance

Learning

Table1.OrganizationalProcessImprovementModels

TheIDEALandISO/IEC15504modelsarethebestcandidatestousetodiscussagile processimprovementefforts.However,duetothesimilaritiesbetweenthemodels, instead of focusing on two SPI organizational models, IDEAL will serve as the referencemodelbecauseitismorewidelyusedandclaimsseniorityintermsofage overtheISO/IEC15504model.

2.1. TheIDEALModel

AtthementionofSPI,manyimmediatelythinkofSPIframeworkssuchasCapability Maturity Model Integration (CMMI), ISO 15504 (SPICE), ISO 9001 and so forth. However, this almost automatic response raises the question of where do these

14

frameworks fit in the overall process improvement effort of an organization. For example,CMMIidentifiesthestepsalongthepathofprocessmaturity,butdoesnot treat how to sustain the progress or provide the context for these changes. The IDEAL process model fills this gap by providing an organizational model for software process improvement. In other words, it provides an overarching model for CMMI and the other process improvement frameworks. The IDEAL model is cyclical,whichimpliescontinuousprocessimprovement.Thatis,itachievesregular and continuous improvement by continuing to go through the cycle of initiating, diagnosing,establishing,actingandlearning.

2.1.1 OverviewoftheIDEALModel

TheIDEALmodelprovidesadisciplinedengineeringapproachforimprovement.It focusesonmanagingtheimprovementprogram,andestablishesthefoundationfor alongtermimprovementstrategy.Themodelconsistsoffivephases: IInitiating:Layingthegroundworkforasuccessfulimprovementeffort. D Diagnosing: Determining the present state and desired state and developingrecommendationsforimprovement. E Establishing: Planning the specifics of how to reach SPI initiatives target. AActing:Doingtheworkaccordingtotheplan. L Learning: Learning from the experience and improving the ability to adoptnewtechnologiesinthefuture. Eachofthefivephasesismadeupofseveralactivities.Figure1showsthephases andactivitieswithineachofthephasesofIDEAL. Usually in SPI efforts, a team of specially trained individuals, headed by an experienced change agent, oversees and conducts the execution of the overall

15

organizationalchangeandimprovementprocess.Thephasesguidingthisteamare presentedingreaterdetail:

Figure1.IDEALModel[66]

The Initiating Phase: The team completes the critical groundwork during the initiating phase. It clearly articulates the business reasons for undertaking the process improvement effort. It identifies the effort's contributions to the goals and objectives of the business. The team secures thesupportofcriticalmanagers,andarrangesfortheallocationofresources. Finally, it puts in place an infrastructure for managing implementation details. The activities of the initiating phase are critical. If they are done completely and properly, subsequent activities can proceed with minimal disruption.Iftheyaredonepoorly,incompletely,orhaphazardly,thentime, effortandresourceswillbewastedinsubsequentphases.

16

 The Diagnosing Phase: This phase builds upon the initiating phase to develop a more complete understanding of the improvement work. During the diagnosing phase, the SPI team determines two characterizations of the organization: the current state of the organization and the desired future state. It uses these organizational states to develop an approach for improving the practice of the business. Characterizing the current and desiredstatesissimilartoidentifyingtheoriginanddestinationofajourney. Theteamcancharacterizethesetwostatesmoreeasilybyusingareference standard (or measurement index) such as the Capability Maturity Model (CMM). The recommendations the team develops as a part of this activity suggestawayofproceedinginsubsequentactivities. TheEstablishingPhase:Thepurposeoftheestablishingphaseistodevelop a detailedwork plan. The SPI team sets therecommendations made during the diagnosing phase, as well as the organization's broader operations and theconstraintsofitsoperatingenvironment.Then,theSPIteamdevelopsan approach that honors and factors in the priorities. Finally, the team incorporates the specific actions, milestones, deliverables and responsibilitiesintoanactionplan.

The Acting Phase: The activities of the acting phase help an organization implementtheworkthattheSPIteamhasconceptualizedandplannedinthe previousthreephases.Theseactivitiestypicallyconsumemorecalendartime andmoreresourcesthanalloftheotherphasescombined.

The Learning Phase:Thelearningphasecompletestheimprovementcycle. OneofthegoalsoftheIDEALModelistocontinuouslyimprovetheabilityto implement change. In the learning phase, the SPI team reviews the entire

17

IDEAL experience to determine what has been accomplished, whether the effortachievedtheintendedgoals,andhowtheorganizationcanimplement change more effectively and/or efficiently in the future. The SPI team must keeprecordsthroughouttheIDEALcyclewiththisphaseinmind. InhisthesistitledDevelopmentandEvaluationofSoftwareProcessImprovement MethodsKomiSirviprovidedadetaileddiscussionofSPImodelsandframeworks thatcomplementthisbriefintroductiontoIDEAL[58]. Beforediscussingagilityandprocessimprovement,itisimportanttoexplainwhere CMMI and the Standard CMMI Appraisal Method for Process Improvement (SCAMPI)fitwithintheIDEALmodel,becauselaterithelpsexplainwheretheAgile AdoptionFrameworkfitswithintheSPIinitiativesforagilesoftwaredevelopment.

2.1.2 IDEAL,SCAMPIandCMMI
TheCMMIisthebasicmeasurementindexforsoftwaredevelopmentcapabilityand maturity in an organization. The SCAMPI appraisal method is used to identify strengths, weaknesses and ratings relative to the CMMI measurement index. DiagnosesfromSCAMPIappraisalsshouldbepartofaprocessimprovementcycle such as IDEAL. In the IDEAL cycle, the SPI team uses SCAMPI appraisals and the CMMI primarily in the diagnosing phase to characterize the current and desired states of the organization, and to develop the process improvement recommendations.Figure2showshowtheCMMIandtheSCAMPIareusedinthis phase. Additionally,theSCAMPIandCMMIindirectlyaffecttheactivitiesoftheEstablishing stageofIDEAL.Thisstagefocusesonprioritizingthechangesthattheorganization needs to make and developing an action plan for the process improvement effort. The sequencing of the CMMI levels along with the appraisal approach the SCAMPI

18

uses implicitly dictates a certain prioritization of these process improvement changes. For example, an organization at CMM Level 2 gives a higher priority to establishing the key process areas highlighted in CMM Level 3 than those in CMM Level5.ThepurposeCMMIandSCAMPIserveintheestablishingphaseistoprovide direction to the activities in this phase, not to directly conduct these activities. Consequently,theyarenotofficiallyconsideredpartofthestage.

Figure2.CMMIandSCAMPIrelativetoIDEAL

The presentation of a generic SPI lifecycle model (IDEAL) and the relationship betweenitandotherprocessimprovementmethodsandframeworks(SCAMPIand CMMI) leads to further discussion of the SPI lifecycle model, but from the perspective of adopting agile practices in the next section. The next section also

19

includes a discussion of the relationship between the Agile Adoption Framework andSPImodels.

2.2. SPILifeCycleModelsforAgileDevelopment
Moving an organization toward having an agile development process through the adoption of agile practices is a type of process improvement effort. Organizations are increasingly recognizing the need for specific implementation guidance when theyadoptnewsoftwareengineeringtools,processesandmethods.Becausemany softwareprocessimprovementefforts,includingtheadoptionofagilepractices,are complex with effects far reaching in the organization, they require a systematic approachformanagingtheprocessimprovementlifecycle. WhilemanyagilepractitionersarecriticalofCMMandanythingrelatedtoCMM(e.g. IDEAL),thereisnodoubtthatthereismuchtolearnfromthe CMMbasedprocess improvementefforts.Oneimportantlessonhighlightstheneedtoapproachprocess improvement efforts in a systematic manner, instead of chaotically. In fact, some level of guidance and structure should exist for all process improvement efforts, includingagilesoftwaredevelopment,nomatterwhattheanticipatedoutcomeis.

2.2.1 ChallengeswithSPIModelsforAgility
There are several challenges to overcoming the perceived incompatibility of SPI models and agile software development. One challenge is the limited number of referencesdirectlyaddressingtheissueoforganizationalSPI withinthecontextof agile software development. A reason for this might be that most of these SPI models were not originally developed for agile processes. For example, since McFeeley originally designed IDEAL as a life cycle model for software process improvement based upon the SoftwareCMM (SWCMM) [66], many agile

20

consultants have perceived it to be incompatible with agile approaches. Their rationale behind that perception is the infeasibility to have plandriven process improvement models used when the target development method is agile. This reasoningisinvalid,becausethemodificationsmadetothesemodels,astheyexist today, to fit a wide range of process improvement domains suggest they can be modifiedtofitagileadoptionefforts.Thisleadstothesecondreasonfortheclaim thatSPImodelsarenotapplicabletoagileadoptionefforts.Thefocusofnumerous agile methodologies is on the project level activities of software development, but SPImodelsaddressissuesonanorganizationallevel[55]. This difference in focus between agile methodologies and SPI models is a valid concern for not using traditional SPI models with agile software development. However,SPImodelssuchasIDEALprovideenoughguidanceandbenefittomakeit irrational to throw them all away, because they focus on an organizational level ratherthanaprojectlevel.TheAgileAdoptionFrameworkisnotaSPIlifecyclefor agiledevelopment;noristhefocusofthisresearchtoprovideacompleteSPIlife cycleforagilesoftwaredevelopment.TheAgileAdoptionFramework,likeSCAMPI and CMMI, needs to live within a SPI lifecycle model. The Agile Adoption FrameworkcanbeusedwithaSPIlifecyclemodelsuchasIDEALorISO/IEC15504 whenthemodelisslightlymodified.Thesemodificationschangetheinitialstagesof themodeltobothcatertotheprojectandorganizationallevelsoftheagileadoption effort. Therefore,sincetheAgileAdoptionFrameworkcanalterIDEALtoincludeaproject focus, it is still possible to use IDEAL as an overall guidance model for agile SPI initiatives.

2.2.2 IDEALandAgility
In general, IDEAL or similar SPI models (e.g. ISO/IEC 15504) do not demand or provide any specific SPI methods for conducting different SPI activities. Instead,

21

theysuggestthestepsnecessarytoachievecontinuousimprovement,thusserving asaroadmapforimprovementinorganizations.Thissectionprovidesabrieflookat the steps and phases of IDEAL with the idea of using this model to guide an organization adopting agile practices. Again, the intent of this research is not to modify IDEAL for use with agile adoption, but to present it to provide the context andestablishtheoverallpictureofwheretheAgileAdoptionFrameworklieswithin theoverallprocessofSPI. TheSPIinitiativeusingIDEALstartswithastimulusforchange.Inthecaseofagile processimprovement,thisstimulususuallycomesfromanorganizationsaspiration tobecomemoreabletoadapttochangeortoincreaseproductqualityortohavean earlierreturnoninvestmentoranyoftheotherbenefitsthat theadoptionofagile practices can realize for an organization [85], [76], [12], [11], [61], [59]. Once a stimulusforchangeoccurs,theIDEALlifecyclebegins. Intheinitiatingphase,theSPIteamstillneedstobuildthecontextofthisdesireto movetowardsagilitywithintheorganization.Theteamisalsorequiredtoalignthis transition with the organizations business strategy and build sponsorship for the change.Othershavementionedthesamestepshighlightedintheinitiatingphaseof IDEALasbestpracticeswhenadoptingagilepractices[19,31].Therefore,simply followingawellestablishedmodellikeIDEALforprocessimprovementcansavethe agileadoptionindustrybothtimeandeffortsortingoutwhatworksfromwhatdoes notworkforanorganization.Ofcourse,thisisnosilverbullet,butitdoessavethe agileadoptionindustryfromreinventingthewheelorlearningfromscratch. Oncetheinitiatingphaseprovidesthegroundworkforthemovetowardagility,the SPI team moves to the diagnosing phase to assess and further analyze the current agile state of the organization until it can develop a set of recommendations concerning the agile practices the organization should adopt. Working from these recommendationsintheEstablishingstage,theSPIteamdevelopsadetailedwork plan that takes into consideration the current environment and constraints of the 22

organization. With this information, the SPI team implements the process improvement efforts in the Acting stage. The Learning stage consists of reviewing the changes and reflecting on the change process. If the review shows that the objective of the improvement has not been attained, another cycle of process improvement that takes into consideration what was learned from the previous cyclecommences. Onceagain,itisimportanttokeepinmindthattheSPIteamsimplyusesIDEALhere toprovideguidancetoagileadoptioneffortsandnottodictatethem.

2.3. ResearchScope:TheAgileAdoptionFramework
Sincethescopeofthisresearchdoesnotincludedevelopingortailoringacomplete process improvement lifecycle for agile adoption efforts, the discussion of IDEAL fulfills the objective of creating the groundwork or foundation for such a lifecycle. LikeIDEAL,whichneedstheCMMIandSCAMPIforitsfoundations,anagileprocess improvementlifecycleneedsanagilemeasurementindexandaprocessormethod that uses this measurement index to diagnose the organizations readiness and to guide the process improvement effort. This measurement index and the ensuing process are the scope of this research. The Agile Adoption Framework consists of twocomponents,theSidkyAgileMeasurementIndex(SAMI)anda4Stageprocess that uses SAMI. These two components work together to provide a first step in guidingorganizationstowardadoptingagilepractices. As developed, these two components enable others to start using a process improvement lifecycle, such as IDEAL, to guide their adoption efforts. The challenges, as highlighted in Chapter 1, are to create an agile measurement index and develop a process that efficiently uses this measurement index to guide the adoptionefforts.Anothermajor challenge,asmentionedearlier,istocreatethe4

23

stageprocessoftheAgileAdoptionFrameworkinamannerthataddressesproject levelfactorsofagileadoptionaswellasorganizationalfactors. The mapping of the Agile Adoption Framework to IDEAL primarily covers the activities of the Diagnosing stages, while partially influencing the Initiating and Establishing stages. Figure 3 illustratesthe areas of IDEAL that the Agile Adoption Frameworkaddresses. The Agile Adoption Framework addresses the objectives of the Initiating phase of IDEAL via the first stage of its 4stage process, Identifying Discontinuing Factors. Whilethisfirststagedoesnotmapexactlytotheactivitieshighlightedintheoriginal IDEALmodel,thisstageassessestheorganizationtodeterminewhetheranyfactors are present that would prevent the adoption process from continuing. As in the initiating phase of IDEAL, one of factors to be assessed in the first stage of the 4 stageprocessissponsorshipsupportfortheprocessimprovementinitiative. InplaceoftheDiagnosingphaseofIDEAL,theAgileAdoptionFrameworkusesthe 4Stage process and the agile measurement index to determine a target agile level foraprojectanddevelopasetofrecommendedagilepracticesfortheorganization toadopt.LikeSCAMPI,theAgileAdoptionFrameworkalsoidentifiesthestrengths or weaknesses in the organization relative to the practices recommended for adoption. However, unlike SCAMPI, the framework does not include a set of best practices that highlight how to overcome the weaknesses. Instead, the Agile Adoption Framework provides guidance on prioritizing the weaknesses to be addressed.ThisishowtheAgileAdoptionFrameworkinfluences thethirdstageof IDEAL,Establishing.TheActingandLearningstagesofIDEALareoutsidethescope ofthisresearch.

24


Figure3.AgileAdoptionFrameworkrelativetoIDEAL

Chapter 3 provides a detailed discussion of the main component of the Agile Adoption Framework, the 4Stage process. The chapter includes an explanation of howexactlyeachofthe4stageshelpsprovideguidancetoorganizationsadopting agilepracticesfrombothaprojectandorganizationalperspective.Additionally,the chapter provides a brief overview of the Sidky Agile Measurement Index (SAMI). Chapter 4 then presents the details of the SAMI and an explanation of how it was created.

25

3. TheAgileAdoptionFramework:The4StageProcess
TheAgileAdoptionFrameworkisastructuredandrepeatableapproachdesignedto guideandassistagileadoptionefforts.Itassiststheagilecommunityinsupporting the growing demand from organizations that want to adopt agile practices. The main component of the Agile Adoption Framework is the 4Stage Process, which utilizes the Sidky Agile Measurement Index (SAMI) to help an organization adopt agilepractices.TheSAMIisascaletheagilecoachusestoidentifytheagilepotential ofaprojectororganization.
No-go

Stage 1: Discontinuing Factors Stage 2: Project Level Assessment

Suspend Adoption Effort Go Target Agile Level for the Project

Stage 3: Organizational Assessment

Target Agile Level for the Organization

Stage 4: Reconciliation
Agile Practices to Adopt

Figure4.The4StageProcessforAgileAdoption

As depicted in Figure 4, the 4Stage Process consists of four pieces that work together to help the assessor determine if (or when) an organization is ready to movetowardagility,or,inotherwords,makethego/nogodecision,andassistshim or her in the process of identifying which agile practices the organization should adopt.Thefourstagesare: Stage 1: Discontinuing Factors.Discoversthepresenceofanyroadblocks(or showstoppers)thatcanpreventtheadoptionprocessfromsucceeding

26

Stage 2: Project Level Assessment. Utilizes the SAMI to determine the target levelofagilityforaparticularproject Stage 3: Organizational Readiness Assessment. Uses the SAMI to assess the extenttowhichtheorganizationcanachievethetargetagilitylevelidentified foraproject

Stage 4: Reconciliation. Determines the final set of agile practices to be adoptedbyreconcilingthetargetagilelevelforaproject(fromStage2)and thereadinessoftheembodyingorganization(fromStage3)

This chapter focuses on the backbone of the Agile Adoption Framework, the 4 StageProcess.Thechapterstartsbypresentingsomeofthechallengesencountered inthedevelopmentofthe4StageProcess.Section 3.2presentsanoverviewofthe SAMI, since the 4Stage Process utilizes it. (Chapter 4 provides the details of the SAMI.)Thelatterpartofthischapterincludessectionsoneachofthefourstagesof the4StageProcess.

3.1. MotivationandChallenges
The objective behind the creation of the Agile Adoption Framework is to provide organizationswithguidanceonwhichagilepracticestoadopt.SimilartoCMMIand SCAMPI,predecessorsoftheAgileAdoptionFramework,theframeworkconsistsof twomaincomponents,anagilemeasurementindexandaprocesscomponentthat uses the measurement index to provide the organization with guidance. The first threephasesofIDEAL(Initiating,DiagnosingandEstablishing)providetheprimary sources of inspiration in determining the nature and structure of the process component of the framework. The objective was not to replicate these phases of IDEAL,buttolearnfromthemwhatisneededtoguideanorganizationthroughthe adoptionofanewtechnology,includingagilepractices. Analysis of the objectives of these three stages of IDEAL results in a process that comprisesthefollowingfourstructuredstages:

27

1. DiscontinuingFactors 2. ProjectLevelAssessment 3. OrganizationalReadinessAssessment 4. Reconciliation The decision to call this a process is based on the definition of the word process. According to the American Heritage Dictionary, one definition for a process is a series of actions, changes, or functions bringing about a result. Since these four stagesdoexactlythis,theyhavebeentitledthe 4Stage Process.Thedetailsofeach of these four stages follow, but are proceeded by a discussion of two of the main issuesthatinfluencedthecreationofthesefourstages.Thefirstissueisrelatedto the need of conducting preassessments, and the second concerns whether the desired state of agility should be addressed from a projectlevel perspective or an organizationallevel.

3.1.1 TheNeedtoConductaPreAssessment
Traditional Software Process Improvement (SPI) models, based on the Capability MaturityModel(CMM)andCMMIntegration(CMMI),recommendthatthedecision to start a SPI initiative be made after a trained assessor has conducted a pre assessment of the organization in order to determine whether it is ready for SPI [43]. Organizations that do not embody the factors necessary for a successful SPI effortareconsiderednotready.Inthissituation,theSPIeffortissuspendeduntil the missing factors become present. Preassessment is also important in an agile adoption initiative, because it helps identify factors in an organization that can prevent the successful adoption of agile practices. If such factors exist, the organization must eliminate them before continuing with the adoption effort. This preassessmentphasesavestheorganizationtime,moneyandeffortbyidentifying upfrontmissingorexistingfactorsthatcancausetheSPIoragileadoptioneffortto fail[53].

28

Additionally, conducting an assessment in order to decide whether or not to go aheadwiththeefforttointroduceagilepracticesisimportantbecauseofadditional lossesthat Technical Chaoscanprecipitate.Technicalchaos,thedisruptionscaused by the partial adoption of new practices, leaves the development process in an unstablestateuntilitrevertsbacktotheoriginalengineeringpracticesusedbefore thefailedadoptioneffort.Technicalchaosislikelytooccurwhenanagileadoption effort starts and then fails before completion. As a result, the stage titled Discontinuing Factors was created to ensure that the organization makes the decision to adopt agile practices only after finding no factors present that can jeopardizetheadoptioneffort.

Thenextissuethatinfluencedthedevelopmentofthe4StageProcesswaswhether thedesiredstateofagilityshouldbeaddressedfromanorganizationalperspective oraprojectperspective.

3.1.2 DesiredState:ProjectorOrganization?
This challenge exists because most of the traditional SPI models and frameworks have an organizational focus. It is common in SPI to identify the current level of processmaturityofthewholecompany(currentstateoftheorganization)andthen determine the desired level for the whole organization (desired state of the organization).IDEAL,CMMIandtheISO15504discussthecurrentstatesordesired states in terms of the whole organization, and not in terms of current or desired statesforindividualprojects.Thisfocusmakessense,becausetheseSPIinitiatives are working to instill certain principles and Key Process Areas (KPAs) across the wholeorganization.Theirobjectiveistoseetheseprinciples andKPAsevidentfor everyprojectintheorganization. However,adoptingagilepracticesisdifferentbecausethefocusisnotonprinciples orKPAs,butontheadoptionofagilepractices.Thegoalofagileadoptioninitiatives is to ensure the implementation of these principles and KPAs in the organization

29

throughtheuseofagilepractices.ForexamplesinceRequirementsManagementisa KPAforCMMLevel2,theobjectiveistoensurethatagilepracticesareusedtofulfill thegoalsofthisKPA.Thisexplainswhyadoptingagilepracticesinanorganization is not in opposition to achieving higher CMM levels. Moreover, within the same organization, the KPA of Requirements Management can be manifested through different practices, depending on the project. The requirements management needed for a government project differs in the way it is implemented from that needed for a social networking portal. Since every project is different and is surrounded by unique circumstances (customers, location, team and so forth) the agilepracticesusedforoneprojectareoftenunsuitableforanotherproject. TheabovediscussionillustrateswhytraditionalSPIinitiativesaddressthedesired stateissuefromanorganizationalperspectiveandwhySPIinitiativesthatfocuson adopting agile practices need to address the same issue, but from a project perspective.Thisconclusionanswerstheinitialchallengeofwhethertoaddressthe desired state of agility from a project perspective or from an organizational perspective. The answer is that both need to be addressed. Since each project is different, the agile practices that are suitable for one project may or may not be suitable for another. Therefore, each project needs a specific target level of agility (thedesiredstate).Atthesametime,itisimportanttorecognizethatthisprojectis livingwithinanorganizationand,therefore,itisnecessarytotakeintoaccountthe organization too. The organizational assessment determines if the organization is readyfortheprojecttoadoptitstargetagilelevel. Since there was no stage responsible for developing recommendations, a fourth stage titled Reconciliation has been added to the Agile Adoption Framework. The Reconciliation stage isresponsible for comparingthe target projectagile leveland theorganizationsreadinesslevel,andreconcilingthedifferencesbetweenthetwo levelsinamannerthatyieldsrecommendationsonhowtoreach thedesiredagile levelfortheproject. 30

The 4Stage Process is assists organizations in determining their readiness to undertake an initiative to adopt agile practices. Additionally, the four stages help organizations determine which practices to adopt while identifying organizational weaknesses that might affect their adoption.After completing the4StageProcess, anorganizationneedstocreateaplantostrengthentheidentifiedweaknesses,and planfortheadoptionoftheidentifiedagilepractices.Withtheseplansinplace,the organizationadoptsthepracticesandthenconfirmsthesuccessoftheadoption.As mentioned in Chapter 2, the steps to complete agile adoption (occurring after the completion of the four stages of the framework) are outside the scope of this research. The remainder of this chapter provides a detailed explanation of each of the four stages,includinghoweachcontributestotheoverallobjectiveofprovidingguidance to organizations aspiring to adopt agile practices. However, since the 4Stage Process relies on the Sidky Agile Measurement Index (SAMI) for many of its assessments, the next section provides a brief description of that measurement index.Chapter4presentsadetaileddescriptionoftheSAMI.

3.2. OverviewoftheSidkyAgileMeasurementIndex(SAMI)
Oneofthemainconcernsorganizationshavewhenseekingtoadoptagilepractices isdetermininghowagiletheycanbecome[39].Theagilepotential(i.e.thedegreeto which that entity can adopt agile practices) of projects and organizations is influencedbythecircumstancessurroundingthem.Todeterminetheagilepotential the coach (or the one conducting the assessment) needs to use a measurement index orscalethat can assessthepotentialagilityofanentity. TheAgile Adoption FrameworkusestheSidkyAgileMeasurementIndex(SAMI)todeterminetheagile potential of a project or organization. The SAMI that is composed of four components:

31

Agile Principles
A 5 5 B C D E 5

Agile Principles
A B C D E

Agile Levels

Agile Levels

4 3 2 1

Agility Increases

4 3 2 1

Agile Levels
(b) Empty Agile Levels with Agile Principles

4 3 2 1

(a) Empty Agile Levels

(c) Agile Levels populated with Agile Practices categorized within Agile Principles

Figure 5. Components of the Agile Measurement Index (Indicators are not shown)

1. AgileLevels:asetofagilepracticesthatarerelatedand,whenadopted collectively,makesignificantimprovementsinthesoftwaredevelopment process,therebyleadingtotherealizationofacorevalueofagility 2. AgilePrinciples:guidelinesthatneedtobeemployedtoensurethatthe developmentprocessisagile 3. AgilePracticesandConcepts:theconcreteactivitiesandpractical techniquesusedtodevelopandmanagesoftwareprojectsinamanner consistentwiththeagileprinciples 4. Indicators:questionstheexaminerusestoassesscertaincharacteristicsof anorganizationorproject,suchasitspeople,cultureandenvironment,in ordertoascertainthereadinessoftheorganizationorprojecttoadoptan agilepractice. Chapter4detailsthedevelopmentprocessoftheSAMIandeachofitscomponents. This section presents a simple overview of the measurement index as a whole, withoutfocusingonanyparticularcomponent,aswellasthenameandobjectiveof eachofthefivelevels.Figure 5showsthecomponentsoftheSAMI.

32

Agile levels, as depicted in Figure 5a, are considered the units of the SAMI as they enumerate the possible degrees of agility for a project or organization. The agile potentialofaprojectororganizationisexpressedintermsthehighestagilelevelit can achieve. The attainment of a particular level indicates that the project or organizationhasrealizedandembracedtheessentialelementneededtoestablisha commensurate agile development process. For example, when the elements inherent to enhancing communication and collaboration are embodied within the development process, then the Agile Level 1 (Collaborative) is attained. However, beforeaprojectcanexpecttomovetoLevel2status,allpracticesassociatedwith Agile Level 1 must be achieved or achievable. The agile levels represent the core qualities of agility as defined by the Agile Manifesto [2]. The objective of the level refers to the agile quality the level seeks to achieve or introduce into the developmentlifecycle.Table2showsthefivelevelsindescendingorder.
AgileLevel Level5 Level4 Level3 Level2 Level1 LevelName Encompassing Adaptive Effective Evolutionary Collaborative LevelsObjective(AgileValueReworded) Establishingavibrantandallencompassingenvironmentto sustainagility Respondingtochangethroughmultiplelevelsoffeedback Developinghighquality,workingsoftwareinanefficientan effectivemanner Deliveringsoftwareearlyandcontinuously Enhancingcommunicationandcollaboration

Table2.The5AgileLevelsindecsendingorder

Each of the agile levels is composed of a set of agile practices, that when adopted, helpsaccomplishthe levelsobjective.Thesecondcomponentofthemeasurement index, agile principles, guides the assignment of agile practices and concepts assignedtoeachlevel. Agileprinciplesaretheessentialcharacteristicsthatmustbereflectedinaprocess before it is considered Agile. For example, two key agile principles are human centric, which refers to the reliance on people and the interaction between them, 33

and technical excellence, which implies the use of procedures that produce and maintainthehighestqualityofcodepossible.TheSAMIusesfiveagileprinciplesto ensurethattheagilelevelsembodytheessentialcharacteristicsofagility.Figure5b illustratestherelationshipbetweenagilelevelsandagileprinciples.Thetoprowof Table 3enumeratesthoseprinciples. Each agile level contains practices associated with most, if not all, of the agile principles. The principle reflects the approach that the agile practice uses to promote the agile quality pertinent to a level. For example, all of the practices in Level 3 (Effective) promote the agile objective of developing high quality, working software in an efficient an effective manner. How an objective is achieved is determined by the practices associated with agile principles spanning each level. Along the same lines, practices associated with the technical excellence principle promote its agile objective by focusing on enhancing the technical aspect of the process; while practices associated with the humancentric principle promote enhancing the human aspect of the process. More about agile principles can be foundinChapter4. The realessence ofthe agile measurement index, however,istheagile practices it enunciates. Agile practices are concrete activities and practical techniques used to develop and manage software projects in a manner consistent with the agile principles. For example, paired programming, user stories, and collaborative planningareallagilepractices.Sincetheagilelevelsarecomposedofagilepractices (organizedalongthelineofagileprinciplesseeFigure5c),theyareconsideredthe basic building block of the SAMI. The attainment of an agile level is achieved only whentheagilepracticesassociatedwithitareadopted.TheSAMIispopulatedwith 40 distinct agile practices. Table 2 illustrates these practices, arranged along the linesoftheagilelevelsandprinciples. 34

A set of indicators, or questions, must accompany each agile practice or concept in themeasurementindex.TheSAMIcontainsapproximately300differentindicators. The agile coach uses these indicators or questions to measure the extent to which the organization is ready to adopt an agile practice or concept. Each indicator is designed to measure a particular organizational characteristic necessary for the successfuladoptionoftheagilepracticetheindicatorisrelatedto.Dependingonthe question, a manager, developer, or agile coach is designated to answer it, either subjectively or objectively. All the organizational characteristics that need to be assessed, along with the indicators needed to assess them, are placed in the Readiness Assessment Table (RAT) associated with each agile practice. RATs are explainedinfurtherdetailinthediscussionoftheIndicatorscomponentoftheSAMI inChapter4. Asanexampleoftheabove,assumetheassessorwantstodeterminetheextentto which the organization is ready to adopt coding standards (Level 1, Technical Excellence).Thetwoorganizationalcharacteristicsthatneedtobeassessedare:(1) towhatextentdothedevelopersunderstandthebenefitsbehindcodingstandards, and(2)howwillingaretheytoconformtocodingstandards.Severalindicatorsare usedtoassesseachofthesecharacteristics.Forexample,toassesswillingness,the assessor might ask the developers to what extent would they abide by coding standardsevenwhenunderatimeconstraint.

35

Agile Principles Embrace Change to Deliver Customer Value Level 5 Encompassing Establishing a vibrant environment to sustain agility Low process ceremony [60, 72] Plan and Deliver Software Frequently Agile project estimation [29] Human-centric Ideal agile physical setup [60] Technical Excellence Test driven development [16] Paired programming [84] No/minimal number of level -1 or 1b people on team [24, 22] Level 4 Adaptive Responding to change through multiple levels of feedback Client driven iterations [60] Continuous customer satisfaction feedback [64, 77] Smaller and more frequent releases (4-8 weeks) [64] Adaptive planning [60] [29] Daily progress tracking meetings [8] Agile documentation [73, 57] User stories [30] Customer immediately accessible [22] Customer contract revolves around commitment of collaboration [45, 64] Customer Collaboration Frequent face-toface interaction between developers & users (collocated) [17]

Level 3: Effective Developing high quality, working software in an efficient an effective manner

Risk driven iterations [60] Plan features not tasks. [29] Maintain a list of all features and their status (backlog) [57]

Self organizing teams [60, 72, 57, 27] Frequent face-to-face communication [72, 27, 18]

Continuous integration [60] Continuous improvement (refactoring) [57, 17, 41, 7]. Unit tests [50] 30% of level 2 and level 3 people [24, 22]

Level 2: Evolutionary Delivering software early and continuously

Evolutionary requirements [60]

Continuous delivery [60, 57, 45, 17] Planning at different levels [29]

Software configuration management [57] Tracking iteration progress [60] No big design up front (BDUF) [5, 17]

Customer contract reflective of evolutionary development [45, 64]

Level 1: Collaborative Enhancing communication and collaboration

Reflect and tune process [64, 77]

Collaborative planning [72, 27, 60]

Collaborative teams [80] Empowered and motivated teams [18]

Coding standards [51, 82, 68] Knowledge sharing tools [60] Task volunteering [60]

Customer commitment to work with developing team [18]

Table 3. The Sidky Agile Measurement Index (SAMI) populated with agile practices and concepts

TheSAMIisusedintheprocesscomponentoftheframework,whichconsistsoffour stages working together to guide organizations in identifying agile practices that best fit into their environment. After this brief introduction to the SAMI, the 36

remainder of this chapter illustrates how the 4Stage Process uses the SAMI to provideorganizationswithguidanceandassistance.

3.3. Stage1:DiscontinuingFactors
The objective of the first stage of the 4Stage Process is to provide organizations with a method for reaching a decision on whether or not to proceed with agile adoption initiatives. As Figure 6 shows, to achieve this goal, Stage 1 provides organizations with an assessment process that identifies the factors that could prevent the successful adoption of agile practices. These are called discontinuing factors and can vary from one organization to another. Stage 1 suggests that organizationsfollowthreestepsinordertofulfilltheobjectiveofthisstage: 1. Determinethelistofdiscontinuingfactors 2. Assesstheextentofthepresenceofdiscontinuingfactors 3. MakeGo/Nogodecisionbasedonassessmentresults
No Discontinuing factors found

Agile Adoption Initiative

No Added Business Value No Finances No Executive Buy-In

Proceed to Stage 2

Any discontinuing factor found

Suspend adoption of Agile till circumstances become more supportive

Figure6.Stage1:DiscontinuingFactors

37

Thefollowingsubsectionsprovideadiscussionoftheimportanceofthisstageand detaileddescriptionsoftheactualstepsthattakeplaceduringthisstage. ThisdiscussionbeginswithadescriptionofhowStage1oftheprocessguidesand assistsorganizationsinmakingGo/Nogodecisionsconcerningtheadoptionofagile practices.Apreassessmentactivitythatidentifiesanydiscontinuingfactorsaidsin making this decision. The next three sections provide a detailed discussion of the processthatshouldbefollowedduringthisstage.

3.3.1 DeterminingtheDiscontinuingFactors
The first step in Stage 1 of the 4Stage Process is to identify the factors that could adversely impact the agile adoption process. These Discontinuing Factors are organizational characteristics that, if present in an organization, can hinder or jeopardize the success of the agile adoption process. These factors can vary from organization to organization and from one agile consultant to another. They typicallypertaintoanorganizationsresourcesincludingmoney,timeandeffort,as wellasthesupportoftheexecutives. TheIDEALmodelisasourceofinspirationforidentifyingdiscontinuingfactors.The Initiating phase of IDEAL helped identify two factors that, if absent from an organization, could prevent the success of the agile adoption effort. These two discontinuingfactorsare: Inappropriate Need for Agility: This refers to situations where, from a businessorsoftwaredevelopmentperspective,adoptingagilitydoesnotadd any value. This factor was derived from the initial input of the initiating phaseofIDEAL,Stimulusforchange. Absence of Executive Support:Ifcommittedsupportfromexecutivesponsors isabsent,theneffectiveandsubstantialchangeintheorganizationisunlikely

38

tooccur.ThisfactorwasalsoderivedfromtheinitiatingphaseofIDEALthat emphasizesthepresenceofSponsorshipbeforethestartoftheSPIeffort. Areviewofvariousadoptioncasesvalidatestheidentificationofthesetwofactors as discontinuing factors. Several authors note that these two factors could hinder the adoption process if present. For example, the first two factors that Spayd [79] highlights as needed to realize success in the adoption of agile practices are the counterpartsofboththesefactorsderivedfromIDEAL.Cohn[31],Eckman[37],and Pukinskis[71]allsupporttheideathatthelackofexecutive buyinorsponsorship is a factor that can jeopardize the success of any process improvement effort, especiallyrelativetoagile. A third discontinuing factor is the lack of sufficient funds. When funds are unavailable or insufficient to support the agile adoption effort, then an adoption process is not feasible [37]. As obvious as this factor is, it is important to be conscious of it, especially if the change effort is going to be managed inhouse. Usually, if a consultant is hired to conduct the adoption process, he or she makes surethatsufficientfundsareavailablebeforetheengagementstarts. Another discontinuing factor initially included is the type of the project, because mission or lifecritical projects are not suitable candidates for agility. This assumptionisbasedontheworkofBoehmandotherswhoargueagiledevelopment isnotsuitableformissionandlifecriticalsystems[4][69][19][24].However,since more and more agile development can be found in the mission and lifecritical projects [56] [54] [35], some of the authors that maintained this position arenow changingtheirpointofview.Therefore,thetypeofprojectnolongerneedstobea discontinuingfactor,eventhoughthelevelordegreeofagilityusedformissionand lifecriticalsystemsmightbedifferent.Thisrealizationresultedinapapershowing how to use the concepts of the agile adoption framework to identify the practices suitableforthedevelopmentofmissionandlifecriticalsystems[78].

39

As mentioned earlier, these are not the only discontinuing factors. Other organizationsorconsultantscanidentifyotherdiscontinuingfactors.However,the key to identifying these factors is to think of what could stop or hinder the agile adoptionprocess,regardlessofthenumberofagilepracticesbeingadopted. When an organization demonstrates any of these discontinuing factors, it is unpreparedtomovetowardsagilityandshouldsuspendtheadoptionprocessuntil the environment is more supportive. With the discontinuing factors identified, the nextstepistoemploytheprocessusedtoassesstheirpresenceintheorganization.

3.3.2 AssessthePresenceofDiscontinuingFactors
Once the assessor or the organization has identified the discontinuing factors, the nextsteptowardagileadoptionistoascertaintheextentofthepresenceorabsence ofthesefactors.LiketheapproachusedbytheSAMI,thisstepreliesonindicatorsto assessthedegreetowhichadiscontinuingfactorispresentorabsent.Indicatorsare questionsthatpeopleintheorganizationortheassessorhimselforherselfanswer. Depending on the factor, indictors measure the specific organizational characteristicsthatdirectlyinfluencetheexistenceofthatdiscontinuingfactor. Forexample,todeterminewhetheranorganizationlacksthesufficientfundsforthe agileadoptioneffort,oneoftheorganizationalcharacteristicsmeasuredisthedollar amountoffundsallocatedtotheprocessimprovementeffort.Anothercharacteristic measured is the ability to actually spend the funds for agile adoption. At least one indicator,thoughmorearepreferable,isusedtoassesseachofthesecharacteristics. Anexampleofaquestionorindicatorusedtoassesstheabilitytospendfundson agile adoption is Can the funds be spent on any process improvement activity? AnotherindicatorisArethereanyrestrictionsonthetypeofactivitiesthesefundscan beusedfor? Each discontinuing factor has an assessment table that highlights the different organizational characteristics that the assessor needs to assess in order to determinetheextenttowhichthefactorispresent. 40

Categoryof Assessment

Areatobe assessed

Characteristic(s)to beassessed

Todetermine: Whetherornottheprojects requirementsareclearandwelldefined, thuspredictingnochange,orwhetheror nottherequirementsneedtobeflexible and/ormightchange Whetherornottheprojecthastobe developedquicklyinordertointroduceit tothemarketassoonaspossible Whetherornottheorganizationhasa trendofhavingprojectsthatgoovertime andbudget Whetherornottheorganizationisfacing anyproblemsordissatisfactionwiththe currentsoftwareprocess

Assessment Method

Sample Indicators DC_M5,DC_M6, DC_M7

Requirements Project Delivery ProjectHistory Organization Software Process

RateofChange

Interviewing

TimetoMarket Scheduleand Budget Problems

Interviewing Observation Interviewing

DC_M4 DC_A1,DC_A2 DC_D1,DC_D2, DC_D3,DC_M1, DC_M2,DC_M3

Table4.AssessmentTablefortheDiscontinuingFactor:InappropriateNeedforAgility

For example, Table 4 depicts the assessment table used for the first discontinuing factor, Inappropriate Need for Agility. The assessor uses this factor to determine whether or not there is any value added by adopting agile software development. Thefirstverticalcolumninthetableidentifiesthegenericorganizationalareatobe assessed.Thenextverticalcolumnspecifieswhichaspectoftheorganizationalarea needs assessment. The third column designates the actual organizational characteristic to be assessed. In this example, the assessor needs to assess four different characteristics in order to measure the existence or absence of this discontinuingfactor.Oneofthesecharacteristicsisthe rate of changeoftheproject requirements. The fourth column, To determine, defines the goal behind the assessment of this characteristic. The fifth column provides information on the methodusedtoconducttheassessmentandthelastcolumnprovidesareferenceto the actual indicators the assessor uses for each particular organizational characteristic.Theindicatornumberisusedtoidentifyandreferencetheindicator. The first two letters in the indicators number (DC) mean that the assessors use these indicators for assessment of DisContinuing factors. The letter after the underscore(_)referstothetypeofpersonwhoshouldprovideananswerforthe indicator: A: denotes an indicator that the assessor, or the person conducting the assessment,needstoanswer

41

D: denotes an indicator that the developer, or anyone on the development sideoftheproject,needstoanswer M:denotesanindicatorthatamanager, oranyoneperformingmanagement relatedtasksfortotheproject,needstoanswer

A sequential number is used as the last digit in the indicators number. Figure 7 showssomesampleindicators,whichusuallyconsistofastatementorquestionthat needs a response. Most indicators are based on a 5point Likert summated scale, from1stronglydisagreeto5stronglyagree.Asmallnumberofotherindicators are based on other 5point scales that are more appropriate to the organizational characteristicbeingassessed.

Figure7.SampleIndicatorsforDiscontinuingFactors

Figure8showstheorganizationalcharacteristicsthatneedto beassessedforeach ofthediscontinuingfactors.Theassessoruses21differentindicatorstoassessthe discontinuing factors. Appendix A contains the assessment tables for all three factorsalongwithall21indicatorsusedtoassessthem.

42

Discontinuing Factors
Inappropriate Need for Agility Historical Project Schedules and Budgets (A=2) Challenges with current software process (D=3,M=3) Rate of Change of Project Requirements (M=3) Time to Market Needed for Project (M=1) Lack of Sufficient Funds Availability of Funds (M=6) Absence of Executive Support Executive Management Buy-in (M=3)
Figure8.HierarchyofIndicatorsforDiscontinuingFactors

AppendixAalsohighlightsthemethodusedtoaggregatetheresultsofthedifferent indicatorstocomeupwithonenominalvalue,asshowninTable5.Theaggregate result of the answers to the indicators (the nominal value) shows the extent to whichthatfactorispresentor absentintheorganization.Thedecisiontoproceed with the adoption effort, or abandon it, is based on the nominal values for all the factors.Thenextsectionprovidesadiscussionofthisstep.
NotAchieved PartiallyAchieved LargelyAchieved FullyAchieved 0%35% 35%65% 65%85% 85%100%

Table5.NominalValuesforAggregatedIndicators

3.3.3 MakeGo/NogoDecision
Oncetheassessmentprocesshasidentifiedthedegreetowhicheachdiscontinuing factorispresentintheorganization,itmovestothethirdstepwithinStage1ofthe 4Stage Process of the Agile Adoption Framework. During this step, the assessor

43

recommends proceeding with the agile adoption effort or abandoning it based on the absence of discontinuing factors. To receive the green light, the degree of absenceforeachofthediscontinuingfactorsmustfallbelowanacceptablethreshold for the organization. While this seems a little counterintuitive at first, since the assessment is for discontinuing factors whose presence is a hindrance to the adoptionprocess,theirabsenceisagoodsign.Inotherwords,thegoalistohaveall the discontinuing factors score a Not Achieved. The greater the presence of discontinuing factors in the organization, the worse the situation is. For example, assumeTable6showstheassessmentresultsforanorganization.Theorganization has decided to go ahead with the agile adoption effort when the level of discontinuingfactorswasfoundtobebelow35%(NotAchieved).However,because one or more of the discontinuing factors was found at a level higher than the threshold, the assessor has recommended a Nogo decision. Since the level of presenceofthediscontinuingfactor, Lack of Sufficient Funds, washigherthan35%, thereisaNogodecisiontocontinuetheagileadoptioneffort.Theadoptionprocess is suspended until the conditions changed and a reassessment showed that the presenceofthediscontinuingfactorhaddroppedbelowthethreshold.
DiscontinuingFactors
InappropriateNeedforAgility LackofSufficientFunds AbsenceofExecutiveSupport Not Achieved 0%35% Partially Achieved 35%65% Largely Achieved 65%85% FullyAchieved 85%100%

Table6.AssessmentResultsforDiscontinuingFactors

Eachorganizationcansetitsownthresholdsfordifferentfactors.Forexample,one organization might decide to suspend the adoption process if any discontinuing is partiallyachievedorhigher(35%to100%).However,anotherorganizationmight have the same rule, but set a higher threshold for one of the factors. For example, theorganizationmighttolerateahigherthreshold(below65%) foronlythefactor related to funds. In this case, the example shown in Table 6 would generate a Go decisionbecausethefundsfactorisbelowitsthreshold(65%)andtheotherfactors

44

are already Not Achieved. Again, these thresholds are left to the stakeholders to determine. Clearly,itisnecessarytoensurethatorganizationshavethecapabilitytointroduce agilepracticesintotheirprocessbeforestartingsuchaprocessimprovementeffort. Iftheyarenotready,thentheymayunnecessarilycommittoaninitiativethatcan havedetrimentalconsequenceslater. Insummary,Stage1providesguidancetoorganizationsneedingtodecidewhether to start the agile adoption effort. Identifying and assessing the absence of discontinuing factors in the organization determines an organizations ability to proceed with the introduction of agile practices. Once the stakeholders decide to proceedwiththeagileadoptioneffort,theguidanceprocessentersthesecondstage ofthe4StageProcesstheprojectlevelassessment.

3.4. Stage2:ProjectLevelAssessment
Afterthestakeholdersmakethedecisiontogoaheadwiththeagileadoptioneffort (from Stage 1), the next stage looks at the individual projects that will adopt agile practices and determines which level of agility (based on the SAMI) each should adopt. Since each project is different and is surrounded by unique circumstances, eachprojectneedstoadoptalevelofagilitythatisbestsuitableforit. Figure9depictsanoutlineoftheapproachusedinStage2to determinethetarget agilelevelforeachproject.Theassessorstartsbyassessing certainfactorsrelated to Agile Level 1. If this assessment is positive, the assessor proceeds to assess factors related to the next agile level. The level at which the assessment fails is identifiedasthehighestagileleveltheprojectcanreach(i.e.targetagilelevel). Section 3.4.2describesthedetailsofhowlimitingfactorsoutsidetheorganizations control,influencethetargetlevelestablishedforeachproject.Theselimitingfactors are discussed from an organizational perspective as well as a practicebased

45

perspective.Butfirst,Section3.4.1givessomebriefbackgroundaboutthenotionof projectbasedagility.

Target = Level 5

Encompassing

Yes
Target = Level 4 Adaptive

?
Yes

No
Effective Effective

Target = Level 3

? No
Yes
Target = Level 2 Evolutionary

? No
Yes
Target = Level 1 Collaborative

Figure9.Stage2:ProjectLevelAssessment

3.4.1 ProjectLevelAssessment:BackgroundInformation
Practitioners and researchers alike accept the idea of having different degrees of agile software development based on the type of project. One of the more famous agile methodologies based on the premises that each project is different and, therefore,necessitatesdifferentdegreesofagility(orprocess)isCockburnsCrystal Family [24] [26]. The Crystal family includes a number of different methodologies andthecriticalityandsizeofeachindividualprojectguides thechoiceofthemost suitablemethodologyfortheproject.

46


Figure10.CrystalFamilyofMethodologies[24][26]

Figure 10 shows that each member of the Crystal family is marked with the color indicatingtheheavinessofthemethodology,i.e.thedarkerthecolortheheavierthe methodology.Thecharactersymbolsindicatethepotentiallosscausedbyasystem failure(i.e.C=Comfort,D=DiscretionaryMoney,E=EssentialMoney,andL=Life).The numeral beside the character symbol represents the number of the people on the project.TheimportanceoftheCrystalfamilyisthatCockburn giveseachprojecta differentmethodologydependingonthecriticalityandsizefactorsoftheproject. Little followed the same concept as Cockburn with his Adoptive Agility but identifiedfactorsotherthancriticalityandteamsizetodeterminetheappropriate methodology for the project. Little classified projects according to Complexity Attributes(whichincludedteamsizeandcriticality)andUncertaintyAttributes[63] [62].Basedontheassessmentofthesetwosetsofattributes, aprojectisclassified intooneoffourprojecttypes: DogsSimpleprojectswithlowuncertainty ColtsSimpleprojectswithhighuncertainty

47

CowsComplexprojectswithlowuncertainty BullsComplexprojectswithhighuncertainty

Little did not define a set methodology for each of the four project types, but he highlighted some agile practices that are suitable for each project type. Both Cockburns Crystal Family and Littles Adaptive Agility demonstrate the possibilityofselectingdifferentfactorstodeterminetherightdegreeofprocessor process agility for a particular project. The development of Stage 2 of the 4Stage Process is indebted to the work of Cockburn and Little. However, Stage 2 differs fromtheworkofothers,becausethelevelofagilityaprojectcanreachisnotbased oneithercriticalityandsizeastheCrystalFamilyorthecomplexityanduncertainty, as Adaptive Agility is, but on the absence of factors outside the organizations control that are needed to adopt an agile practice. The next sections present, in greaterdetail,theapproachStage2usestodeterminethetargetlevelofagilityfora project.

3.4.2 EstablishingaTargetAgileLevel
Stage 2 is the first stage of the adoption process that utilizes the SAMI presented briefly in Section 3.2. The objective of this stage is to identify the highest level of agilityaprojectcanachieve.Thisiscalledthetargetagilelevelandisoneofthefive agilelevelsdefinedintheSAMI. The important question is how the target level is identified for each project. The first step to answering this question is to recall the design of the SAMI. In it, each agile level is composed of a set of agile practices. Each one of these practices is associated with a set of indicators that assesses different aspects or factors of the organization to determine the extent the organization is ready to adopt that agile practice. The organization cannot change some of the organizational factors or

48

aspectsassessedbytheseindicators,becausetheyexistoutsideoftheorganizations control.Theseoutsidefactorsinfluencethetargetagilelevelforeachproject. For example, frequent facetoface communication is an agile practice at Level 3. Therefore, near team proximity(havingthewholeteaminacloseproximitytoeach other) is a factor needed to successfully adopt this practice. If the project and organization have no say in changing this project characteristic (near team proximity),becauseitisoutsideoftheircontrol,andiftheprojectlevelassessment determinesthatthisfactorisnotachievedforthisprojectandcannotbeachieved, because it is outsidethe organizations control, then the highest level of agility for thisprojectwillbethesameAgileLevelinwhichthisagilepracticeisfound,which isLevel3inthiscase. Forterminologypurposes,organizationalorprojectfactorsthattheorganizationor project team cannot change are called limiting factors and the agile practices or concepts that depend on these factors for a successful adoption are called limiting agile practices.Thename limiting factorwaschosen,becauseeachhasthepotential tolimitthetargetagilelevelforaproject. Since identifying the target agile level, or the highest level a project can aspire to, dependsonlimitingfactors,orfactorsoutsideofanorganizationscontrol,thefirst step is to identify all these limiting factors and any agile practices that depend on themforasuccessfuladoption(limitingagilepractices).

3.4.3 LimitingFactors:OrganizationalPerspective
There are many organizational and project characteristics that are assessed to determinewhethertheorganizationisreadytoadoptanagilepracticeornot.The organization can change some of these factors, but not others. Different organizationshavedifferentfactorsthattheyhavecontroloverandothersthatthey havenocontrolover.Theabilitytochangecharacteristicsdependsonthestructure

49

of the organization and its policies and procedures. Therefore, since the limiting factorsvaryfromorganizationtoorganization,thesefactorsexemplifyafewofthe morecommonpossibilities: TheCustomer Ifanorganizationcanchangeanyofthesefactors,then,bydefinition,theynolonger qualifyaslimitingfactors.Thatsaid,theorganizationusuallyhaslittleornocontrol over customerrelated factors and, therefore, cannot expect to change them. Team proximity, however, is another matter. While it is something an organization can control, sometimes an organization fails to consider this factor when allocating a certain team for the project and finds itself hamstrung, because this allocation cannot be changed. For example, consider the situation where five of the 12 memberteamarehalfwayacrossthecountryortheglobe,andthereisnothingthat theprojectororganizationcando(practically)tochangethissituation.However,if theorganizationcanchangetheteammembersproximity,thenbydefinitionteam proximityisnolongeralimitingfactor.Thesamelogicappliestoteamcompetency. Iftheteamallocatedforacertainprojectcontainsnoexperiencedpeople,andthisis afactortheorganizationcannotchange,thenteamcompetencyisalimitingfactor. Therefore, at the start of each project or when working with an organization, it is importanttoknowexactlywhichaspectsorfactorstheorganizationcanchangeand whichitcannotchange.Thisknowledgegivesthepersonleadingtheefforttoadopt agility a clear perspective of what to expect. Stage 2 does this, but in a structured andmoredetailedmanner. Teamproximity Teamcompetency

50

3.4.4 LimitingFactors:PracticePerspective
Once the person leading the adoption effort has identified the limiting factors, the next step is to identify any agile practices that depend on any of these limiting factorsforasuccessfuladoption.TheReadinessAssessmentTable(RAT)(explained indetailinSection 4.5.2)associatedwitheachagilepracticeprovidesguidancefor this step. These RATs identify each organizational characteristic that needs to be assessed.IfanyofthelimitingfactorsarefoundintheRATofanyagilepractice,that agile practice is identified as a Limiting Agile Practice. Based on the examples of limiting factors identified earlier in the Agile Adoption Framework, the limiting practicesare: Customerdependent: Frequentfacetofaceinteractionbetweendevelopersandusers Immediatecustomeraccessibility Collaborationcommitmentincustomercontract Evolutionarydevelopmentreflectedincustomercontract Customercommitmenttoworkwithdevelopingteam Frequentfacetofacecommunication Idealagilephysicalsetup 30%ofCockburnsLevel2(experienced)andCockburnsLevel3(highly experiencedpeople Table 7 shows the position of all the potential limiting agile practices within the SAMI.Itisimportanttonotethatthelimitingagilepracticesidentifiedinthissection canvarydependingontwothings: 1. thelimitingfactorsidentifiedintheprevioussubsection 2. thesetofreadinessindicatorsassociatedwitheachagilepractice. 51 No/minimal number of Cockburn Level 1 (no experience) or Cockburn Level1b(someexperience)peopleonteam

Teamproximitydependent: -

Teamcompetencedependent: -

Agile Principles Embrace Change to Deliver Customer Value Level 5 Encompassing Establishing a vibrant environment to sustain agility Low process ceremony Plan and Deliver Software Frequently Agile project estimation Human-centric Ideal agile physical setup Technical Excellence Test driven development Paired programming No/minimal number of level -1 or 1b people on team Client driven iterations Continuous customer satisfaction feedback Smaller and more frequent releases (4-8 weeks) Adaptive planning User stories Daily progress tracking meetings Agile documentation Customer contract revolves around commitment of collaboration Customer immediately accessible Customer Collaboration Frequent face-toface interaction between developers & users (collocated)

Level 4 Adaptive Responding to change through multiple levels of feedback

Level 3: Effective Developing high quality, working software in an efficient an effective manner

Risk driven iterations Plan features not tasks. Maintain a list of all features and their status (backlog)

Self organizing teams

Continuous integration Continuous improvement (refactoring) Unit tests 30% of level 2 and level 3 people

Frequent face-to-face communication

Level 2: Evolutionary Delivering software early and continuously

Evolutionary requirements

Continuous delivery Planning at different levels

Software configuration management Tracking iteration progress No big design up front (BDUF)

Customer contract reflective of evolutionary development

Level 1: Collaborative Enhancing communication and collaboration

Reflect and tune process

Collaborative planning

Collaborative teams Empowered and motivated teams

Coding standards

Knowledge sharing tools Task volunteering

Customer commitment to work with developing team

Table7.TheSAMIwithLimitedAgilePracticesUnderlined

Forexample,ifanorganizationcanchangeteamcompetency,thenallthepractices thatdependedonthisfactornolongerbecomelimitingagilepractices.Moreover,if, forexample,newreadinessindicatorsthatassessedtheteamproximityfactorwere addedforselforganizingteams(anagilepracticeinLevel3oftheSAMI),thenself organizingteamsbecomealimitingagilepractice.

52

 Withtheidentificationofpotentiallylimitingagilepractices,theassessorisreadyto begintheprojectassessmentneededtoidentifythehighestlevelofagilityaproject canreach(i.e.thetargetagilelevel).Thisprocessmeasuresonlytheextenttowhich thefactorsneededforthelimitingagilepracticesarepresent.Theassessorconducts the assessment using the indicators associated with each agile practice. Since indicators are an essential component of the SAMI, Chapter 4 describes in detail howtouseindicatorstoconductassessments. The assessor starts the process by assessing the organizations readiness for adopting only the limiting agile practices of the first agile level. If the result is positiveandshowsthattheorganizationisreadytoadoptthosepracticesthenthe assessmentprocessmovesupwardonthescale.Theassessordoesthesameforthe limiting practices identified in Agile Level 2 and so on. As long as the assessment results show that the organization can adopt the limiting practice, the assessment keepsmovingtohigherlevels.Oncethefactorsneededfortheadoptionofalimiting practice are absent, then the assessment process stops, and the highest level of agilityfortheprojectisthelevelatwhichthelimitingpracticeisfound. The highest level of agility attainable is the level at which the assessment for the limitingfactorhasfailed,becausethefactorsneededforthe adoptionofalimiting agile practice are absent and the organization cannot do anything to change that. Therefore, the project cannot aspire to a higher level of agility, because it cannot fully adopt all the practices in the current level. If the factors outside the organizationscontrolchange,thentheassessmentprocesscancontinuetoidentify anew,andhigher,targetlevelfortheproject. When factors outside the control of the organization constrain the highest level of agilityforaproject,thefocusfallsonresolvingtheconstrainingfactorsthatprevent all the principles of agility from rising to higher levels of agility. Focusing on eliminating these factors is better and more beneficial than focusing on ways to

53

adopt agile practices in higher levels because this does not resolve the effect the weakestprincipleexertsontheadoptionofagility.

In summary, the target agile level for a project is the point when the assessment processdiscoversthatoneoftheprojectcharacteristicsneededtoadoptalimiting agilepracticeorconceptismissing,andneithertheprojectnororganizationcando anythingtoinfluenceorchangethis.Aftertheassessmenthas identifiedthetarget agile level, the next step in the journey to agility is to conduct an organizational readinessassessmenttodeterminethesetofagilepracticesthat canbeadoptedfor theproject.

3.5. Stage3:OrganizationalReadinessAssessment
Identifyingthetargetlevelforaprojectdoesnotnecessarilymeanthatthatlevelis achievable. Determining the achievable level requires an assessment of the readiness of the organization to adopt each of the agile practices up to, and including,thetargetlevel. During Stage 3, the assessor conducts an organizational assessment to determine theextentofthereadinessoftheorganizationtoadopttheagilepracticescontained in the target agile level. The activities of Stage 3 highlight the areas that need improvement to accommodate the adoption of the agile practices. In other words, theassessorusesthisstagetodevelopasetofrecommendationsforachievingthe targetagilelevelfortheproject. As Figure 11 shows, Stage 3 depends on the projects target level identified from Stage2.Stage3assessesallofthedifferentaspectsoftheorganizationtodetermine whethertheorganizationhasthenecessarycharacteristicstosupportthepractices encompassed in the target agile level. The details of how Stage 3 guides this organizational readiness assessment and the role the SAMI plays follow a brief discussion of the background of this stage and the importance of conducting a readinessassessmentinthenextsection.

54

Customers Management Software Process

TargetAgile Level

Effective Developers

Organizational Culture Physical Environment Tools Project Management

Figure11.Stage3:OrganizationalReadinessAssessment

3.5.1 OrganizationalAssessment:BackgroundInformation
The idea of conducting an assessment before the actual adoption process starts is not new. The first suggestion Boehm and Turner have for organizations trying to adopt agile practices is to incorporate preparation upfront [21]. They urge organizations to spend time and effort to conduct a significant upfront analysis to identify any mismatches between the organization and the set of agile practices it wantstoadopt.Moreover,Ceschietal.pointoutthatoneofthebiggestchallengesto introducing agile methods in an organization is the lack of a detailed preliminary evaluationofthechallengesthatthisintroductionmightcause. 55

Although it is important to know whether the organization is ready to handle the adoption of certain agile practices before it starts adopting them, all too often the adoption efforts overlook this preadoption assessment phase or do not spend enoughtimeandeffortonit.Theresultisthatanorganizationstartstoadoptagile practiceswithoutknowingwhetheritisreadyforthem.Challengesstarttoemerge andhardshipsfollow.Theimmediatesolutioninthiskindofsituationiseithertotry harder to adopt the practice or to abandon that the practice and deem it as an unsuitablepractice.Stage3ofthe4StageProcessoftheAgileAdoptionFramework offers a solution to the readiness problem. As described in the next section, it providestheassessorwithguidelinesforassessingthereadinessoftheorganization for each agile practice in such a way that it identifies, before any adoption effort starts,practicesthataresuitableandunsuitableforthe organization.Moreover,the assessment process highlights the exact reasons when a practice is unsuitable for adoption. Investing time and effort in this type of preadoption assessment of each agile practiceincreasestheprobabilityofsuccessfortheoveralltransitiontoagility[21]. CarryingouttheactivitieswithinStage3significantlyreducestherisksassociated with the agile adoption process. Furthermore, this assessment identifies the exact organizational characteristics that might jeopardize the successful adoption of an agile practice. Finally, all of this happens before the organization initiates the adoptioneffortandbeforetheeffortmightcausedisruption. Knowing where an organization falls short before the adoption process helps it either select a more suitable set of agile practices to adopt or improve the weak organizationalcharacteristicsthatcancausetheadoptionprocesstofail.

56

3.5.2 AccomplishingtheOrganizationalReadinessAssessment
ThemainobjectiveofStage3istodeterminetheextenttowhichtheorganizationis readytoachievetheprojectstargetagilelevel.Todoso,theassessorassesseshow readytheorganizationistoadopteachoftheagilepracticeswithinthetargetagile level,andthelevel(s)belowit.TheSAMIplaysacrucialroleduringtheassessment processofthisstage. UsingtheSAMIforOrganizationReadinessAssessment LikeStage2,Stage3ofthe4StageProcessalsoreliesontheSAMI.However,Stage2 assessedthereadinessofagilepracticesthatdependedonorganizational characteristicsoutsidetheorganizationscontrol.Stage3reliesontheothersetof agilepracticeswithinSAMI,thosethatdependonorganizationalcharacteristicsthat theprojectororganizationcanchange.Thisisafundamentaldifferenceintheuseof theSAMIfromStage2toStage3. Table 8 shows the SAMI. During Stage 2, the limiting agile practices (those not underlined) were assessed to determine the highest level of agility for a project. DuringStage3,theorganizationsreadinessfortherestoftheagilepracticesorthe nonlimitingAgilepractices(thoseunderlined)isassessed. The indicators associated with each agile practice in the SAMI are instrumental in theassessment.Theyareusedtodeterminetheextenttowhichtheorganizationis ready to adopt each individual agile practice. The indicators associated with each agile practice are concerned with assessing all the organizational characteristics thatcouldinfluencetheextenttowhichtheorganizationisreadytoadopttheagile practice. The type of organizational or project characteristics usually assessed to determinethereadinessforapracticeare: Customers:theprojectscustomersandclients Developers:thetechnicalstaffinvolvedwiththedevelopmentoftheproject

57

Managers: the managers or executives overseeing the project and involved withdecisionmaking Tools:thesoftwaretoolsusedwithintheorganizationorforacertainproject Culture: the overall culture of the people within an organization or the projectteam
Agile Principles Embrace Change to Deliver Customer Value Plan and Deliver Software Frequently Agile project estimation Human-centric Ideal agile physical setup Technical Excellence Test driven development Paired programming No/minimal number of level -1 or 1b people on team Client driven iterations Continuous customer satisfaction feedback Smaller and more frequent releases (4-8 weeks) Adaptive planning User stories Daily progress tracking meetings Agile documentation Customer contract revolves around commitment of collaboration Customer immediately accessible Customer Collaboration Frequent face-toface interaction between developers & users (collocated)

Level 5 Encompassing Establishing a vibrant environment to sustain agility

Low process ceremony

Level 4 Adaptive Responding to change through multiple levels of feedback

Level 3: Effective Developing high quality, working software in an efficient an effective manner

Risk driven iterations Plan features not tasks. Maintain a list of all features and their status (backlog)

Self organizing teams

Continuous integration Continuous improvement (refactoring) Unit tests 30% of level 2 and level 3 people

Frequent face-to-face communication

Level 2: Evolutionary Delivering software early and continuously

Evolutionary requirements

Continuous delivery Planning at different levels

Software configuration management Tracking iteration progress No big design up front (BDUF)

Customer contract reflective of evolutionary development

Level 1: Collaborative Enhancing communication and collaboration

Reflect and tune process

Collaborative planning

Collaborative teams Empowered and motivated teams

Coding standards

Knowledge sharing tools Task volunteering

Customer commitment to work with developing team

Table8.TheSAMIwithNonLimitedAgilePracticesunderlined

58

Project management: the procedures and practices related to managing projectsintheorganization Software process: the activities and artifacts related to the software developmentprocessintheorganization Physical environment: the physical layout of the organization and the geographicalandgeospatialdistributionofitsemployees.

Figure12,illustratesalltheorganizationalcharacteristicsthatneedtobeassessed for each of the agile practices in Agile Level 1. Notice that the practice Customer commitmenttoworkwithdevelopmentteamisnotpartofthefigure,despitethefact thatitisoneofthepracticesinlevel1.ThisisagainbecauseStage3dealsonlywith theagilepracticesthatarenotlimiting.
Management Style (M=7,D=4) Managers Buy-in (M=2) Management Transparency (M=4) Power Distance (M=1,D=4) Developers Buy-in (D=1) Planning Activity Exists (M=2,A=1) Managements Buy-in (M=2) Developers Buy-in (D=1) Interaction between developers (M=1,D=1) Belief in Collectivism (D=1) Developers Buy-in (D=4) Empowerment of Developers (M=2,D=3) Motivation of Developers (D=6) Managers Trust to Developers (M=4,D=1) Developers Buy-in (D=2) Existence of Coding Standards (A=1) Developers Buy-in (M=1,D=2) Managers Buy-in (M=5) Availability of Knowledge Sharing Tools (A=1) Developers Buy-in (D=1) Managers Buy-in (M=1) Ability to change and improve process (M=3,D=3)

Collaborative Planning

Task Volunteering not Task Assignment Collaborative Teams

Empowered and Motivated Teams Coding Standards Knowledge Sharing

Reflect and Tune Process

Figure12.OrganizationalCharacteristicsAssessedforAgilePracticesinLevel1

59

 Thefundamentaldifferencebetweenlimitingandnonlimitingagilepracticesisthe issue of whether the organization has control over changing the characteristics needed for the adoption of that agile practice. With limiting agile practices, the organizationdoesnothavetheabilitytochangethesecharacteristicsand,therefore, they limit the highest level of agility the project can reach. However, with non limitingpractices,theorganization canchangethem.Therefore,thefocusbecomes determining if the current state of these characteristics can support adopting the agile practice or not. Since they are nonlimiting, if the assessment results show thesecharacteristicsarenotinastatetosupporttheadoptionofanagilepractice, the organization can strengthen and change these organizational characteristics untiltheyarereadytoaccommodatetheagilepractice. AssessingtheOrganizationsReadiness Givenanidentifiedproject,thefirststepistodeterminethesetofagilepracticesor CandidatePracticestheorganizationaspirestoadopt.Tosavetimeandcostduring thisassessmentstage,insteadofassessinghowreadytheorganizationistoadoptall the agile practices in the SAMI, the set of candidate practices consist of only the practices within the target agile level of the project and the levels below that. For example, if the target agile level for a project is Agile Level 3, then the set of candidatepracticescomprisesallthepracticesinAgileLevels1,2and3.Theseare candidatepractices,becausetheyarethepracticesthattheproject wantstoadopt, but is waiting for the results of the organizational readiness assessment to determine which ones the project can actually adopt. Once the assessor has identifiedthecandidatepractices,heorsheusestheindicatorsassociatedwitheach agilepractice(seeChapter4)todeterminetheextenttowhichtheorganizationis readytoadoptthatpractice.Figure12showstheorganizationalcharacteristicsthat theassessorneedsinordertoassesstheagilepracticesinLevel1.Theassessoruses multipleindicatorstoassesseachoftheseorganizationalcharacteristics.Theresults foreachofthesecharacteristicsareaggregatedtogetherusinganapproachinspired

60

bytheEvaluationEnvironment[10]andareplottedinatablesimilartotheonein Figure13. Figure 13 shows the table resulting from the organizational assessment stage that depictstheachievedlevelofeachorganizationalcharacteristic.Thehighestlevelof aggregation for the indicators is that of the organizational characteristic. If the results were aggregated up to the level of the agile practice, the results would be useless. Knowing that an organization is partly ready for an agile practice is not beneficial. However, keeping the level of aggregation at the characteristic level is beneficial to executives and decision makers, because it draws attention to the characteristicsoftheorganizationthatmightcausetheadoptionofapracticetofail.

Figure13.OrganizationalReadinessAssessmentResults

As in the project level assessment, determining the highest agile level an organizationiscapableofachievingisdependentontheorganizationsreadinessto adoptthepracticesinthatagilelevel.Iftheorganizationalcharacteristicsneededfor a practice are found to be not achieved or only partially achieved, this finding indicates that the organization is not ready to adopt that practice. As a result, the highest level of agility the organization can reach becomes the level at which a 61

necessaryorganizationalcharacteristicismissing.Forexample,asFigure13shows, since collaborative planningisinAgileLevel1,andsincetwoofthecharacteristics thatitneedsaredeficient(managementstyleis partially achievedandmanagement buyinisnotachieved),thehighestlevelofagilityforthatorganizationisLevel1.

Stage3endsoncetheresultsoftheorganizationalreadinessassessmentareplotted. Stage4providesguidelinesforanalyzingtheresultsanddevelopinganactionplan basedontheseresults.

3.6. Stage4:Reconciliation
Followingtheorganizationalreadinessassessment,theagilelevelachievablebythe organizationisknown.Priorto that,Stage2hadidentifiedtheagilelevelthatthe project aspires to adopt. Therefore, the final step, reconciliation, is necessary to determinetheagilepracticestheprojectfinallyadopts.Inessence,duringthisstage theassessoranalyzestheresultsoftheorganizationalassessmentandmakesaset of recommendations to the organization on how to proceed, especially if the organizationsreadinesslevelislessthantheprojecttargetlevel. Figure14illustratestheactivitiesofthisstage.Asimplegapanalysisexaminesthe differencebetweentheorganizationalreadinesslevelandtheprojecttargetlevel.If thereisnogap,meaningthattheorganizationisreadytoachievetheprojectstarget agilelevel,thentheorganizationhassuccessfullyidentifiedthesetofagilepractices toadopt.Howeverifthereisagapbetweentheorganizations readinessleveland theprojectstargetlevel,thenreconciliationisneeded.Asexplainedindetaillater, the reconciliation phase will either recommend the strengthening of weak organizational elements or to adopt those practices the organization is ready for, even though the project wont be operating at its full agile potential. During Stage 4 the differences between the projects target agile level and the organizations readiness level are resolved to determine the final set of agile

62

practices to be adopted/employed. Three different scenarios are possible during thisstage: Organization Readiness Level is higher than the Project Target Level:Thiscaseis depicted conceptually in Figure 15. No reconciliation is needed and all the practices within the projects agile level and below become the chosen agile practices for adoption. This scenario rarely occurs, because the project environmentisusuallycontainedwithintheorganization.
Introduce or strengthen the missing or weak organizational characteristics
Customers Management

Yes

Software Process Developers

Gap Analysis

Gap

Is the Organization able to change

Organizational Culture Physical Environment Tools

No Gap

No
Choose only the agile practices the organization is ready for

Project Management

Recommended set of agile practices for adoption

Figure14.Stage4:Reconciliation

63

Level 5 Level 4 Level 3 Level 2 Level 1 Project Organization

Figure15.Reconciliation(Organization>Project)

Organization Readiness Level = Project Target Level: This case is depicted conceptually in Figure 16. No reconciliation is needed and all the practices withintheprojectsagilelevelandbelowbecometheagilepracticeschosenfor adoption.Thisistheidealcase,becausetheprojectisachieving100%ofitsagile potential.

Level 5 Level 4 Level 3 Level 2 Level 1 Project Organization

Figure16.Reconciliation(Organization=Project)

Organization Readiness Level < Project Target Level: As depicted in Figure 17, reconciliation is necessary. Stage 4 provides two options for reconciling this situation.Eachoptionispresentedbelow.

64

Level 5 Level 4 Level 3 Level 2 Level 1 Organization Project GAP

Figure17.ReconciliationStage(Organization<Project)

Option 1: Change the Organization

Thefirstoptionreliesonhowreadyandwillingtheorganizationisforchangesand improvements. The results of the organizational assessment have identified the exact characteristics hindering the organization from reaching higher levels of agility (i.e. the projects target level). If changing any of these characteristics is within the control of the organization, then the organization can undertake the necessarystepstoimprovethesecharacteristics. While the Agile Adoption Framework does not include a list of best practices for improvingorstrengtheningtheorganizationalcharacteristicsfoundtobeweak,the framework provides enough guidance for the organization to find resources to improve these weaknesses. For example, Figure 18 shows that management style and Buyin are the two factors keeping the organization from being able to adopt CollaborativePlanning.Althoughhowtofixthesechallengesisnotwithinthescope of the framework, a simple Internet search provides many resources to improve these characteristics [65] [47] [80] [86]. Changing some of these organizational characteristics might be as simple as buying a software tool or as difficult as orchestratingacompleteculturalchange.Readingbooksandapplyingsomeofthe 65

principles mentioned in them is one way to strengthen these organizational characteristics. In other cases, such as the one Figure 18 indicates, the managers might have to go through some kind of training to change their mindset and promoteaculturalchangewithintheorganization.Everyorganizationmustfindits own approach to overcoming the weakness identified from the organizational assessment.

Figure18.PartoftheOrganizationalReadinessAssessmentresults

WhileStage4doesnotofferaspecificactionplanforfixingtheproblemsidentified, it provides the organization with a certain level of guidance on what needs to be done and in what order. The framework suggests that the order of the changes shouldfollowtheroadmapprovidedbytheSAMI.Inotherwords,theorganization shouldtrytofixallthechallengespertainingtotheagilepracticesinlevel1beforeit movestothechallengesrelatedtothepracticesinlevel2andsoon.Itisbecauseof thisstagethatSection2.3mentionedthatthe4Stageprocessalsoaddressessome of the objectives of the Establishing phase in IDEAL. This is because this stage providestheorganizationwithsuggestionsconcerningtheprioritybywhichchange recommendationsshouldbeimplemented. Whenanorganizationhasmadealltherecommendedchanges,itcansupportagile practicesat the projects target level. However, if the organization is not readyfor change,thenthesecondoptionisputintoaction.

66

Option2:LowerExpectations
The second option is suitable for organizations unwilling to invest time, effort or moneytomakechanges,orareunabletochangesomeoftheweaknessesidentified from the organization assessment. By lowering their expectation, these organizationscanopttoadoptonlytheagilepracticesthatarewithintheircurrent capacity.Thepriorityofsuchanorganizationshouldbetofocusonadoptingallthe practices it canthatare within the same agile level. The reasonforthis is thatthe practices in the same agile level are grouped together to create a certain synergy whenadoptedtogether.Therefore,theorganizationneedstotakeadvantageofthis synergy and try to completely adopt the practices in one level before going to the next. The obvious downside to this option for reconciliation is that the project is restrictedtooperatingatalowerlevelofagilitythanitspotential. This reconciliation stage helps the organization identify the agile practices it can realistically adopt. At the same time, if the organization is able and willing to improve, then this stage guides it to where the improvements need to occur to enable the project operates at its full agile potential. Moreover, by utilizing this approach,theorganizationpreparesitselfsufficientlybeforestartingtheprocessof introducing agile practices into the development process, thereby decreasing the impactoftheadoptionprocess. Thefinalproductofthe4StageProcessisasetofrecommendedagilepracticesthat are suitable for the organization to adopt. How the actual adoption is achieved is outsidethescopeofthisresearch.Foreachagilepracticetheorganizationisready to adopt, either a specialized consultant is hired to introduce a particular agile practicetotheprojectortheprojectteamcanjustreadaspecializedbookaboutthe agile practice they plan to adopt. Most of the agile practices have one or more dedicatedbooksthatexplainthemindetail.

67

The main contribution of the 4Stage Process along with the SAMI is to provide organizations with guidance on how to start the agileadoption process andwhich agile practices they should adopt. Moreover, the framework provides detailed recommendations on what the organization needs to improve on to successfully adoptitsdesiredagilepractices. It is evident from this chapter that the 4Stage Process component of the Agile AdoptionFrameworkreliesheavilyontheSidkyAgileMeasurementIndex(SAMI). The next chapter presents, in detail, the structure of the SAMI and how it is structured.

68

4. TheSidkyAgileMeasurementIndex
Chapter3highlightsthe4StageProcess,themaincomponentoftheAgileAdoption Framework. The first stage of this Process helps determine whether organizations arereadytoundergoagileadoptionefforts.Thesecondandthirdstagesprovidea meansforprojectsandorganizationstoassesstheiragilepotentialusingtheSidky AgileMeasurementIndex(SAMI).Thelaststage,Stage4,suggestsafinalsetofAgile Practices for organizations to adopt by reconciling any differences between the Agile Levels identified in Stage 2 and Stage 3. The SAMI is instrumental in identifying the highest level of agility a project can reach (the goal of Stage 2), identifyingthelevelofagilitytheorganizationisreadytoadopt(thegoalofStage3), and reconciling any existing differences (the goal of Stage 4). This chapter is dedicatedtopresentingthedetailsoftheSAMI. This chapter begins with Section 4.1, which discusses background information about measurement indices both in general and as related to agility. Each of the subsequent 4 sections presents a different component of the SAMI. Section 4.2 discussesthenotionofAgileLevelsindetail,includingtheprocessoftheircreation and varying levels of significance. Section 4.3 presents the role of Agile Principles and their importance in the measurement index. In Section 4.4, a comprehensive exampledescribeshoweachAgileLevelispopulatedwithAgile Practiceswiththe help of Agile Principles. Section 4.4 also includes the taxonomy and description of each of the Agile Practices. The fourth component of the SAMI, the Indicators, is presentedinSection4.5.Thefinalsectionofthischapter,Section4.6,discussesthe tailorabilityoftheSAMI.

4.1 BackgroundInformationaboutMeasurementIndices
Before developing a measurement index capable of measuring agile potential relative to the core values (objectives) of agility, it was necessary to find out

69

whether an adequate one already existed. We started first by looking at popular measurement indices in Software Engineering to decide whether or not it was adequate. ThefirstcandidatewastheCMMI,awelldefinedandwidelyacceptedmeasurement indexforsoftwaredevelopmentprocesses.WhileanalyzingtheCMMIandtheKey Process Areas (KPAs) it assesses to determine its capability, it became apparent thatCMMIwasnotsuitableformeasuringtheagilityofaprocess.CMMIisdesigned tomeasureprocessmaturityandcapability,notagility.Whileitisimpossibletouse CMMI to assess agility, it is possible to use a number of its structural aspects to design an agile measurement index. These aspects are highlighted later in further detail. Whilethereisnoagilemeasurementindexabletodeterminetheagilepotentialofa project,therehavebeenotherattemptstocreatesocalledmeasurementindexesfor agility. However, most of what is published on the subject of agile measurement takestheapproachofdeterminingasuitable process methodologyforaspecifictype of project rather than finding the right degree of process agility for a project. The approaches involved with determining suitable process methodologies look at the whole planning spectrum (see Figure 19) and attempt to identify, in a non pragmaticmanner,whichagileprocessmethodologyismostsuitableforthegiven project.
Milestone Risk- Driven Models

Hackers

XP

Adaptive Sw Devel.

Milestone Plan-Driven Models

Inch- Pebble Ironbound Contract

Agile Methods

Figure19.PlanningSpectrum[19]

70

InhisbookBalancingAgilityandDiscipline[22]BarryBoehmarguesfortheuseofa riskdriven approach for determining the right level of planning necessary for a project.Hemakesuseofdifferenttypesofrisks(e.g.environmentrisks,agilityrisk, and plandriven risks), coupled with different project characteristics (criticality, personnel, rate of changefor the requirements, team size and culture). With these hetellshowtofindthesweetspot,orthemostsuitablelevelofprocessdefinition for the organization. Boehms research, however, fails to translate this sweet spot into actual Agile Practices. Consequently, once the right balance of agility and discipline is defined, it must be established: what the right balance means for an organization,whatthisbalanceshoulddo,andwhichAgilePracticesareequaltothe operational level of agility. While Boehms research on how to balance agility and disciplineisinformative,well documented,andvalidated,itlacksguidelinesforan organization adopting agility on which steps and practices are necessary to reach theidentifiedlevelofagility. Otherwork,bearinganamesimilartotheSAMI,istheAgility MeasurementIndex (AMI) [33]. The AMI also serves as a heuristic approach for deciding which methodology is best for a given project. The AMI defines five dimensions of a project that, when calculated, define the Agility Measurement Index of a project. ThesefivedimensionsareDuration,Risk,Novelty,EffortandInteraction. TheproblemwithBoehmsresearch,theAMIandsimilarapproachesisthattheyfail toidentifytheagilepotentialofaproject.Instead,theyrecognizetheexistenceofa planningspectrum(differentlevelsofplanning)andtrytofindtheidealdegreeof process planning for a project. Moreover, in some cases (e.g. mission and life critical systems) these approaches might suggest a nonagile process as the ideal process for the development of these systems. This is a point that is difficult to acceptbecauseeveryproject,evenmissionandlifecriticalsystems,canadoptsome levelofagility[78].

71

Another observation about the planning spectrum is the way the spectrum is structured.Ifthisspectrumisthoughtofasameasurementindexforhowagilea processis,itbecomesevidentthattheunitsofthismeasurementindexareactually software development methodologies. For example, Figure 19 shows that XP is a unit on this measurement index and Adaptive Software Development (ASD) is another unit on the other side of the agile spectrum. Having specific agile methodologies as units of the measurement index, and using this measurement indexresultsinprocessesbeingmeasuredaccordingtotheir adherence leveltothat specific agile methodology. An agile measurement index must use agile values(i.e. objectives of agility) as units, not specific agile methods. The CMMI is based on valuesandKeyProcessAreas,notonspecificsoftwaredevelopmentmethodologies. TheWaterfalldevelopmentmodelisnotCMMILevel1andtheSpiralmodelisnot CMMI Level 2. The levels of CMMI (i.e. the units of measurement for CMMI) are independent of any particular development model or methodology. However, for some reason when it comes to agility some of the measurement approaches use specificagilemethodsastheunits. Althoughthebestexistingapproaches,highlightedabove,offerusefulcontributions todevelopinganagilemeasurementindex,noneofthemaresuitableforidentifying the agile potential of a project and assessing the readiness of an organization for agility.Therefore,afterthesearchforasuitableagilemeasurementindexfailed,the need to create a new one became evident. The next section discusses in detail the firstcomponentoftheSidkyAgileMeasurementIndex(SAMI)AgileLevels.

4.2 AgileLevels
Since the objective is to create a measurement index to measure organizations adoptingagility,afundamentalquestionneedstobeansweredbeforedetermining howtomeasureagilepotential;howdoesanorganizationmovetowardsandadopt agility.Aftermuchthought,theanswerisobvious;organizationsbecomemoreagile

72

when they adopt more Agile Practices. As a result, in very general terms and on a verymacrolevel,themoreAgilePracticesanorganizationadopts,themoreagileit is.Anorganizationthathasadopted10AgilePracticesismostprobablymoreagile thananorganizationthatusesfewerornoneatall.Thisfundamentalconcepthelps answer the critical question of how to measure agile potential by the number of AgilePracticessoftwaredevelopmentprocesscanadopt.Asaresult,theSidkyAgile Measurement Index (SAMI) is designed to measure the agile potential of an organizationusingthenotionofAgilePractices. Onceitisdeterminedhowtomeasuretheagilepotential,thenextcrucialquestion relatingtotheSAMIiswhatunitsthismeasurementindexwillusetomeasureagile potential.AtemptinglysimplesolutionistocountthenumberofAgilePracticesan organizationcanadoptandmakethesumitsagilepotentialscore.However,this approach is too simplistic and inaccurate. For example, it is inaccurate to say an organization able to adopt five Agile Practices has more agile potential than an organization that can adopt four practices, because many other factors must be considered,includingthetypeofpracticesemployedandtheimpactofeachpractice ontheorganizationsagility.Thelatterisespeciallyimportant,becausenotallAgile Practiceshavethesamelevelofimpactonanorganizationsagility WhenasimplecountofAgilePracticesprovesinadequate,thesearchforasolution continues with looking at other process improvement measurement indexes for inspiration.TheCMMIandotherprocessimprovementstandardsandmeasurement indexes,suchastheISO15504(SPICE),used levels asunitsfortheirmeasurement indexes.CMMIhassixdifferentmaturity levelsrangingfrom 0 to 5 and SPICE has sixcapabilitylevels. ThenotionoflevelsinCMMIandSPICEinspiredthedecisiontomaketheunitsfor the SAMI Agile Levels. The next challenge is to define the nature of these levels within the agile measurement index. An explanation of this process follows in the nextsections. 73

 With the agile measurement index measuring the agility of an organization by the useofAgilePracticeswithAgileLevelsasitsunits,itbecomesnecessarytofindthe number of levels needed and how to define each level with respect to Agile Practices.AgaintheCMMIprovideshelp.IntheCMMI,eachmaturitylevelstabilizes an important part of the organizations processes, and each maturity level comprisesapredefinedsetofprocessareas.Everyprocessareaconsistsofacluster of related practices that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. Similarly, each agile level introduces an important agile quality (e.g. collaboration) into the organizationtohelpitbecomemoreagile.EachagilelevelconsistsofasetofAgile Practices that are related and, when adopted collectively, make significant improvements in the software development process, thereby leading to the realizationoftheagilequalityoftherespectiveagilelevel.

4.2.1 IdentifyingtheLevelsofAgility
The next challenge is to define the levels of agility. The Agile Levels must be independentofanyparticularagilemethod,soitisnotsuitabletohaveagilelevel1 beAdaptiveSoftwareDevelopmentandagilelevel2beExtremeProgramming.The levelsmustbebasedonthecorevaluesandqualitiesofagility.Forthisreason,the starting point for defining the Agile Levels of the SAMI is the Agile Manifesto, the original document that highlights the core values and principles of agile software development,whichstates: We are uncovering better ways of developing software by doing it and helpingothersdoit.Throughthisworkwehavecometovalue: Individualsandinteractionsoverprocessesandtools Workingsoftwareandovercomprehensivedocumentation

74

Customercollaborationovercontractnegotiation Respondingtochangeoverfollowingaplan

That is, while there is value in the items on the right (e.g. Individuals and interactions),wevaluetheitemsontheleft(e.g.processesandtools)more. TheoriginaltextoftheAgileManifesto,aswellasthe12principlesdevelopedfrom the manifesto and the review of the body of literature related to agility helped identifyfivevaluesorqualitiesofagility.Theyare: Responding to change through multiple levels of feedback: The whole paradigm shift towards agile pivoted around this goal of responding to change. Agile development ensures that multiple levels of feedback are presenttoenablethenotionofadaptingtochange[45]. Ensuring continuous delivery of software: The value of early and continuous delivery of software is fundamental to agile software development Every agile method is based on the notion of evolutionary development(i.e.smallandcontinuousincrements)[60]. Establishing communication and collaboration: This value is concerned with fostering communication and collaboration between all the different stakeholders.Collaborationisthefoundationofagilesoftwaredevelopment
[80][24][27].

Producing quality software: Agile processes seek to employ engineering practices that foster the development of quality software. In order for an agileprocesstobenimbleandadaptquicklytochange,effectiveengineering practicesmustsupportthetechnicalprocess[51][27].

Providinganallencompassingagileenvironment:Agilityisnotonlyaset ofpractices,butalsoessentiallyaculture.Therefore,itis importanttohave an environment that is reflective and supportive of the agile nature of the softwaredevelopmentprocess.

75

 After identifying these key agile values and qualities, the task of converting them intoAgileLevelsisnext.Oncetheneedforthefivelevelseachrepresentingoneof theagilevaluesbecameevident,thenextstepistonameand sequencethelevels. Table 9 shows the names given to each level and the agile value or quality each represents
AgileLevelName Adaptive Evolutionary Collaborative Effective Encompassing AgileValueorQuality Respondingtochangethroughmultiplelevelsoffeedback: Ensuringcontinuousdeliveryofsoftware Establishingcommunicationandcollaboration Producingqualitysoftware Providinganallencompassingagileenvironment Table9.AgilevaluesrepresentedbyAgileLevels

4.2.2 DeterminingtheOrderoftheLevelsofAgility
Oncenamed,thelevelshavetobecarefullysequencedinamannerthatprovidesa roadmap for those aspiring to move toward agility. This roadmap answers the questionsofwhichagileleveltointroducefirstandwhy. Thesearchforthemostappropriatesequenceforthelevelsinvolvesreviewingthe Agile Manifesto, various agile books and articles, organizational change books and even books about social change and its causes. One book in particular stands out, The Tipping PointbyMalcolmGladwell[42].EventhoughGladwellsbookdiscusses mainlythephenomenaofsocialoutbreaks(whetherpositiveornegative)andhow theyarecaused,italsoprovidesageneralframeworkforthesequencingoftheAgile LevelsintheSAMI.Gladwellexplainshowfashionstartsandspreadsandhowcrime wavesstartanddieoutusingthreemainlawsorfactors.Thefirstlaw,theLawof theFew,highlightstheroleofpeopleinthespreadofsocialchanges.Detailingthe differentkindsofpeopleneededforthesesocialoutbreaks,Gladwelldemonstrates 76

that the first factor is all about people. The second law, the stickiness factor, is concerned with the actual content of the message or of the concept being spread. The last factor, which Gladwell calls the context, is all about the environment. Gladwellshowsthattocompleteasocialchangeoroutbreakitisnecessarytosetup anenvironmentorcontextthatissymbolicofthismessageorconcept. Thisanalysisof TheTippingPointledtoanepiphany.ThefiveAgileLevelsshownin Table9followthesamegenericframework.Thefirstfactorinthisbookfocuseson people and relationships, as does the agile level named collaborative. The last factor,thecontextmatchesperfectlytheagilelevelnamedencompassing,which focusesonestablishinganallencompassingenvironment.Themiddlefactorinthis book, the content of the message or concept, matches the remaining three Agile Levelsthatwererelatedtotheactualnatureoftheagiledevelopmentprocess,orin otherwords,thecontent. TheserealizationssetthebasisforthesequencingoftheAgileLevels.Thefirstlevel (Agile Level 1) focuses on establishing communication and collaboration. The last agile level (Agile Level 5) focuses on providing an allencompassing agile environment. For the rest of the levels it must be determined which agile value shouldbeintroducedfirstintoanorganization.Thiselicitstwomoreconcernstobe determined: which of these values would have the biggest impact on moving an organizationtowardsagility,andiftheagilevaluesdependantuponeachother.The obviousanswertobothisthatAgileLevel2ensuresearlyand continuousdelivery of software. The basis of this decision is that most of the Agile Practices are dependantonthefactthatthedevelopmentisconductedinanevolutionarymanner rather than the big bang approach. As a result, the effective engineering practices cannot be introduced first, because they depend on an evolutionary development process.Moreover,theagilevalueofrespondingtochangepivotsaroundtheuseof evolutionary development. Once this is decided, it was obvious that Agile Level 3, theeffectivelevel,shouldfocusonproducingqualitysoftware.Thereasonforthisis that sound technical practices that enable the process to produce working quality 77

software are a prerequisite to having the ability to respond to change. Before the product can quickly adapt to constant changes, it mustmake surethat no changes will jeopardize the quality of the product. Hence, the effective agile level precedes theadaptivelevel,orLevel4.Table2displaysthesequenceoftheAgileLevelsinthe measurementindex.Thelevelsareshowninreverseordertoreflectthenotionthat agilityincreaseswitheachagilelevelofattainted.
AgileLevel Level5 Level4 Level3 Level2 Level1 LevelName Encompassing Adaptive Effective Evolutionary Collaborative LevelsObjective(AgileValueReworded) Establishingavibrantandallencompassingenvironmentto sustainagility Respondingtochangethroughmultiplelevelsoffeedback Developinghighquality,workingsoftwareinanefficientan effectivemanner Deliveringsoftwareearlyandcontinuously Enhancingcommunicationandcollaboration

Table10.The5AgileLevelsinorder

AgileLevel1:CollaborativeorEvolutionary? AfterorganizingtheAgileLevelsthereissomequestionaboutthefirsttwolevelsin particular. Since the Agile Levels now represent a roadmap for an organization moving towards agility, the levels this suggest the steps this organization should take to move toward agility. The disputed questions arise over whether the first stepshouldbeaboutcommunicationandcollaborationoraboutensuringthereisan evolutionary development process. While this is a legitimate concern, however, ultimatelyitwouldstillyieldahigherimpacttowardsagilityfortheorganizationif themovetoagilitybeganwithcommunicationandcollaboration.

78

Theprimaryreasonforthedecisiontohavecommunicationandcollaborationasthe firstlevelisthefirstsentencefromtheAgileManifestoitself: Individualsandinteractionsoverprocessesandtools If the first step towards agility focused on changing the software development process, and not enhancing communication and collaboration between the individuals,itwouldbecontradictingtheagilemanifestoitself. The CMMI and the traditional process improvement paradigm provide another reason for making communication and collaboration the focus of Level 1. In 1993 Watts Humphrey developed the Personal Software Process (PSP) and its companion the Team Software Process (TSP) [48]. These software development processeswereasetofguidelinesandbestpracticestoincorporatedisciplineinthe software development process. What proves interesting, especially with TSP, is its focus on enhancing communication and collaboration. Success stories have highlighted the contribution that TSP has had on improving the software development efforts of various organizations [20]. Therefore, it is obvious, even withintheCMMIparadigm,thataddingcommunicationandcollaborationpractices wouldenhancetheprocesstremendously. These two reasons, the opening sentence of the Agile Manifesto and the observations from the TSP, lead to the conclusion that enhancing communication andcollaborationshouldbethefirststepforanorganizationsmovetowardagility. In 2006, Alistair Cockburn, one of the original authors of the Agile Manifesto, published the second edition of his book about agile software development, Agile Software Development: The Cooperative Game [25]. The titles wording confirmed AgileLevel1ascollaborative.InChapter3(FirstWho,ThenWhat)ofhisbook Good to Great: Why Some Companies Make the Leap... and Others Don't, Jim Collins also focusesonbuildingpeoplefirst[32].Justasthisliteratureoffersmuchevidencethat collaborationshouldbethefirststepandpriorityofsoftwaredevelopment[27,49, 79

45],thetitleofKertPetersonsarticlein2005Collaboration: The key to Enterprise Agile Adoption [70], provides yet another sign that the focus of Level 1 should be enhancing communication and collaboration. In fact, the literature on agile adoptionunderscoresthenotionthatcollaborationtrulyisthefirststeptosuccess intheagileadoptionprocess. WhenisanorganizationconsideredAgile? Theaboveconclusionbringsupthequestionofhowtodecidewhenanorganization isagile.Forexample,isanorganizationconsideredagileevenifitisonlyatLevel1? What if an organization is still using the waterfall model, and adopts all the Agile PracticesinAgileLevel1,isthisorganizationconsideredagile?Thesequestions are about titles and names, not substance. It adds no fame or glory to call an organizationagilewhenitisnot.Themainpointisthatnoonecandenyenhancing communication and collaboration in an organization is a step towards agility (See Figure20).Theconcernhereiswithmovingorganizationstowardsagility,notwith givingthemcertificatesandrecognitionwhentheybecomeagile.
5

Agile Levels

4 3 2 1

Agile Practices and Concepts

Agility Increases

Figure20.AgileLevels

Since the measurement index uses Agile Practices to measure agility, each of the Agile Levels must consist of a set of different Agile Practices. The next step in the developmentoftheagilemeasurementindexistopopulateeach ofthelevelswith relevant Agile Practices. The role of the second component of the SAMI, the Agile Principles, is to provide organizations with guidance on how to properly populate

80

each agile level with the right set of Agile Practices. The adherence to Agile Principles ensures that each the software development process is agile. The next section discusses what Agile Principles are, and how they are used to develop the SAMI.

4.3 AgilePrinciples
Agile principles are the essential characteristics that need to be embodied in a processbeforeitisconsideredagile.WhenwritingtheAgileManifesto,theauthors identified12principlesforagilesoftwaredevelopment[2]. 1. Ourhighestpriorityistosatisfythecustomerthroughearlyandcontinuous deliveryofvaluablesoftware. 2. Welcomechangingrequirements,evenlateindevelopment.Agile processes harnesschangeforthecustomer'scompetitiveadvantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months,withapreferencetotheshortertimescale. 4. Business people and developers must work together daily throughout the project. 5. Buildprojectsaroundmotivatedindividuals.Givethemtheenvironmentand supporttheyneed,andtrustthemtogetthejobdone. 6. The most efficient and effective method of conveying information to and withinadevelopmentteamisfacetofaceconversation. 7. Workingsoftwareistheprimarymeasureofprogress. 8. Agile processes promote sustainable development. The sponsors, developers,andusersshouldbeabletomaintainaconstantpaceindefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicitytheartofmaximizingtheamountofworknotdoneisessential.

81

11. The best architectures, requirements, and designs emerge from self organizingteams. 12. Atregularintervals,theteamreflectsonhowtobecomemoreeffective,then tunesandadjustsitsbehavioraccordingly. In terms of the development of the SAMI, knowing the principles of agility is important because they play a key role in populating the Agile Levels with Agile Practices.

4.3.1 TheRelationbetweenAgileLevelsandAgilePrinciples
An analogy that helps illustrate the relation between Agile Principles and Agile LevelstakesitsinspirationfromWakesSlicingthecakeanalogyusedfordividing userstories[82].Thinkofadevelopmentprocessthatisfullyagileasamultilayer cake,whereeachlayerofthecakeisanagileprinciple,therebymakingthis12layer cake,andthatAgileLevelsareslicesofthecake.Tomakesurethateachsliceofthe cake(AgileLevel)exemplifiestheessenceofthewholecake(agility),allthelayers ofthecake(AgilePrinciples)shouldbepresentineachslice. ThesameconceptholdstruefortheSAMI.ToensurethattheAgileLevelsembody theessentialcharacteristicsofagility,eachleveliscreatedbyadheringtoasmany,if not all, of the Agile Principles. The makeup of each agile level, in terms of Agile Practices,isguidedbythelevelsscopeofadherencetotheseAgilePrinciples.Each agileleveladherestotheAgilePrinciplesfordifferentpurposes,dependingonthe agilevaluethelevelisintroducingintotheprocess. ThereasoneachagilelevelneedstoexemplifyalloftheAgilePrinciplesistoensure thatwhenanorganizationadoptstheAgilePracticeswithinanygivenagilelevelitis not only adopting one aspect of agility (one layer of the cake). If it were to adopt only one aspect of agility the software development process after the adoption of

82

thatagilelevelwillnotexhibitanagilebehavior.Moreover,ifeachagilelevelwere tofocusononlyoneortwoAgilePrinciples,thentheroadmaptoagilityisnotagile inandofitself,becauseitwouldbefollowingawaterfallapproachwherethewhole product(agilityoranagileprocess)wouldonlycomeintoexistenceattheendofthe wholeprocess.Agilepromotesitselfusingthefactthataftereachiterationthereisa potentially shippable product, which means that at each iteration the product consistsofallofitslevelsanddoesnotwaittocometogetheronlyattheendofthe developmentprocess.

4.3.2 Identifyingthe5AgilePrinciplesusedintheSAMI
The12AgilePrinciplesareusedasguidelinesforpopulatingtheAgileLevelswith Agile Practices. However, if all of the 12 Agile Principles are used to define each agile level, unnecessary complications will be introduced. Careful grouping and summarizationmakeitpossibletoidentifythefiveAgilePrinciplesthatcapturethe essenceofall12principles.ThesefiveAgilePrinciplesguidethedevelopmentofthe 5LevelsofAgility: Embrace change to deliver customer value [17]. The success of a software development effort is based on the extent to which it helps deliver customer value. In many cases, the development team, as well as the customer, are in a continuous learning process as to the requirements necessary to realize additional customer value. Hence, an attitude of welcoming and embracing changeshouldbemaintainedthroughoutthesoftwaredevelopmenteffort. Plan and deliver software frequently [18][29][72].Earlyandfrequentdelivery of working software is crucial, because it provides the customer with a functionalpieceoftheproducttoreviewandprovidefeedbackon.Thisfeedback isessentialfortheprocessofplanningforupcomingiterations,asitshapesthe scopeanddirectionofthesoftwaredevelopmenteffort. Humancentric[24].Therelianceonpeopleandtheinteractionsamongthemisa cornerstoneinthedefinitionofagilesoftwareprocesses. 83

Technicalexcellence[45][57].Agiledevelopersarecommittedtoproducingonly thehighestqualitycodepossible,becausehighqualitycodeisessentialinhigh speeddevelopmentenvironments,suchastheonescharacterizedasagile.

Customer collaboration [18]. Inspired by the original statement of the agile manifesto, there must be significant and frequent interaction between the customers,developers,andallthestakeholdersoftheprojecttoensurethatthe productbeingdevelopedsatisfiesthebusinessneedsofthecustomer.

In effect, Agile Principles are used to ensure that each Agile Level embodies essential characteristics of agility. Figure 21 illustrates the relationship between AgileLevelsandAgilePrinciples. EachagilelevelshouldcontainAgilePracticesassociatedwithmost,ifnotall,ofthe Agile Principles. The principle reflects the approach that the agile practice uses to promote the agile quality pertinent to a level. For example, since adopting the practices within agile Level 1 renders a collaborative process. By adhering to the technical excellence principle during the creation of that level, Agile Practices and conceptsthatarerelatedtotechnicalexcellencebecomepartofthesetofpractices that makeup the level. Therefore, even when the agile level is focused on collaboration, it will still contain practices that exhibit technical excellence, and at thesametime,promotecollaboration.AsforAgileLevel3,it willcontainpractices thatexhibittechnicalexcellencebutpromoteitsagilevalueeffectiveness.

84

Agile Principles
A 5 B C D E

Agile Levels

4 3 2 1

Agile Practices and Concepts

Agility Increases

Figure21.LayoutofAgileLevelsandPrincipleswithinSAMI

Atthispoint,theagilemeasurementindexhastwodimensions,theAgileLevelsand theAgilePrinciples.However,themeasurementindexisempty,asFigure22shows, andcannotbeusedyet.Tocompletetherenditionoftheagile measurementindex, theAgileLevels,byadheringtothesefiveAgilePrinciples,arepopulatedwithAgile Practices and concepts. The next section provides an explanation of how the agile measurementindexispopulatedwiththeAgilePracticesandconcepts.
Agile Principles Delivering Customer Value by Embracing Change Level 5: Encompassing Level 4: Adaptive Level 3: Effective Level 2: Evolutionary Level 1: Collaborative Planning to Deliver Software Frequently Humancentric Technical Excellence Customer Collaboration

Figure22.EmptyMatrixofthe5AgileLevelsand5AgilePrinciples

85

4.4 AgilePractices
The previous two sections explain Agile Levels and Agile Principles and the relationshipbetweenthem.AgileLevelsarethebasicmeasurementunitoftheSAMI and are used to assess the agile potential of a project or organization. Each Agile Level iscomposed ofasynergisticsetofAgile Practices that, when adopted, cause thesoftwaredevelopmentprocesstorealizeanewvalueorqualityofagility.Agile PrinciplesguidetheprocessofpopulatingeachAgileLevelwiththeappropriateset ofAgilePractices.AgilePracticesaretheconcreteactivitiesandpracticaltechniques usedtodevelopandmanagesoftwareprojectsinamannerconsistentwiththeAgile Principles. At the same time, each Agile Practice is categorized under the Agile Principle that it manifests. Examples of popular Agile Practices include paired programming,userstories,andcollaborativeplanning. Industry uses many of the currently known Agile Practices even as new Agile Practices are being developed. Some Agile Practices are borrowed from other disciplinesandsomearecreatedtomeetthespecialdevelopmentneedsoftheagile community. In either case, Agile Practices either replace nonagile practices or redefine or complement them. For example, user stores are promoted as a replacement for the traditional requirements specification document and Test Driven Development (TDD) complements current or traditional development practices. Paired programming is either a new practice or can be considered a redefinition of how programmers should work. Although there are advocates and critics of many of these practices, it is not within the scope of this research to commentonthesepractices. Before populating each Agile Levels in the SAMI with its suitable set of Agile Practices,alistofalltheAgilePracticesneedstobeknown.Theapproachtakento identify all the Agile Practices is to collect all Agile Practices used by current agile development methodologies [51] [57] [3]. Because of the large number of

86

redundancies, the collection process includes grouping similar practices together. Also, some of the names of the practices are changed to reflect a more generic approachtothepractice.Aftertheseadjustments,theresultisasetof40different Agile Practices. This compilation provides a starting point, but does not by any meanslimitAgilePracticestothislistonly. The Agile Practices are grouped according to the Agile Principles identified in Section 4.3. Each of the practices listed used to exemplify and manifest the Agile Principle above it within the software development process. The compiled list of AgilePractices(withreferences)are: EmbraceChangetoDeliverCustomerValue 1. Lowprocessceremony[60,72] 2. Clientdriveniterations[60] 3. Continuouscustomersatisfactionfeedback[64,77] 4. Evolutionaryrequirements[60] 5. Reflectandtuneprocess[64,77] PlanandDeliverSoftwareFrequently 6. Agileprojectestimation[29] 7. Smallerandmorefrequentreleases(48weeks)[64] 8. Adaptiveplanning[60][29] 9. Riskdriveniterations[60] 10. Planfeatures,nottasks.[29] 11. Maintainingalistofallfeaturesandtheirstatus(backlog)[57] 12. Continuousdelivery[60,57,45,17] 13. Planningatdifferentlevels[29] 14. Collaborativeplanning[72,27,60]

87

 Humancentric 15. Idealagilephysicalsetup[60] 16. Selforganizingteams[60,72,57,27] 17. Frequentfacetofacecommunication[72,27,18] 18. Collaborativeteams[80] 19. Empoweredandmotivatedteams[18] TechnicalExcellence 20. Testdrivendevelopment[16] 21. Pairedprogramming[84] 22. No/minimalnumberofCockburnsLevel1or1bpeopleonteam[24,22] 23. Dailyprogresstrackingmeetings[8] 24. Agiledocumentation[73,57] 25. Userstories[30] 26. Continuousintegration[60] 27. Continuousimprovement(refactoring)[57,17,41,7]. 28. Unittests[50] 29. 30%ofCockburnslevel2andCockburnslevel3people[24,22] 30. Softwareconfigurationmanagement[57] 31. Trackingiterationprogress[60] 32. Nobigdesignupfront(BDUF)[5,17] 33. Codingstandards[51,82,68] 34. Knowledgesharingtools[60] 35. Taskvolunteering[60] CustomerCollaboration 36. Frequent (collocated) facetoface interaction between developers & users[17] 37. Customerimmediatelyaccessible[22]

88

38. Customer contract revolving around commitment of collaboration [45, 64] 39. Customercontractreflectiveofevolutionarydevelopment[45,64] 40. Customercommitmenttoworkwithdevelopingteam[18] This list is not prioritized or ordered in any way. The references associated with each practice serve as a good starting point for those who wish to gain further knowledgeaboutthepractice.Abriefexplanationofeachpracticeisincludedinthe next sections. After compiling the Agile Practices, the next step is to place each practice in its relative agile level, as illustrated by Figure 23. Each puzzle piece representsoneormoreAgilePractices.
Agile Principles
A 5 B C D E

Agile Levels

4 3 2 1

Figure23.AgileLevelspopulatedwithAgilePracticescategorizedwithinAgilePrinciples

ThenextsectionfocusesontheprocessbywhicheachAgileLevelispopulatedwith Agile Practices, and how Agile Principles guide this process. The next section explains the population process through a detailed, working example of how Agile Level1ispopulated.

89

4.4.1 PopulatingAgileLevel1withAgilePractices
TopopulateanAgileLevel,onemustfirstrecognizetheobjectiveoftheAgileLevel. For example, the objective of Agile Level 1 is enhancing communication and collaborationinthesoftwaredevelopmentprocess. Atthispoint,theAgileLevelisemptyanddoesnotcontainanyAgilePractices(see Figure 24). The population process moves across the level, focusing on each Agile Principleseparately.TheprevioussectionshowstheAgilePracticesclassifiedunder eachAgilePrinciple.TheapproachtakentopopulateanAgileLevelistolookfirstat eachAgilePrincipleandtheAgilePracticesrelatedtothisprincipleandattemptto identifytheAgilePracticesthatpromotetheoverallobjectiveofthatAgileLevel(in thiscaseenhancingcommunicationandcollaboration).
Agile Principles Delivering Customer Value by Embracing Change Level 1: Collaborative Planning to Deliver Software Frequently Humancentric Technical Excellence Customer Collaboration

Figure24.AgileLevel1unpopulatedwithpractices

IdentifyingAgilePracticesrelatedtotheFirstAgilePrinciple Thefirstagileprinciple,deliveringcustomervaluebyembracingchange,providesa startingpointforexplainingtheprocessofpopulatingagilelevel1.Atthispoint,it is important to recall the objective of agile level 1, enhancing communication and collaboration,andthenlookatthesetofAgilePracticesrelatedtotheAgilePrinciple andaskwhichofthepractices,whenadopted,wouldenhancecommunicationand collaborationwithinthedevelopmentprocess.BelowarealltheAgilePracticesthat manifestthefirstAgilePrinciple:

90

Lowprocessceremony Clientdriveniterations Continuouscustomersatisfactionfeedback Evolutionaryrequirements Reflectandtuneprocess

The key concern is to ascertain if these five agile practices, when adopted, will enhance communication and collaboration. Different people may have different answers,whichisacceptable.Thisconceptofacceptingdifferentanswersisfurther discussed in Section 4.6, when the tailorability of the measurement index is discussed. With SAMI, the reflect and tune agile practice is included in the first level of agility, because this practice is concerned with holding retrospectives at regular intervals within the development process. The objective of this practice is alsototunethefutureuseoftheprocesstoovercomeanyobstaclesorchallenges facedthusfar. Holding these reflecting and tuning retrospectives enhances communication and collaborationbecausetheyprovideaforumwherethestakeholderscanexpressany process challenges they have encountered and suggest solutions for them for the next period of time. At the same time, this agile practice helps deliver customer value, because the stakeholders can discuss necessary changes in the process and actually embrace them. Ester Derby and Diana Larsen wrote an informative book aboutagileretrospectives[34].
Agile Principles Delivering Customer Value by Embracing Change Level 1: Collaborative
Reflect and tune process

Planning to Deliver Software Frequently

Humancentric

Technical Excellence

Customer Collaboration

Figure25.AgileLevel1populatedwithonlyoneAgilePractice

91


Atthispointinthepopulationprocess,oneagilepracticehasbeenidentifiedunder the first agile principle (see Figure 25). If no other practices exist under that principle that help enhance communication and collaboration,thenthe population process moves to the second principle to identify any agile practices under the secondprinciple IdentifyingAgilePracticesrelatedtotheSecondAgilePrinciple

Moving along to the second agile principle of planning and delivering software frequently,withinthislevelofagilitycontinuestheprocessofpopulatingAgileLevel 1.Again,itisnecessarytolookatallAgilePracticesunderthenamedprincipleand try to pick those practices that, once adopted, would enhance communication and collaboration.Thenextchoice,therefore,iscollaborativeplanning. Collaborative planning is a common concept used in agile and other collaborative environments.Theagileprocessencouragesallstakeholdersintheprojecttocome together during the planning phase or activities of the project. Even when the project is large and composed of many teams, it is recommended that representativesfromeachbeincluded.Thispracticeincreasesprojectvisibilityand buyin from different groups of stakeholders. Involving more people builds more loyaltyandacceptanceoftheplanunderdevelopmentandincreasesthemotivation and empowerment of the individuals on the team [72, 27, 60]. Other than participation in the decisionmaking process, collaborative planning is a powerful toolforinformationsharing,negotiationandparticipation. The rationale behind choosing this practice for Agile Level 1 is that collaborative planningrepresentsasteptowardestablishingacollaborative environmentwithin the organization. Without collaborative planning, employees may feel left out and, therefore,notexperienceownershipoftheproject.Anotherpossibleimpedimentto asuccessfultransitiontoagilityismanagerswhoareoutoftouchwiththerealityof

92

the software development effort, or the developers themselves, and, therefore, developaprojectplanthatisimpracticalandcausesfrustrationwithintheteam.All these are symptoms of a noncollaborative environment. The use of collaborative planning enhances communication and collaboration within the organization because the client, the developers, and the managers all work together to set the projectplan. IdentifyingAgilePracticesrelatedtotheThirdAgilePrinciple Thehumancentricprincipleisanotheragileprinciplewithinthefirstlevelofagility. There are many aspects to the humancentric nature of an agile software process. After the achievement of all five levels of agility, the organization realizes the full humancentric nature of agile software processes. However, since populating the first level of agility is the focus here, it was only necessary to select those Agile Practices that help establish a collaborative environment from a humancentric perspective.Consequently,inthislevelofagilitytherearetwohumancentricAgile Practices,collaborativeteamsandempoweredandmotivatedteams. In her latest book [80], Jean Tabaka defines a collaborative team. Her definition is comprehensive and includes some of the Agile Practices and concepts that are introducedinhigherlevelsofagility.However,AgileLevel1adoptsonlyasubsetof thecharacteristicsshehasdefinedforcollaborativeteams.Atthislevel,supervisors mustempowerandequiptheseteamswiththeauthoritytomakedecisionsontheir own.Thisauthorityhelpsmotivatetheteammembers,whomustbelievethatthey can solve any problem that team faces. The team members must cooperate with each other and with other teams. Although these concepts seem simple, they are oftenoverlookedwithinsoftwaredevelopmentefforts.Toestablishtrueagilityina software development process, a conscious effort must be made to introduce and maintainthesevaluesandcharacteristicswithintheteam.

93

Agile Principles Delivering Customer Value by Embracing Change Level 1: Collaborative

Reflect and tune process

Planning to Deliver Software Frequently

Collaborative planning

Human-centric

Technical Excellence

Customer Collaboration

Collaborative teams Empowered and motivated teams

Figure26.AgileLevel1afterpopulatedthreeAgilePrinciples

AfteridentifyingtheAgilePracticesthatservethefirstthreeAgilePrinciples,Agile Level1encompassesfourAgilePractices(seeFigure26). IdentifyingAgilePracticesrelatedtotheFourthAgilePrinciple ThepopulatingofAgileLevel1continueswiththetechnicalexcellenceprinciple,for whichthreeAgilePracticesarechosen.Thepracticesselectedare coding standards, knowledge sharing tools,and task volunteering.Allthreeofthesepracticespromote enhancing communication and collaboration from a technical excellence perspective. Even tools that focus primarily on promoting high quality software development have a communication or collaboration aspect to them. Coding standards are important for collaboration, because when people start collaborating and cooperating,codingstandardshelppeopleunderstandsharedcodemoreeasily[51, 82,68].Thepromotingofacollaborativeandcooperativeenvironmentmeansthat whilethedeveloperswritecodetheyneedtomakesuretheycancollaboratefroma coding perspective. Coding standards facilitate that level of collaboration because theycreateacommonlanguagebetweenallthedevelopers.Inotherwords,once someone opens the code of someone else, just by looking quickly through it and knowingthesestandards,heorshecanreadandcomprehendthecodewithease.It

94

wasinterestingtofindoutthatintheresultsoftheMarch2006AgileAdoptionRate SurveyconductedbyScottW.Ambler,haveshownthattheagilepracticemostoften adoptedbyorganizationswascodingstandards.About40%ofthemorethan4000 participantssaidtheyhadadoptedcommoncodingguidelines. The second agile practice chosen for Agile Level 1 to enhance communication and collaborationfromatechnicalperspectivewastheuseofknowledgesharingtools. Knowledge sharing tools could be electronics such as wiki, blogs or they could be simple whiteboards or walls. Continuously sharing project information through theseknowledgesharingtoolshelpstoestablishacollaborativeenvironmentwhile at the same time sharing technical information and hence enhances the technical excellence of the overall software development process. Another benefit of having knowledge sharing tools is increasing project visibility, which, in turn, increases loyaltyandthefeelingofownership.Thishelpssupportanotherpracticediscussed inthepreviousprinciple,empoweredandmotivatedteams.Insummary,knowledge sharing tools such as blogs, wikis and forums help to document and maintain the information and knowledge exchange that occurs between people and enables otherstolearnfromthat,therebypromotingevenmorecollaboration[60]. Thelastpracticechosenrelatedtothetechnicalexcellenceprinciplethatpromotes collaborationistoallowthedeveloperstovolunteerfortasksratherthanhavethe manager assign the tasks to them. It is a rather simple practice that is carried out usually during planning meetings. In a planning meeting once the list of tasks has been generated, the project manager should encourage people to volunteer and committotasksthattheychoosebasedontheirpreference.Besidesincreasingthe employeesmotivationandjobsatisfactionrate,thefreedomthatthispracticegives resultsinahigherqualityperformancefromtheemployeesthantheyarelikelyto givewhenamanagerassignsthetasks.Ifnoonevolunteersforaparticulartask,it istheteam'scollectiveresponsibilitytocompletethattask,insteadofthemanagers responsibilitytoassignittosomeone.

95


IdentifyingAgilePracticesrelatedtotheFifthAgilePrinciple The last agile principle, customer collaboration, suggests that to promote a collaborative environment the customer too has to commit to working with the developmentteam.Itisimportanttohavecustomer commitmentasapracticein AgileLevel1,becausemanyAgilePracticesfoundinupcomingAgileLevelsdepend on some degree of the customers interaction and collaboration. Therefore, the customerneedstomakeacommitmentatthisleveltoworkwith thedevelopment team.Althoughsomemightthinkofthecustomerswillingnesstocollaborateasthe default, in some situations a customer, reluctant to exert additional effort expects thecontractortoprovidethemajorityoftheproject'seffort[57].

Agile Principles Delivering Customer Value by Embracing Change

Reflect and tune process

Planning to Deliver Software Frequently

Collaborative planning

Human-centric

Technical Excellence
Coding standards Knowledge sharing tools Task volunteering

Customer Collaboration
Customer commitment to work with developing team

Collaborative teams Empowered and motivated teams

Level 1: Collaborative

Figure27.AgileLevel1populatedwithAgilePractices

By identifying the Agile Practices under the last Agile Principle, the population process of Agile Level 1 is complete (see Figure 27). We emphasize that the placement of the practices in the SAMI is not the focus of the measurement index. The SAMI structure is what is fundamental. In addition, the positioning of the practicesissubjecttochangefromoneusertoanother.Wedetailhowthisworksin Section4.6,whichdiscussesthetailorabilityofthemeasurementindex.

96

TheproceduretopopulateAgileLevels2through5issimilartothatofAgileLevel1. ThefollowingsectionbrieflydiscussesAgileLevels2through5andtheirassociated AgilePractices.

4.4.2 AgilePracticeswithinAgileLevel2
AgileLevel2encompassesasetofAgilePracticesthatworktogethersynergistically to deliver software incrementally in shorter cycles. Similar to Agile Level 1, Agile PrinciplesguidetheprocessofpopulatingAgileLevel2withitscorrespondingAgile Practices.ThefollowingisabriefdiscussionaboutLevel2AgilePracticespopulated fromeachAgile(Figure28).
Agile Principles Delivering Customer Value by Embracing Change Evolutionary requirements Planning to Deliver Software Frequently Continuous delivery Planning at different levels Humancentric Technical Excellence Software configuration management Tracking iteration progress No big design up front (BDUF) Customer Collaboration Customer contract reflective of evolutionary development

Level 2: Evolutionary

Level 1: Collaborative
Figure28.AgileLevel2populatedwithAgilePractices

Evolutionary Requirements is the most important agile practice that helps the delivery of software incrementally in shorter iterations. It suggests that requirementsshouldbeiterativelyevolvedinsteadofbeingfullydevelopedinone majorspecificationeffort[60].Agilepractitionersarguethatupfrontrequirements elicitation is ineffective. The reason is that requirements are bound to change. Therefore,elicitingknownrequirementsandleavingtheresttoevolvebasedonthe customersfeedbackyieldsthebestvaluetothecustomerandpreparestheprocess toembracechange.

97

 Continuous Delivery,anotherAgilePracticewithinLevel2,focusesonthenotion of delivering the product in small iterations at regular intervals. The emphasis is on regularintervals,becausehavingfirmdeadlinesforeachiterationensurestheteam hastodividetheproduct(andnotdeliveritallatonce)inordertomeetthegiven timeframeforeachiteration.ThedurationoftheiterationisirrelevantatthisAgile Level.AnotherAgilePracticeinLevel4definesthedurationoftheseiterations,and ensurestheyareshort.Onasidenote,itiscommontoseeagilepracticesinlower Agile levels to be of generic nature, and agile practices in higher Agile levels to be morespecific.Thisisduetothefactthatinthelowerlevelstheprojectisstillbeing introduced to these new agile concepts, and then later as they become more agile (i.e.aspireforhigheragilelevels),theseconceptswillbemanifestedthroughmore specificpractices. Since the development process is now delivering the product in iterations on a regularbasis,anotherAgilePractice, Planning at different levels, isneededtoensure that the project teams maintain a plan for both the overall product development lifecycleandtheindividualiterations.Usuallytwolevelsof planningoccurinagile projects:Releaseplanning(dealingwiththeoverallproduct)anditerationplanning (dealingwithcurrentiteration). Fromatechnicalexcellenceperspective,itiscrucialnowatthisleveltohavesome tool for Software Configuration Management (SCM). SCM tools help control the different versions and iterations of the software being developed. Another agile concept found in this level is Tracking Iteration Progress, which is concerned with the team having a means by which they can measure the progress of the developmenteffortwithineachiteration.Thisconceptdoesnotdictateaparticular methodtofulfillthistracking.Itemphasizes,however,theneedtohaveit.InAgile Level 4, another Agile Practice (Daily progress tracking meetings) defines a particularwaytoachievethisagileconcept. 98

NoBigDesignUpFront(NoBDUF)isanotheragilepracticethatensurestheproduct isbeingdevelopedusinganevolutionaryapproach.BDUFiswherea"big"designis createdbeforecodingandtestingtakesplace,asinatypicalwaterfalldevelopment process. In Agile development design is not a onetime, upfront phase, it occurs throughoutthedevelopmentprocess. The last Agile Practice within Agile Level 2 is customer contract reflective of evolutionary development. This practice ensures the customer understands the evolutionary nature of the development process. It also does not define individual milestoneswhen all the requirementsand design documentsare completed. Ifthe contract does so then the evolutionary nature of the whole process is in jeopardy. Thecontractorwillwanttomeetthesedeadlinesandthereforewillnotworkusing an evolutionary approach. Milestones in contacts that are reflective of the evolutionary development approach are usually defined around iterations or releases. By adopting these agile practices the software development process can deliver softwareearlyandcontinuouslyandhencefulfillsthegoalofAgileLevel2.Oncethe development process is evolutionary (i.e. Agile Level 2 is archived), the project is ready for a higher level of agility. This is manifested in the projects ability to develophighqualityworkingsoftwareinanefficientandeffectivemannerwhichis the objective of Agile Level 3. The following section presents the different agile PracticesinAgileLevel3thathelpthelevelfulfillitsobjectives.

4.4.3 AgilePracticeswithinAgileLevel3
BeforeachievingAgileLevel3,theorganizationshouldhavealreadyadoptedallthe practices in Agile Level 1 and 2. Now that communication and collaboration have been instilled in the development process, and the development process is deliveringsoftwareearlyandfrequently,theobjectiveofAgileLevel3istoincrease

99

the efficiency and effectiveness of the development process. This is achieved by encouraging the adoption of more engineering practices that enable the development of high quality working software. This is important because Agile Level4focusesonembracingchange,andthereforeAgileLevel 3mustensurethe development process is effective, efficient, and stable (by adopting more engineering practices). To ensure the development process produces quality softwareinanefficientandeffectivemanner,theSAMIsuggeststheadoptionofnine differentAgilePractices(seeFigure29). Risk Driven Iterations help tackling risk elements as early as possible. Mitigating those risks early ensures that the project team does not spend a considerable amount of time building a system that they cannot complete. By catching these issuesearly,thedevelopmentprocessbecomesmoreeffective.
Agile Principles Delivering Customer Value by Embracing Change Planning to Deliver Software Frequently
Risk driven iterations

Human-centric

Technical Excellence

Customer Collaboration

Self organizing teams

Continuous integration Continuous improvement (refactoring) Unit tests 30% of level 2 and level 3 people

Level 3: Effective

Plan features not tasks. Maintain a list of all features and their status (backlog)

Frequent face-to-face communication

Level 2: Evolutionary

Level 1:
Collaborative Figure29.AgileLevel3populatedwithAgilePractices

AnotheragileconceptinLevel3istomakesurethattheteamis Planning Features not Tasks. The customer usually expresses their needs as features in terms of the

100

customersdomainvocabulary(e.g.anelectronicshoppingcart).Tasks,ontheother hand,areusuallyexpressedinthedeveloperstermsandarenotunderstandableto thecustomer(e.g.buildaninterface).Oneofthemainreasonswhyplanningshould be done in terms of features not tasks is to prepare the development process for Client Driven Iterations (an Agile Practice in Agile Level 4). Another reason is that the planning is done in terms of features, when a certain feature changes or is removedtheimpactithasontheplanningprocessisminimized. Maintaining a list of all features and their status (i.e. backlog) is another agile practice in this level. The product backlog is a list of the business and technical requirements for the system being built or enhanced based on the current knowledgeofthesystem.Thispracticeincludesthetasksforcreatingthebacklog, and controlling it consistently during the process by adding, removing, specifying, updating, and prioritizing the backlog items. In this Agile Level the concern is not about who maintains this list or has authority to change it, the focus is to ensure suchabacklogexists. From a humancentric perspective, having an efficient and effective development process entails establishing efficient and effective communication between the members of the team. Having frequent facetoface communication is one of the means to ensure that communication is more effective [24] [6]. Another human centric Agile Practice is that of selforganized teams. A selforganized team is empowered by management to make decisions on their own without waiting for managements approval. These teams are usually crossfunctional and the roles of individuals are not defined. When the team is given a task, it becomes the responsibilityofthewholeteam,collectively,tofinishit,notaspecificpersononthe team.Managementtreatsselforganizingteamsasoneentitywithoutdistinguishing between the individuals of the team. The importance of having selforganizing teams in this particular agile level is that, as the authors of the Agile Manifesto highlighted, the best architectures, requirements, and designs emerge from self

101

organizing teams, and it is in this Agile Level that it is crucial that the project developsthehighestqualityofworkingsoftware. InAgileLevel3,therearefouragilepracticesfoundunderthetechnicalexcellence agileprinciple.ThefirstagilepracticeunderthisprincipleisContinuousIntegration. Continuous Integration is a software development practice that encourages members of a team to integrate their work frequently. It is preferred that each integrationisverifiedbyanautomatedbuildtoolinordertodetectanyintegration errors as quickly as possible. This approach leads to significantly reduced integrationproblemsandallowsateamtodevelopcohesivesoftwaremorerapidly [36]. Another Agile Practice recommended to improve effectiveness of the development process and make it ready to embrace change is that of Continuous Improvement (aka Refactoring).Refactoringisanessentialpracticetobeadoptedat Agile Level 3 because of the project evolutionary development process (assumed after Agile Level 2). Agile development addresses the issue of continuously developing and improving a systems design by the use of refactoring [41] [7]. Refactoring involves rewriting the code to improve its structure, while explicitly preservingitsbehavior,andissometimesinformallyreferredtoas"cleaningupthe code". Therefore, regularly refactoring the code is necessary since evolutionary requirements are adopted (from Agile Level 2). In general, the refactoring process focuses on removing code duplication (a sign of poor design that might be introduced due to no Big Design Up Front). Additionally, refactoring increases the cohesion of the code, while lowering its coupling, which makes the system more readytoembracechangewithoutbreakingotherpartsofthesystem. Refactoring is strongly supported by comprehensive testing to be sure that as the designevolves,nothingisbroken.Thus,organizationsareencouragedtoadopt Unit Tests, another agile practice in this level. Unit tests are code procedures used to validatethatindividualunitsofsourcecodeareworkingproperly.Aunitofsource code is the smallest testable part of an application. For example, in procedural programming a unit may be a function or procedure, while in objectoriented 102

programming, the smallest unit is usually a class. A unit test provides a strict, writtencontractthatthepieceofcodemustsatisfy.Whilein anagiledevelopment processitishighlyrecommendedforunittestingtobeautomatedthroughatesting framework,itmaystillbeperformedmanually. ThelastagilepracticeinAgileLevel3istohave 30%oftheteambeCockburnLevel2 or Cockburn Level 3 people. Cockburns people levels are directly related to the amount of experience the developer has. Inspired by the martial art of Aikido, Alistair Cockburn has discussed the three levels of listening at which people are placed [24]. Cockburn has identified three levels of understanding people have when they approach new material and has argued that a persons level of understanding is directly linked to his or her experience in the domain. Barry Boehm adapted these levels of generic understanding and created a measurement indextoqualifythecompetencyofthedeveloperbasedonhisorherunderstanding of the core concepts of programming, especially object oriented programming. Whilethismeasurementindexisincomplete,itisagoodstartingpointforcreatinga way to measure the competency of the developers not in terms of a set of generic skills, but in terms of their understanding of how to this approach object oriented programming. Table 11 identifies the characteristics expected from developers at eachoftheCockburnsLevels.
Level 3 2 1A 1B 1 Characteristics Abletoreviseamethod(breakitsrules)tofitanunprecedentednewsituation Abletotailoramethodtofitaprecedentednewsituation With training, able to perform discretionary method steps (e.g., sizing stories to fit increments,composingpatterns,compoundrefactoring,complexCOTSintegration).With experiencecanbecomeLevel2 With training, able to perform procedural method steps (e.g. coding a simple method, simplerefactoring,followingcodingstandardsandCMprocedures,runningtests).With experiencecanmastersomeLevel1Askills. May have technical skills, but unable or unwilling to collaborate or follow shared methods. Table11.Cockburn'sLevels

103

AtAgileLevel3,theteamneedstoconsistofdeveloperswhocanhandlenewand unexpectedproblemsbecausetheyareadoptingmanynewtechnicalpractices,that iswhyCockburnsLevel3andLevel2peopleareimportantelementsoftheteam. BeforepresentingtheAgilePracticesinLevel4,theisanimportantreasonwhythe agilepracticeregardingthecompetencyoftheteammembers(CockburnsLevels)is inthesameAgileLevelasthatofselforganizingteams.Theexplanationstemsfrom Ken Blanchard and Paul Herseys theory of Situational Leadership, which explains the relation betweenthe issue ofpersonnel competenceand selforganizing teams [44]. Blanchard and Hersey have characterized leadership style in terms of the amount of direction and support that the leader provides to his or her followers. They have categorized all leadership styles into four behavior types. Additionally theirtheoryarguesthatleadersshouldnotalwaysuseoneleadershiptype,because leadership depends on two factors, the commitment and competence of the followers. DirectingLeaders:makeandannouncedecisions.Usedwithlowcompetence, highcommitmentfollowers Coaching Leaders: seek ideas and suggestions from the followers, but make the decisions. Used with followers with some competence and low commitment Supporting Leaders: facilitate daytoday decisions, such as task allocation and processes, that are now the responsibility of the followers. Used with followersthathavehighcompetenceandvariablecommitment Delegating Leaders: give control to the followers and decide the time and extent of their own involvement. Used with high competence, high commitmentfollowers Withthistheoryinmind,theagilepracticeofhaving selforganizing teamsimplies that management should give the employees control over the decision making process. This is similar to the Supporting and Delegating leadership styles, which

104

Blanchard and Hersey recommend should be practiced only when there are competent individuals on the team. This is why competencerelated practices are not introduced until Agile Level 3, the same level in which the practice of self organizingteamsisintroduced. AfteradoptingtheAgilePracticeinAgilelevel1,2and3,thedevelopmentprocess shouldbereadytomovetothenextlevelofagility,AgileLevel4.

4.4.4 AgilePracticeswithinAgileLevel4
The practices in Agile Level 3 focus on increasing the overall efficiency and effectivenessofthesoftwaredevelopmentprocessbyadoptingcertainengineering practices that help stabilize and automate the development process. Establishing these practices first helps prepare for Agile Level 4, which focuses on responding andembracingchangethroughmultiplelevelsoffeedback.Thissectionpresentsan overviewofthenineagilepracticesthatenableAgileLevel4toachieveitsobjective (seeFigure30). OneofthekeyAgilePracticesenablingthedevelopmentprocesstoberesponsiveto change (i.e., adaptive) is to have Client Driven Iterations. Clientdriven iterations imply that the client dedicates the choice of features for the next iteration. This makestheclientincontrolandabletochangethesystembasedonwhateverthey perceive as the highest business value to them. In this way, the client steers the project,iterationbyiteration,requestingthefeaturesthattheycurrentlythinkare mostvaluablebasedontheirlatestinsight,ratherthanspeculativelyatthestartof the project. The customer has ongoing control to change the system as fresh information arises, and the development process should easily embraces these changes.AnotheragilepracticethatissupplementarytoClientDrivenIterationsis Continuous customer satisfaction feedback. Continuousfeedbackiscrucialtoensure the customer is satisfied with what is being developed. If customer satisfaction or acceptanceisonlysoughtattheendofaproject,thenthereisasignificantriskthat

105

whathasbeendevelopedisnotwhatthecustomeractuallyneeds.Moreover,when thecustomerrequestsachangeinthesystem,itiscrucialtogathertheirfeedbackto ensurethechangeimplementedissatisfactory.Ifthispracticeisoverlooked,more time and much effort are wasted. Hence in highly adaptive environments, such as Level 4 of agile software development, gathering frequent feedback from the customerisessentialtoensurethattherightproductisbeingdeveloped.
Agile Principles Delivering Customer Value by Embracing Change
Client driven iterations

Planning to Deliver Software Frequently

Smaller and more frequent releases (4-8 weeks) Adaptive planning

Human-centric

Technical Excellence

Customer Collaboration

Daily progress tracking meetings Agile documentation User stories

Level 4: Adaptive

Continuous customer satisfaction feedback

CRACK Customer immediately accessible Customer contract revolves around commitment of collaboration

Level 3: Effective Level 2: Evolutionary

Level 1:
Collaborative Figure30.AgileLevel4populatedwithAgilePractices

LookingbackatAgileLevel2,underthePlanningtodeliverSoftwareFrequently Agile Principle, there is a practice named Continuous Delivery. A more specific version of this agile practice is what is found in Agile level 4, under the same principle,andistitledSmaller and more frequent releases (48 weeks).Smallerand more frequent releases (48 weeks) encourages organizations to keep the timeframeforthereleasessmallandlimitthemto8weeks.Thispracticefocuseson thetimeframeforeachreleasenotiteration.Usuallybuilding areleasewillinclude multiple iterations. Therefore, while not explicitly restricting the timeframe for iterations,naturallywhenthereleasetimeframeisreduced,theiterationtimeframe

106

should be reduced accordingly. Having shorter releases helps the development processs ability to embrace change. Once a release is completed, feedback is obtainedandusedtoadaptthenextrelease.Ifthetimebetweenreleasesislong,it meansadditionaltimeandeffortwillbeinvestedintotheproductbeforefeedbackis obtained.Theriskisthatthisfeedbackmaychangethedirectionoftheproduct,and thereforeitwouldhavebeenmuchbettertofindthatchangeofdirectionasquickas possible.Thenext,andcloselyrelated,agilepracticeisAdaptivePlanning.Ingeneral, themoretimespentonaproject,themoreknowledgeoneacquiresaboutit.Many people invest so much time creating a plan for the entire project at the beginning (whentheyhavetheleastknowledgeabouttheproject)andavoidplanningduring the project (when more information becomes apparent). Adaptive Planning delays developinganiterationdetailsuntilimmediatelybeforethefollowingiteration,and thereforeincorporatesallthefeedbackobtainedincludingwhatislearnedfromthe previousiteration.Adaptiveplanninghelpsorganizationsembracechangebecause the focus shifts from adapting to a plan (which make people less embracing of change) to continuously planning based on the latest feedback obtained (which inherentlypromotesthecultureofwelcomingchange). In Agile Level 4, under the technical excellence principle, there are three agile practices. The first is daily progress tracking meetings. As mentioned earlier, this agilepracticeisamorespecificversionofanotheragilepractice(TrackingIteration progress)locatedinAgileLevel2.Thekeyto daily progress tracking meetingsisthe worddaily.FromthestartofAgileLevel4onecannoticethefastpacenatureofthis level.Thisiswheretheagilityofthedevelopmentprocessis reallyputtotest.The development process will need to respond to growing demands while still producing high quality working software. Therefore, to survive in a fastpaced adaptiveenvironment,theteammuststayinformedonadailybasisregardingthe statusoftheiteration.Anotherimportantagilepracticethatis Agile Documentation [73].UntilAgileLevel4,documentationisnotmentioned,despitethefactthatitis one of the first negative things mentioned about Agile Software development.

107

Nevertheless,AgileDocumentationdiscourageswritingunnecessaryrequirements, designormanagementdocumentsfortwomainreasons[17][60].Thefirstreason is that agile practitioners have recognized that there is a cost associated with developing and maintaining documentation. The second reason is that documentation does not deliver value to the customer, while working software does.Therefore,minimaldocumentationispromotedinagiledevelopment,because itgivesthecustomerabetterandearlierreturnoninvestmentvaluableworking softwareinsteadofperceivedinvaluabledocuments. ThelastAgilePracticeunderthetechnicalexcellenceagileprincipleisUserStories.A userstoryisanagilepracticewheresoftwaresystemrequirementsareformulated asoneortwosentencesintheeverydaylanguageoftheuser.Userstories,together with acceptance tests,are used for the specification of requirements in some agile softwareengineeringmethods.Eachstorymustbeshortenoughtofitonthesideof anotecard.Thecustomersshouldwritethestoriesforthesoftwareproject;these storiesarethewaytheyinfluencedevelopment.Userstoriesare,therefore,aquick way of handling customer requirements without having to deal with large formal requirement documents and tedious tasks related to maintaining them. This helps thedevelopmentprocessrespondfasterandwithlessoverheadtorapidlychanging realworldrequirements. The final two Agile Practices within Agile level 4 are related to Customer Collaboration. The first practice is to have the CRACK Customer immediately accessible. A CRACK Customer refers to a customer who is Collaborative, Representative, Authorized, Committed and Knowledgeable. These characteristics are important because they address a number of issues that emerge during the development process. At this level, the focus is not where this CRACK customer is located, the focus is on how responsive they are. To cope with the fastpaced environment where change is welcomed and embraced, the team must have immediateaccesstoaCRACKCustomertoaddressalltheirquestionsandconcerns astheyarise.Thenext,andlast,AgilePracticeinthislevelistohavethecustomer

108

contact revolve around commitment of collaboration not features or requirements. Thisisoneoftheultimatefactorsthatenablesorganizationstoembracechangeand actually welcome it. Usually the customer contract contains a list of features or requirementsthatonemustdeliverorelsetheyareatriskofnotgettingthemoney orlegalprosecution.Ineitherwaytheorganizationusuallypreferstonotwelcome change and just deliver what they were contracted for and get the money. What thispracticewanttoachieveistohavethecustomeragreestocontractthedegree andamountofcollaborationwehavenotthelistofrequirementsorfeatures. WiththeadoptionofallthepracticesinAgileLevel4,theorganizationaspiresfor even a higher level of agility, Agile Level 5. The next section presents the agile practicesfoundwithinAgileLevel5.

4.4.5 AgilePracticeswithinAgileLevel5
AgileLevel4buildsuponthecommunicationandtechnicalfoundationsestablished by Agile levels 1 through 3. Agile Level 4 takes the development process to a new level of agility by enabling it to respond to change. The next level of agility, Agile Level5,focusesnotonlyonthedevelopmentprocess,butalsoontheculture.Agility isessentiallyaculture,anditisimportanttohaveanenvironmentthatisreflective andsupportiveoftheagilenatureofthesoftwaredevelopmentprocess.Therefore, Agile Level 5 concentrates on establishing an allencompassing environment to sustain and foster agility throughout the organization. This section presents the sevenagilepracticesthatenableAgileLevel5toachieveitsobjective.Thesecanbe seeninFigure31. The first agile concept is that of having Low Process Ceremony in the organization. ProcessCeremonyisthelevelofpaperworkinvolvedwithaprocess.Forexample, anorganizationwithhighprocessceremonywouldrequirethatchangerequestsbe

109

signed by at least three levels of management. It is obvious that high process ceremonyjeopardizestheveryessenceofagility,beingresponsivetochange.
Agile Principles Delivering Customer Value by Embracing Change
Low process ceremony

Planning to Deliver Software Frequently

Agile project estimation

Human-centric

Technical Excellence

Customer Collaboration

Ideal agile physical setup

Test driven development Paired programming No/minimal number of level -1 or 1b people on team

Level 5: Encompassing
Level 4: Adaptive Level 3: Effective Level 2: Evolutionary

Frequent faceto-face interaction between developers & users (collocated)

Level 1:
Collaborative Figure31.AgileLevel5populatedwithAgilePractices

Under the Planning and Deliver Software Frequently agile principle, most of the practices are related to planning. However, in Agile Level 5 the focus moves to a more fundamental point, which is Agile Project Estimation. This is an important practicebecauseplansareonlyasgoodastheestimatestheyarebasedon.Atthe same time, highly dynamic and changing environments, such as the agile environment, needs an estimating technique that is flexible without jeopardizing accuracy. Agile Project estimation can be done in various ways; two of the most populararestorypointsandidealdays[29]. From a humancentric perceptive, having the Ideal agile physical setup helps establish the right environment for the agile software development to thrive in. Manydifferentphysicalsetupsaresuitableforagiledevelopment.Thekeytomost

110

of these physical setups is to have the whole team together in one room with no cubiclesordividers.Theobjectiveistohaveasmuchtacitknowledgeflowbetween all the team members. Accessibility to team members becomes instantaneous and lines are immediately established. The physical setup of an agile working environment also deals with the way the tables are setup in the room, the equipment available in the room (white boards, projectorsetc) and also the way thewallsareutilizedasinformationradiators[24][45]. AfamousagilepracticeisTestDrivenDevelopment(TDD).TestDrivenDevelopment (TDD)isasoftwaredevelopmenttechniquethatinvolvesrepeatedlyfirstwritinga test case and then implementing only the code necessary to pass the test. Practitioners emphasize that testdriven development is a method of designing software,notmerelyamethodoftesting.AdoptingTDDresultsinaculturechange relatedtotesting,designingandrequirements.Additionally,adoptingTDDrequires that the developers have a certain level of comfort with automated unit testing. ThereisarhythmtoTDD.Firstthedevelopercreatesonetesttodefinesomesmall aspectoftheproblemathand.Thens/hecreatesthesimplestcodethatwillmake that test pass. Then s/he creates a second test. Now the programmer adds to the codetheyjustcreatedtomakethisnewtestpass,butnomore!Notuntiltheyhave yetathirdtest.S/hecontinuesuntilthereisnothinglefttotest.Thecodecreatedis usually simple and concise, implementing only the features wanted. Other developerscanseehowtousethisnewcodebybrowsingthetests. AnotherAgilePracticethatisreflectiveofaculturechangeis Paired Programming. Paired programming is an agile practice that requires two software engineers to participate in a combined development effort at one workstation. Each member performstheactiontheotherisnotcurrentlydoing;forexample,whileonetypesin unitteststheotherthinksabouttheclassthatwillsatisfythetest.Thepersondoing the typing is known as the driver, while the person guiding is known as the navigator.Itisoftensuggestedthatthetwopartnersswitchrolesatleasteveryhalf hour or after making a unit test. When an organization starts using Paired 111

Programming an environment of technical excellence is created because of the immense sharing of expertise that occurs from developers working together. Additionally,asenseofcollectiveownershipofthecodeemergeswherecodeisnot ownedbyoneperson,butmultiplepeople. Sincethecompetencelevelsofdevelopersplaysasignificantpartinagilesoftware development, the SAMI requires the team to have more competent people on it at thehigherlevelsofagility.AprojectaspiringforAgileLevel5shouldhave no or a minimal number of Cockburn level1 or 1b peopleontheteam.Asexplainedearlier in4.4.3CockburnLevel1BinLevel1developershavetheleastexperienceandare notableorwillingtocollaboratewhichcanhamperthetransitiontoagility;thisis whytheirpresenceisdiscouragedatAgileLevel5.Agilepractitionershavesaidthat competent people are necessary because of the nature of the fastpaced developmentprocessandtheconstantneedtoberesponsivetochange. The final agile practice in Agile level 5 is to have frequent facetoface interaction between developers and users (collocated).Itisidealtohavenotjustthedevelopers collocated by also have the customer and users in the same room. This ensures almostinstantfeedbackandincrediblecommunication. The previous explanations about the positioning of the Agile Practices show that thereissynergycreatedwhenthepracticesofeachagilelevelareputtogetherand adoptedtogether.Thatiswhyitisnotrecommendedtoencouragepeopletojump levelsandtrytoadoptpracticesofahigherlevelbeforetheyhaveadoptedallthe practices in the lower levels. Table 12 consolidates all the Agile Levels and their AgilePractices,categorizedbytheAgilePrincipletheyfallunder.Itisimportantto emphasize that the population of the SAMI is not fixed, and is subject to peoples experience. Intheprevioussectionswehighlightedourrationalforpositioningeachpracticein their respective levels. Through time and experience our opinions may change on 112

wherecertainpracticeswouldbebestsituated.Whatiskeytorememberisthatthe positions of the practices in the measurement index is not the focus of the measurement index, it is the structure of the SAMI that is fundamental. The tailorabilityoftheSAMIisdiscussedingreaterdetailinSection4.6
Agile Principles Embrace Change to Deliver Customer Value Level 5 Encompassing Establishing a vibrant environment to sustain agility Low process ceremony [60, 72] Plan and Deliver Software Frequently Agile project estimation [29] Human-centric Ideal agile physical setup [60] Technical Excellence Test driven development [16] Paired programming [84] No/minimal number of level -1 or 1b people on team [24, 22] Level 4 Adaptive Responding to change through multiple levels of feedback Client driven iterations [60] Continuous customer satisfaction feedback [64, 77] Smaller and more frequent releases (4-8 weeks) [64] Adaptive planning [60] [29] Daily progress tracking meetings [8] Agile documentation [73, 57] User stories [30] CRACK Customer immediately accessible [22] Customer contract revolves around commitment of collaboration [45, 64] Customer Collaboration Frequent face-toface interaction between developers & users (collocated) [17]

Level 3: Effective Developing high quality, working software in an efficient an effective manner

Risk driven iterations [60] Plan features not tasks. [29] Maintain a list of all features and their status (backlog) [57]

Self organizing teams [60, 72, 57, 27] Frequent face-to-face communication [72, 27, 18]

Continuous integration [60] Continuous improvement (refactoring) [57, 17, 41, 7]. Unit tests [50] 30% of level 2 and level 3 people [24, 22]

Level 2: Evolutionary Delivering software early and continuously

Evolutionary requirements [60]

Continuous delivery [60, 57, 45, 17] Planning at different levels [29]

Software configuration management [57] Tracking iteration progress [60] No big design up front (BDUF) [5, 17]

Customer contract reflective of evolutionary development [45, 64]

Level 1: Collaborative Enhancing communication and collaboration

Reflect and tune process [64, 77]

Collaborative planning [72, 27, 60]

Collaborative teams [80] Empowered and motivated teams [18]

Coding standards [51, 82, 68] Knowledge sharing tools [60] Task volunteering [60]

Customer commitment to work with developing team [18]

Table12.SAMIpopulatedwithAgilePractices

113


The identification of the agile level and its principles and the Agile Practices and conceptsinsideeachlevel,hascompletedthefoundationoftheagilemeasurement index.Thelastcomponent,theindicators,istheactualmeans usedtomeasurethe degreeofagilityforadevelopmentprocess.Thenextsectiondiscussesindicatorsin detail.

4.5 Indicators
Thus far, SAMI, with its levels, principles and practices, only offers a roadmap for agile adoption efforts. Its levels and practices give organizations guidance about which practices to adopt first and the sequence of adoption. Moreover, the measurement index, as detailed thus far, is not capable of assessing the agile potentialofaprojectororganization,becauseitlacksassessmentindicators.

4.5.1 IntroductiontoIndictors
Basically,indicatorsarequestionstheassessorusestoassesscertaincharacteristics ofanorganizationorproject,suchasitspeople,cultureand environment,inorder to determine the entitys current or target level of agility. A set of indicators, or questions, should accompany each agile practice or concept in the measurement index. These indicators are used to assess the readiness of the organization or projecttoadoptanagilepracticeTheSAMIemploysover300indicatorsdeveloped fortheAgilePracticesidentifiedwithintheagilemeasurementindex. Theobjectiveoftheindicatorsistoassesshowreadytheorganizationistoadopta certain agile practice. Therefore, the indicators associated with each agile practice areconcernedwithassessingorganizationalcharacteristicsthatcouldinfluencethe extent to which the organization is ready to adopt that agile practice. The

114

organizational or project characteristics usually assessed to determine the readinessforapracticeare: Since indicators are essentially questions, someone must be responsible for answeringthem.Thecustomerisresponsibleforansweringsomeoftheindicators, while the developers and the managers answer still another group of indicators. Each of the indicators attempt to assess the groups opinion or feeling toward a certain concept or idea. The assessor usually answers indicators related to observing an activity or reviewing an artifact. Table 13 and Table 14 list some sample indicators that are used to assess the extent to which an organization is ready to adopt the agile practice of collaborative planning. Table 13 depicts some sample indicators that the developers should answer, and Table 14 shows some sampleindicatorsthatthemanagersshouldanswer.

Customers:theprojectscustomersandclients Developers:thetechnicalstaffinvolvedwiththedevelopmentoftheproject Managers: the managers or executives overseeing the project and involved withdecisionmaking Tools:thesoftwaretoolsusedwithintheorganizationorforacertainproject Culture: the overall culture of the people within an organization or the projectteam Project management: the procedures and practices related to managing projectsintheorganization Software Process: the activities and artifacts related to the software developmentprocessintheorganization Physical environment: the physical layout of the organization and the geographicalandgeospatialdistributionofitsemployees

115

Indicator# OR1_D1

Statements Your manager listens to your opinions regarding technical issues You would like to participate in the planning process of the project you will work on. It is acceptable for you to express disagreement with your manager(s) without fearing their retribution. Strongly Disagree Strongly Disagree Strongly Disagree Tend to Disagree Tend to Disagree Tend to Disagree

NominalValues Neither Agree nor Disagree Neither Agree nor Disagree Neither Agree nor Disagree Tend to Agree Tend to Agree Tend to Agree Strongly Agree Strongly Agree Strongly Agree

OR1_D5

OR1_D7

Table13.Sampleindicatorstobeansweredbythedeveloper

Indicator# OR1_M3 Statements You usually seek your subordinates opinions before making a decision. You frequently encourage your subordinates to find creative solutions to problems. Developers should aid in the planning of a project. Strongly Disagree Strongly Disagree Strongly Disagree Tend to Disagree Tend to Disagree Tend to Disagree NominalValues Neither Agree nor Disagree Neither Agree nor Disagree Neither Agree nor Disagree Tend to Agree Tend to Agree Tend to Agree Strongly Agree Strongly Agree Strongly Agree

OR1_M5

OR1_M9

Table14.Sampleindicatorstobeansweredbythemanager

Theindicatornumber(firstcolumn)isusedtoidentifyandreferencetheindicator. Thefirsttwolettersintheindicatorsnumber(OR)meanthat theseindicatorsare concernedwithassessingorganizationalreadiness.Thenextnumeral(1)represents the agile level of the agile practice to which these indicators are related. Since collaborativeplanningisanagilepracticewithinAgileLevel1,thenumeralusedis (1). The letter after the underscore ( _ ) refers to the type of person who should provideananswerfortheindicator.Thefourlettersusedforthatpositionare: A: denoting an indicator that the assessor, or the person conducting the assessment,needstoanswer D: denoting an indicator that the developer, or anyone on the development sideoftheproject,needstoanswer M:denotinganindicatorthatamanager, oranyoneperformingmanagement relatedtasksfortotheproject,needstoanswer

116

C:denotinganindicatorthatacustomerexecutive, or adecisionmakerfrom theentitycontractingtodevelopthesoftware,needstoanswer

Asequentialnumberisusedasthelastdigitintheindicatorsnumber.Theindicator itself(whichcanbeseeninthesecondcolumn)isusuallyastatementorquestion thatneedsaresponse.Mostindicatorsarebasedona5pointLikertsummatedscale (thirdcolumn),from1stronglydisagreeto5stronglyagree.Asmallnumberof indicators are based on other 5point scales that are more appropriate to the organizationalcharacteristicbeingassessed.

4.5.2 OrganizationoftheIndicators
Thisdiscussionofthesampleindicatorsprovidesastartingpointforanexplanation oftheorganizationandstructureoftheseindicatorswithintheagilemeasurement index. Each agile practice is associated with a set of indicators that measure the extenttowhichtheorganizationisreadytoadopttheassociatedagilepractice.The GoalQuestionMetricapproach(GQM)[13]andtheObjectivesPrinciplesAttributes (OPA)Framework[9]influencedtheapproachusedtodevisetheindicatorsforeach practice. Each indicator is designed to measure a particular organizational characteristic(discussedearlier)necessaryforthesuccessfuladoptionoftheagile practiceassociatedwiththeindicator.Inotherwords,thegoalistoassessthestate of a certain organizational characteristic and then determine if the state of that characteristic is supportive of the adoption of the practice. For example, to assess thereadinessofanorganizationtoadoptcollaborativeplanning,theassessorneed toascertainifitsmanagementstyleissuitablefortheadoptionoftheagilepractice. Hence, Management Style is the organizational characteristic assessed. The goal behindassessingthemanagementstyleistodeterminewhetheracollaborativeora commandcontrol relation exists between managers and subordinates. The management style is an indication of whether management trusts the developers andviceversa.

117

Therefore, the first step in identifying the indicators for an agile practice is to identify the organizational characteristics that need to be assessed in order to determinetheextenttowhichtheorganizationisreadytoadoptthepractice.Figure 32 shows the different organizational and project characteristics that need to be assessedfortheAgilePracticesinLevel1.
Management Style (M=7,D=4) Managements Buy-in (M=2) Management Transparency (M=4) Power Distance (M=1,D=4) Developers Buy-in (D=1) Planning Activity Exists (M=2,A=1) Managements Buy-in (M=2) Developers Buy-in (D=1) Interaction between developers (M=1,D=1) Belief in Collectivism (D=1) Developers Buy-in (D=4) Empowerment of Developers (M=2,D=3) Motivation of Developers (D=6) Managements Trust to Developers (M=4,D=1) Developers Buy-in (D=2) Existence of Coding Standards (A=1) Developers Buy-in (M=1,D=2) Managements Buy-in (M=5) Availability of Knowledge Sharing Tools (A=1) Developers Buy-in (D=1) Managements Buy-in (M=1) Ability to Change and Improve Process (M=3,D=3)

Collaborative Planning

Task Volunteering, not Task Assignment Collaborative Teams

Empowered and Motivated Teams Coding Standards Knowledge Sharing

Reflect and Tune Process

Figure32.OrganizationalCharacteristicsassessedforpracticeinAgileLevel1

While the typical structure for an indicator hierarchy is a tree (as in Figure 32), there are cases when the indicator structure can be an acyclic graph. This occurs when the same question (indicator) is used to assess two different organizational characteristics or when two different agile practices depend on the same organizationalcharacteristic.Thisdistinctionbetweenthestructurebeingatreeor anacyclicgraphhasnodirectimpactontheassessmentprocessbutitisapointthat isworthmentioning.

118

The assessor has two ways to identify the organizational characteristics that need assessmenttodetermineanorganizationsreadinessforanagilepractice.Thefirst is commonsense and the second is experience and technical literature. The first is selfexplanatory, because determining the organizational characteristics for some AgilePracticesisamatterofcommonsense.Forexample,makingsurethatthereis adevelopersbuyinbeforeadoptingcodingstandardsiscommonsense.However, the main source of inspiration and the basis for selecting organizational characteristicstobeassessedtodeterminetheorganizationalreadinesstoadopta practice consists of information gathered from agile consultants and coaches and thetechnicalliterature.Bothofthesesourcesarebasedonconsultantsexperiences. BesidesusingcommonsenseforsomeobviousAgilePractices,technicalliteratureis the second source for identifying organizational characteristics used in assessing thereadinessofanagilepracticeinSAMI.Someofthesesourcesinclude[71,57,67, 80,19,31,76].
Category of Assessment Area to be assessed Characteristic(s) to be assessed To determine: Assessment Method Sample Indicators OR1_M1, OR1_M2, OR1_M3, OR1_M4, OR1_M5, OR1_M14, OR1_M17, OR1_D1 OR1_D2, OR1_D3, OR1_D4, OR1_M9, OR1_M10, OR1_M6, OR1_M7, OR1_M8, OR1_M13 OR1_M11, OR1_D6, OR1_D7, OR1_D8, OR1_D9 OR1_D5 OR1_A1 OR1_M16, OR1_M18

Management Style

Whether or not a collaborative or a command-control relation exists between managers and subordinates. The management style is an indication of whether or not management trusts the developers and vice-versa.

Interviewing

Management Whether or not management is supportive of or resistive to having a collaborative environment Whether or not management can be open with customers and developers No politics and secrets Whether or not people are intimidated/afraid to give honest feedback and participation in the presence of their managers Whether or not the developers are willing to plan in a collaborative environment Whether or not the organization does basic planning for its projects Interviewing

People

Buy-In

Interviewing

Transparency

Interviewing

Power Distance Developers Buy-In

Interviewing

Interviewing Observation

Project Management

Planning

Existence

Table15.ReadinessAssessmentTable(RAT)forCollaborativePlanning

119

Oncetheassessorhasidentifiedtheappropriateorganizationalcharacteristics,they are then placed in a Readiness Assessment Table (RAT). Table 15 shows the RAT usedtoassessanorganizationsreadinesstoadoptcollaborativeplanning. The first column in the RAT highlights the generic organizational area to be assessed. The next two vertical columns specify the aspect of that area needing assessment.Thethirdcolumndesignatestheactualorganizationalcharacteristicto beassessed.Thegoalbehindtheassessmentofthischaracteristicisdefinedinthe fourth column titled to determine. The fifth column provides information on the methodusedtoconducttheassessment.Thelastcolumnprovidesareferencetothe actual indicators (presented earlier) that will be used to assess each particular organizationalcharacteristic. Appendix A provides the RATs for each agile practice along with all the indicators used to assess the Agile Practices in SAMI. This appendix also provides a detailed explanation on how to aggregate the different indicators together and calculate a finalnominalvalueforeachorganizationalcharacteristic.Thenextchapterprovides informationonhowtointerprettheresultsoftheassessments. As explained earlier in Section 3.2, the SAMI is tailorable. The five Agile Levels presented earlier are one instance of the SAMI. The next section provides a more detaileddiscussionofthetailorabilityoftheSAMI.

4.6 Tailorabilityofthe5LevelsofAgility
Although the practices are arranged in a certain way within each agile level, it is understandablethatothersmighthavedifferentpointsofviewabouttheplacement ofcertainAgilePractices.Thatisacceptableanddoesnotjeopardizethestructureof theagilemeasurementindex.Itmerelymeansthatitispossibletohavemorethan oneinstanceofthemeasurementindex.Thescienceofagilemeasurementindexesis

120

stillinitsinfancyandmuchmorerefinementisneededtoconsolidateorestablish relationsbetweenthedifferentinstancesoftheSidkyAgileMeasurementIndex. WhenmembersoftheagilecommunityviewedthefiveLevelsofAgility,alongwith alltheirpracticesandindicators,severalofitsleadersencouragedtheconsideration of factors that might lead to alternate instances of the five Levels of Agility. These factors are incorporating business values and reorganizing the practices based on experiential success. The two following subsections elaborate on these factors and thetailorabilityofthefiveAgileLevels

4.6.1 IncorporatingBusinessValues
Business values refer to the added benefit an organization realizes after adopting AgilePractices.Formostorganizations,theachievementofthesebusinessvaluesis the real incentive behind adopting agility. For example, common business values that organizations hope to realize from adopting Agile Practices comprise decreasing time to market or increasing product quality. Augustine [75] and Elssamadisy [38] have suggested the possibility of prioritizing the levels of agility accordingtothebusinessvaluesanorganizationhopestorealize.Thissuggestionis both valuable and beneficial to the growth the framework, because currently the five Levels of Agility are not associated with any business values; instead they are based on the qualities and values of agility. This relationship between agility and business values is parallel to that between the Agile Manifesto (focusing on agile values) and the Declaration of Interdependence (capturing the business values) [2] [1].

4.6.2 ReorganizingPracticesbasedonExperientialSuccess.
The agile coaches and consultants Cockburn [23], Cohn [28], and Wake [81], in additiontoothers,havesuggestedareorganizationoftheAgilePracticesbasedon experiential successes. That is, they advocate that the kind of projects and the experiencesgainedfrompreviousadoptioneffortscan,andshould,serveasabasis for formulating a better arrangement of the practices within the Agile Levels. For

121

example, Cohn has suggested that user stories be introduced in the first level of agility, because, from his experience, they enhance collaboration and communication between the stakeholders with regard to requirements. Others havesuggestedthat pairprogrammingbeincludedinthefirstlevel,becauseithelps to establish collaboration within teams. This inability to reach a consensus on the positionofAgilePracticesemphasizesanimportantfactorinprovidingguidancein an agile adoption effort: the adherence to Agile Principles, not the positions of the actual practices, is paramount when establishing the levels. The intention behind thelevelsofagilityistoprovideaframeworktoguidetheadoptionprocess,notto dictateit. The above rationalizations have lead to the conclusion that a tailorable measurement index is both desirable and beneficial. However, when tailoring or creatinganotherinstanceofanagilemeasurementindex,itisimportanttoobserve the following guidelines to ensure that the new measurement index has all the necessarycomponentsandavalidstructure: Ensure that multiple levels exist.Levelsareneededtoenumeratethedegreesof agility. Without levels, the power of the measurement index, when used in conductingcomparativemeasurementsoftheagility,isdiminished. The measurement index is based on practices and concepts. Agile Practices and concepts form the foundation of the agile measurement index. The extent to which Agile Practices and concepts can be adopted determines the agility of a process. Each practice or concept has indicators. When introducing a new agile practice (otherthanthe40identified)tothemeasurementindex,itisimportantthatthe practice has an associated set of valid and sufficient indicators. Without indicators,therearenomeansforconductingthisassessment. After the Agile Adoption Framework was developed, members of the agile community were asked to attend presentations about the framework and provide

122

theirfeedback.Thenextchapterprovidesadetailedanalysisoftheresultsgathered from the substantiation process of the Agile Adoption Framework by the agile community.

5. SubstantiatingtheAgileAdoptionFramework
This chapter presents data that substantiates the validity of the Agile Adoption Framework. It describes the substantiation process and the rationale behind it. It alsopresentsandanalyzesformalandinformalfeedbackcollectedfrominterviews, surveysandinformalconversationsfrommembersoftheagilecommunity. A longitudinal study is a common method for validating any new research framework.Inthiskindofstudy,oneormoreorganizationsuseanewframework, andaresearcher,orteamofresearchers,gatherdatathatallowsthemtoevaluate the process. Therefore, a longitudinal study is the ideal way to validate the Agile Adoption Framework. This is because observing and gathering data about the adoptionprocessandcomparingittoadoptionprocessesatorganizationsnotusing theframeworkgeneratestheempiricalevidenceneededtosubstantiatethevalidity oftheframework. However, the problem with this kind of study is that it takes extensive periods of time and requires several organizations to buy into the use of Agile Adoption Framework before enough empirical evidence can be gathered. The latter requirement intensifies the problem because many organizations are hesitant to employ a new framework with no evidence of its validity. Therefore, instead of a longitudinalstudy,gatheringfeedbackfromtheagilecommunityisthebestmeans ofsubstantiatingthevalidity(orgoodness)oftheframework.Thisfeedbackshould highlightthepositiveimpactandbenefitsoftheAgileAdoptionFramework,aswell as identify any potential problems. Moreover, substantiating the framework with feedbackfromtheagilecommunitycanenableafuturelongitudinalstudy,because 123

this type of positive feedback can increase the credibility of the framework in the eyesoftheorganizations,therebyincreasingtheirwillingnesstoparticipateinsuch astudy. The next section describes the approach used to gather feedback from the agile community.

5.1. TheSubstantiationApproach
Much thought and discussion was needed to identify an efficient and practical approach of gathering feedback from people in the agile industry, and who have littletimeintheirschedulestoinvestinsuchstudies.Thefollowingsectionspresent the procedures used to gather feedback as well as a discussion about the participantsandthesurveysused.

5.1.1 Procedureforgatheringfeedback
The initial idea for gathering agile industry feedback was to prepare a comprehensivesurveyoftheAgileAdoptionFrameworkandtomailittopeoplein the agile community. However, since these potential participants were not yet informed about the framework, this survey had to be supplemented with reading materialexplainingtheAgileAdoptionFramework.Compilinganexplanationofthe frameworktoaccompanythesurveyresultedina50pagedocument.Therealityis thatpeopleinagilecommunity,especiallyindustryleadersandexperts,wouldnot havethetimetoreada50pagedocumentandfilloutandreturnasurvey. Another idea, to visit and present the framework facetoface to selected clients from the agile community, grew out of the spirit of agility and its humancentric nature. Visiting people in person ensured having their attention for at least the duration of the visit. On average, those who agreed to participate dedicated 90 minutesoftheirtimeforavisit.Thenextchallengewastodevelopanapproachfor presentingtheframeworkandgatheringfeedbackwithintheallocatedtime.The12 124

page survey, (included in the Survey Collection document) originally designed to gather feedback about all aspects of the framework was not suitable for this new approach.Inordertoassurearesponseatthetimeofthevisit,thesurveyhadtobe shortandconcise.Otherwise,theparticipantswouldasktofillitoutandsenditin later, and might become too busy to find the time to do so. Therefore, again employing the principles of agility, the questions providing the most valuable answers for the substantiation process were chosen. The result was a twopage survey in which each page provided a series of questions designed to elicit a responsetoeachofthetwocomponentsoftheframework:thefivelevelsofagility andfourstageprocess.Analysisoftheanswerstothesurveyprovidedanoverview oftheagilecommunitysresponsetotheAgileAdoptionFramework. Onthedayofthepresentation,eachparticipantwasgiventhetwopagesurveyand a printoutof the slides, including a short narrative foreach slide.The participants generated interesting discussions because they were intrigued by the idea of the framework and the Sidky Agile Measurement Index (SAMI). These discussions servedastheinformalfeedbackusedaspartofthesubstantiationprocess.Afterthe presentation and the discussions, the participants filled out the survey. Although discussions and surveys completed at a time of presentation guaranteed adequate feedbacktovalidatetheagileframework,theparticipantsweregiventheoptionof completing the 12page survey. Those interested in participating in a more elaborate feedback process were given the detailed assessment package (the original 50 page document) along with a selfaddressed envelope to use to return the 12page survey. There was enough enthusiastic interest in providing further feedback about the framework that over 65% requested the detailed assessment package. However, as anticipated, only a small fraction of those actually sent back thelongsurvey. The next section presents the structure and content of the surveys and questions usedtogatherfeedbackfromtheparticipants.

125

5.1.2 OverviewofSurveyQuestionsandParticipants
SincetheAgileAdoptionFrameworkconsistsoftwocomponents,theSAMIandthe 4Stage process, feedback about each of the components was gathered separately for more accurate results. In the twopage survey, one page served for collecting data on the SAMI and the other for collecting data on the 4Stage process. The advantage of using what amounted to separate onepage surveys is to enable the competitiveanalysisoftheresultsbetweenthetwocomponentsoftheframework. Since the twopage surveys were intended for managers and consultants, whose timeandavailabilityislimited,therewere20quantitativequestionsbasedona5 pointLikertsummatedscale,from1stronglydisagreeto5stronglyagree,.There were also 4 qualitative openended questions that complemented the quantitative questions to provide broader and deeper coverage of the topic. These qualitative questions, coupled with the informal discussions, helped to elicit better feedback from the participants about the framework. Thirtyfive members of the agile community agreed to participate in the survey process. Of these, 27 filled out the twopage survey after the 60 minutes presentation of the Agile Adoption Framework.Ofthefivethataskedtocompletethesurveyandmailitin,onlyone didso.Thisconfirmstheimportanceofhavingparticipantsfilloutthesurveyatthe timeofthepresentation.The28completedsurveysyieldeda78%responserate. The12pagesurveywasofferedtoeachofthe35participants,butonly12tookitto filloutandreturnbymail.Ofthese,onlytwocompletedandreturnedthem.These two surveys represent 17% of the 12 participants and, including these two participants,7%ofthe28whofilledoutthetwopagesurvey.Whilethisresponse wasdisappointing,itwasexpected.Anonymouscopiesofthe28 twopagesurveys andthetwo12pagesurveyscanbefoundinAppendixB. Each of the next two subsections presents and discusses the questions used to gatherfeedbackoneachofthecomponentsoftheframework.

126

QuestionsabouttheSidkyAgileMeasurementIndex
Sinceitwouldhavebeendifficulttogatherfeedbackaboutthefivelevelsofagility, alongwiththeirprinciples,practicesandindicatorswithinanacceptabletimeframe, a twopage survey was designed to optimize time and response data. On the page devoted to the SAMI, the five questions measured, using the Likert scale, the comprehensiveness(using2questions),practicality,necessity andrelevanceofthe locationofthepracticeswithintheSAMI(see Table16).
LIKERTSCALEDQUESTIONS TODETERMINE Comprehensiveness Practicality Necessity Relevance QUESTION(S)USED The 5 agile levels are comprehensive enough to depict the various states and levels mostorganizationscouldbeatrelativetoagility? The5agilelevelsaredefinedinavalidandlogicalorder? One objective is to make sure that the agile levels are practical and can be used in industry. In light of this, to what extent would you agree that these agile levels can be used to classify, and/or aid in the transition of currently employed software developmentefforts? Theclassificationofagilityinto5agilelevelsaspresentedwouldbebeneficialtothe softwareengineeringindustry? Eachoftheagilelevelspresentedencompassesasetofagilepracticesandconcepts. To what extent would you agree that those practices and concepts are relevant and correctlyassignedtotheirrespectiveagilelevels?

OPENENDEDQUESTIONS Wouldyouadd,removeorredefineanyofthe5agilelevels?Ifso,pleaseexplainwhy. Doyouhaveanyfurthercommentsabouttheagilelevels?

Table16.TwoPageSurveyQuestionsabouttheSidkyAgileMeasurementIndex

Openended questions asked about the possible changes to the framework and promptedtheusertoprovidefurthercomments.Inparticular,itwasimportantto know whether the five levels sufficiently represented the different stages an organization passes through on its journey to agility, and whether they are in the rightorder.Theirsufficiencywasdeterminedbyassessingthe comprehensiveness of the levels. Since one objective of this research was to define a process to guide and assist coaches and organizations when adopting agility, determining the practicality of the levels was very important as this showed whether the research wasfulfillingitsobjectives.Similarly,thenecessityofanagilemeasurementindex, fromtheagilecommunity'sperspective,wasanimportantaspecttogatherfeedback

127

on.Thequestiononrelevancewasaskedtoascertaineachparticipantsopinionon therelevanceoftheagilepracticesassignedtoeachlevel.

Questionsaboutthe4StageProcess
Sincethe4Stageprocessisthemaincomponentoftheframework,anotherpageof thetwopagesurveywasdevotedtoit.Inthesurvey,15questionsmeasuredbythe Likert scale assessed understandability (using 6 questions), practicality, necessity, completeness (using 2 questions) and effectiveness (using 5 questions). The two openendedquestionsrepeatedthequestionsontheSAMI.

LIKERTSCALEDQUESTIONS TODETERMINE QUESTION(S)USED Overallobjectiveofthisprocessframework Discontinuingfactors Forthetopicslistedtohere designatethedegreetowhich 5agilelevels youagreethattheyare Projectlevelassessment understandable Organizationalassessment Gapanalysis Oneofourobjectivesistomakesurethattheprocessframeworkispractical andcanbeusedinindustry.Inlightofthistowhatextentwouldyouagree thatprocessframeworkwouldbepracticalandfeasibletouse? Theprocessframeworkisbeneficialtothesoftwareengineeringindustry? Allthenecessarycomponentsarepresentinthisprocessframeworkinorder toachieveitsoverallgoalofaidinganorganizationintheadoptionofagile developmentforitsvariousprojects? Thestepsandactivitiesintheprocessframeworkareorganizedinalogical andvalidsequenceinordertoachieveitsoverallgoalofanassistingagile adoption? Discontinuingfactors Towhatextentdoyouagreethateach ofthecomponentsinthisprocess frameworkisnecessaryandsufficient fortheframeworktoachieveits purpose? OPENENDEDQUESTIONS Wouldyouadd,removeorredefineanycomponentsofthisprocessframework?Ifso,pleaseexplainwhy. Doyouhaveanyadditionalcommentsabouttheprocessframework?

UNDERSTANDABILITY

PRACTICALITY NECESSITY

COMPLETENESS

5agilelevels Projectlevelassessment Organizationalassessment Gapanalysis

EFFECTIVENESS

Table17.TwopageSurveyQuestionsaboutthe4StageProcess

128

Since the primary objective of the 4Stage process is to provide guidance and assistance to organizations, it was necessary to assess the extent to which participantsunderstoodthestagesoftheprocessandtheirfunctionalities.Feedback about the practicality, necessity, and completeness of the 4Stage process was essential, just as it was to the SAMI, to establish whether the framework provided the services for which it was designed. To assess the effectiveness of the 4Stage process, the survey elicited the participants opinions on the necessity and sufficiency of each stage and the contribution of each to the fulfillment of the framework'soverallpurpose.Table17showsthequestionsusedontheonepage, withinthe2pagesurvey,devotedtothe4Stageprocess.

5.1.3 Participants
A total of35 members oftheagilecommunitytookpart inthesurvey.All of them provided informal feedback at the presentations and 27 filled out the twopage surveyonsiteafterthepresentation.Theremainingparticipantsaskedtomailtheir survey in at a later time. Only one of the aforementioned surveys was received, makingatotalof28responses,yieldinga78%overallresponserate. Theinformalfeedbackandthetwopagesurveysweregatheredinpersonfromthe participants at 10 onsite visits made in various parts of the United States. Some presentation sessions, usually those with the more busy and high profile consultants, were conducted oneonon. Other presentations were conducted in large agile consulting and development firms, where four or five individuals representingdifferentpositionsandexperiencesattended. Demographic information gathered from the participants included their personal information and their experience with agile development. The twopage survey included a question that asked participants for their position in their company or organization,anotherquestionaskingthemfortheiryearsofexperience,andthena section with four questions gauging their expertise on agility. These, too, used a

129

Likertscaleof1fornotfamiliarto7forexpert.Table18presentsthequestions usedinthesurveytogatherthisdemographicinformationfromeachparticipant.
OfficialPosition/Role: PleaserateyourfamiliaritywithAgilesoftware development
1
NOT FAMILIAR

YearsofExperience:
2

7
EXPERT

SOMEWHATFAMILIAR

Pleaserateyourhighestlevelofinvolvementin developmenteffortsthatusedAgilepractices

1
NONE

4
PARTICIPANT

7
LEADER

Howfrequentlyhaveyouaidedentitiesin adoptingAgilepractices Pleaserateyourleveloffamiliaritywith generalprocessassessmentand/orprocess improvement

1
NEVER

4
OCCASIONALLY

7
CONSTANTL Y

1
NONE

4
PARTICIPANT

7
LEADER

Table18.ParticipantInformationonRolesandAgileExperience

Animportantfactorwhendesigningthissubstantiationeffortwastomakesurethat theparticipantsrepresentedasamplespectrumoftheentireagilecommunitywith respecttodifferentpositionsanddifferentlevelsofexperiences.Whilerecognizing thatdiversitywasimportant,itwasalsoimperativethatmajorityoftheparticipants be agile coaches and consultants, since these would be the primary users of this framework. Whenclassifyingthe28whorespondedtothetwopagesurveybasedontheirroles andpositions,theparticipantsfellintothreecategories: Developers: Eight of the participants (28%) were junior or senior software engineers,architects,analystsordevelopers Management: Eight of the participants (28%) were directors, managers or marketingpersonnel

130

Agile coaches/consultants: Fourteen of the participants (44%) were agile consultants,agilecoaches,seniorXPcoaches,chiefscientistsorCTO's

Based on their years of experience, the participants were also divided into three groups: Table 19 shows the number of participants by role and experience and highlights therelationbetweenthetwocategories. 12 Years: Eleven of the participants (39%) had between 12 years of experiencewithagile 35 Years: Nine of the participants (33%) had between 35 years of experiencewithagile 612 Years: Eight of the participants (28%) had between 612 years of experiencewithagile

Groups AgileCoaches Management Developers
Total

12 Years
2 3 6

35 Years
5 2 2

612 Years
5 3 0

11

Total 12 8 8 28

Table19.CategorizationofParticipantsbytheirRolesandYearsofExperience Acoupleofinterestingobservationsconcerningthegroupingoftheparticipantsare asfollows: Mostoftheagilecoacheshave3ormoreyearsofexperience Mostofthedevelopershave12yearsofexperience Managementisdistributedequallyintermsofyearsofexperience

131

Also, of the 28 participants, five people made up a special group that was highly experienced with process assessment and process improvement efforts, and have ledagileadoptioneffortsforoversixyears.Sincethisgrouprepresentstheexperts and leaders of the agile adoption community, their participation was important to thesuccessofthisvalidationeffort.Theypossesssubstantialknowledgeaboutagile adoption and are, therefore, better able to assess the overall performance of the Agile Adoption Framework. The remaining participants are also important to the validation effort, because they assess how the framework meets their need for guidance throughout the adoption process. As a total group, the participants representtherangeofexperienceusuallyencounteredasorganizationsembarkon thejourneytoagility. Theprevioussectionshaveprovidedanoutlineofthethreemaincomponentsofthe study,theprocedure,thequestions,andtheparticipants.Thenextsectionpresents ananalysisofthequantitativefeedbackgatheredfromtheagilecommunity.

5.2. QuantitativeFeedback
Duetothenatureofthefeedbacksessionsandtheavailabilityofmembersfromthe agile community, the number of participants is relatively small for complex statistical analysis. Therefore, the results presented in this section are based on simple statistical descriptions, data trends and comparisons of percentages. The results related to each of the components of the framework are presented separately,startingwiththeSAMI.

5.2.1 ResultsconcerningtheSidkyAgileMeasurementIndex(SAMI)
Figure 33 depicts the overall results of the one page of the twopage survey assessingtheSAMI.Thefigureshowsthatover75%,representingamajorityofall

132

therespondents,eitherbelieveorstronglybelievethattheSAMIiscomprehensive, practical,andnecessary.However,theresponsetothequestionontherelevanceof theagilepracticeswithintheagilelevelsshowstheagreementratedropstoalittle below 50%, while the rate of disagreement rises to approximately 37%; the rest neitheragreenordisagree.Figure34showsabreakdownoftheoveralldatabythe experienceoftheparticipantsforfurtheranalysisofthedataforeachaspectofthe levelsbeingassessed.Figure35showsabreakdownofthedatabyrole(developers, managementandcoaches/consultants).

All Participants
100%

80%

60%

40%

20%

0%
Comprehensiveness Practicality Necessity Relevance

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree Strongly Disagree

Figure33.OverallresultsfortheSAMI

133


1-2 Years of Experience (11 Participants)
100%

80%

60%

(a)

40%

20%

0% Comprehensiveness Practicality Necessity Relevance

3-5 Years of Experience (9 Participants)

100%

80%

60%

40%

(b)
Comprehensiveness Practicality Necessity Relevance

20%

0%

6-12 Years of Experience (8 Participants)

100%

80%

60%

40%

(c)
Comprehensiveness Practicality Necessity Relevance

20%

0%

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree

Strongly Disagree

Figure34.ResultsoftheSAMICategorizedbyYearsofExperience

134

Developers (8 Participants)
100%

80%

60%

40%

(a)
Comprehensiveness Practicality Necessity Relevance

20%

0%

Management / Administrative (8 Participants)

100%

80%

60%

40%

(b)
Comprehensiveness Practicality Necessity Relevance

20%

0%

Agile Coaches/Consultants (12 Participants)

100%

80%

60%

40%

(c)
Comprehensiveness Practicality Necessity Relevance

20%

0%

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree

Strongly Disagree

Figure35.ResultsoftheSAMICategorizedbyRoles

135

Comprehensiveness
As Figure 33 shows, 53.5% of the participants strongly agreed, 21.5% slightly agreed,21.5%neitheragreednordisagreed,andonly3.5%slightlydisagreedthat the 5 levels are comprehensive enough to reflect the various steps most organizationsgothroughtoreachagility.Theoverallmeanforalltheparticipants was4.05(slightlyagree),withastandarddeviationof0.89. AsFigure34shows,whencategorizedbyyearsofexperience,theresultsexhibita trend: both sides of the experience spectrum were more in agreement than the middle.Participantswith12years(Figure34a)andwith612years(Figure34c)of experiencehaveaclosebyagreementrates(90%and75%respectively)aboutthe comprehensiveness ofthe levels,probably because thegroup with less experience (90%,Figure34a)didnothaveenoughexperiencetocomparethelevelswithreal life experiences. At the opposite end of the spectrum, participants with extensive experience (75%, Figure 34c) have been involved with many projects and have agreedthatthelevelsarecomprehensiveenoughtocapturethestepsorganizations gothroughtoreachagility.Representingthemiddlegroundareparticipantswith3 5 years of experience (Figure 34b) who were 45% neutral and 55% in agreement with the comprehensiveness of the levels. The closeness of agreement between participantswith12yearsand612yearsofexperienceissignificantbecausethe former group represents the need for guidance to agility and the latter group has the experience to judge adequacy of the completeness of the Agile Adoption Framework AsFigure35shows,whencategorizedbyrole,theresultsexhibitadifferenttrendin that 75% of developers, management and coaches agreed on the adequacy of the comprehensivenessofthefivelevelsofagility.Usuallydevelopers(Figure35a)are not involved with the overall picture of adopting agility in organizations and the levelsitgoesthrough,andhencemighthaveagreedbecauseof inexperience(they have nothing to compare it to). However, having 75% of the agile

136

coaches/consultants(Figure35c)andmanagers(Figure35b)agreewiththelevels comprehensiveness is significant because the nature of their work makes them familiarwiththeagileadoptionprocess. In summary, the survey participants perceived the SAMI as sufficient and comprehensive enough to represent the different stages an organization goes through to achieve agility. The positive feedback on the comprehensiveness of the levelsofagilityiscrucialinthesubstantiationoftheoverallframework,becausean essential part of the 4Stage process (Stages 2 and 3) relies on the structure and priorityofthelevelsofagilityindeterminingthetargetlevelofagilitythatprojects canadopt,andthereadinessoftheorganizationforadoption. Therefore,whenthe agile community agrees that the levels represent the right steps and order of an organizationsmovetowardsagility,thevalidityofthewholeframeworkincreases.

Practicality
Out of all the participants, Figure 33 shows 39.3% strongly agreed, while 42.9% slightly agreed that the SAMI is practical and can be used during agile adoption efforts.Oftherest,7.1%neitheragreednordisagreedand10.7%slightlydisagreed. Theoverallmeanis4.1(slightlyagree),withastandarddeviationof0.95. AsallthepartsofFigure34show,yearsofexperiencedidnotimpactthepracticality results. At 90% for 12 years of experience, 77% for 35 years, and 91% for 612 years,thepercentagesofagreementwerealmostthesameregardlessofthelevelof experience. However, when classified by roles, the results did vary. While 39% of thedevelopers(Figure35a)stronglyagreedonthepracticalityoftheAgileAdoption Framework,almost30%weredividedbetweenneutralorslightlydisagreeing.This canbeattributedtothefactthatdevelopersusuallydonotusethelevelsofagility duringadoptionefforts.Notasinglemanagerstronglyagreedwiththepracticality ofthelevels,yetalmost80%ofthem(Figure35b)slightlyagreedtoit.Thisreflects

137

thewaymanagersareinvolvedintheprocess.Theyareusuallytheoneswhohave tosellthesetechniquestotheclients,anditishardtosellsomethingwithouthaving full confidence in it and having seen it working. However, the managers see the potentialoftheframework,asthe80%inslightagreementindicates(Figure35b), but are still skeptical. The agile coaches are more than 90% (Figure 35c) in agreementthatthelevelsarepracticalandcanbeusedduringagileadoption.Unlike developers, agile coaches and consultants usually use the levels of agility during adoption efforts. Therefore it was not surprising that they exhibited more confidence in the practicality of the framework due to their handson experience andtheirunderstandingoftheusefulnessoftheagilelevelstotheadoptionprocess.

Necessity
As Figure33 shows, 35.7% ofall the participants strongly agreed that the SAMI is necessary, and 39.3% slightly agreed, while 7.1% were neutral and 17.9% slightly disagreed. The overall mean is 3.9 (slightly agree), with a standard deviation of 1.08. The agreement levels for necessity are slightly lower than those for comprehensiveness and practicality because of the developers responses to this question. Although approximately 50% agreed to the necessity of the levels of agility,thehighlevelofdisagreementoccurred,becausedevelopershavenoneedor useforanagilemeasurementindexintheirdaytodaywork.Theyarenotinvolved with actual agile adoption efforts. However, high level of agreement (over 75%) from management (Figure 35b) and coaches (Figure 35c) reflects the need for an agilemeasurementindexwithintheagilecommunity.

Relevance
Figure33illustratesthatonly7.1%oftheparticipantsstronglyagreedthattheagile practices were assigned to relevant agile levels. However, 39.2% slightly agreed, while 17.9% neither agreed or disagreed and another 17.9% slightly disagreed. 138

However,forthefirsttime,17.9%oftheparticipantsstronglydisagreed.Themean fortherelevancewas3.0(neitheragreenordisagree),withastandarddeviationof 1.27. The low agreement rate for relevance was expected and accounted for in the framework. The overall results of the comprehensiveness, practicality, and necessity categories seen in the one page of the twopage survey devoted to the SAMIhighlightstheagreementoftheagilecommunityontheirutility.However,the agreementrateismuchlowerwhenitcomestothedetailsofthelevelsofagilityand where to place each agile practice or concept, because some of the participants lacked actual experience in the journey to agility and those with experience, especiallyconsultantsandcoaches,havedevelopedtheirownmethodsformaking thetransition.Theproblemisthatthesemethodsmorethanoftenarebasedonthe means and structure of a specific organization, and therefore, are not always applicabletootherorganizations. Thefivelevelsofagilitysolvethisproblembecauseofitsmaincontributiontothe agileadoptionprocesstherepeatablestructureandguidancethatcanbeusedfor agile adoption effort. Agile coaches can tailor the levels of agility and place agile practices in different levels to reflect their experience and approaches to agile adoption.Thelowagreementrateonthedetailsofthelevelsdoesnotjeopardizethe validityoftheframework.Itsimplytestifiestothefactthateachpersonintheagile community has his or her own opinions concerning when and why to introduce differentagilepractices.Nevertheless,theresultsfromthetwopagesurveyonthe other aspects show that there is in need for structure and guidance on how to organize these agile practices and concepts; and this is exactly what the SAMI provides.

139

TheExpertsResponsetotheSidkyAgileMeasurementIndex
Theoverallresults,andtheclarificationsbyrolesandyearsofexperienceraisethe concern of what the experts had to say about the agile adoption framework. This section,therefore,presentsonlytheresultsobtainedfromthespecialgroupofagile expertsdefinedearlierinthischapter.

Over 6 Years Experience Leading Agile Adoption

100% 80% 60% 40% 20% 0%
Comprehensiveness Practicality Necessity Relevance

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree Strongly Disagree

Figure36.ResultsoftheAgileMeasurementIndexfromagileexperts

As Figure 36 shows, 80% of these experts strongly agreed with the comprehensivenessoftheagilelevels,whiletheremaining20%neitheragreednor disagreed. They all agreed to the practicality of the levels of agility, with 80% indicatingstrongsupport.Also,80%agreedtothenecessityofthelevelsofagility and20%slightlydisagreed.Asfortherelevance,60%agreedthatthepracticesare more or less in the right levels and 20% chose to remain neutral until they have studiedthe5levelsmorethoroughly.Theremaining20%stronglydisagreed.

140

Overall,theagilecommunityhasacceptedtheSAMI.Thisisimportantbecausethey are the foundation used by the 4Stage process. The next section presents the feedbackobtainedfromthesecondpage,ofthetwopagesurvey,whichisdevoted togatheringfeedbackaboutthe4Stageprocess.

5.2.2 Resultsconcerningthe4StageProcess
AsFigure37shows,themajorityofalltheparticipants(approximately80%)either agreed or strongly agreed with all five aspects of the 4Stage process. What is encouragingisthatnotasingleparticipantstronglydisagreedwithanyaspectofthe 4Stageprocess,andonlyoneparticipantslightlydisagreedwithitscompleteness. Figure 38 provides a breakdown of the participants by years of experience and Figure39byrole.Thenextsectionspresentananalysisofthesegroupings.

All Participants
100%

80%

60%

40%

20%

0%
Understandability Practicality Necessity Completeness Effectiveness

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree Strongly Disagree

Figure37.Overallresultsforthe4StageProcess

141

1-2 Years of Experience (11 Participants)

100% 80% 60% 40% 20% 0%
Understandability Practicality Necessity Completeness Effectiveness

(a)

3-5 Years of Experience (9 Participants)

100% 80% 60% 40% 20% 0%
Understandability Practicality Necessity Completeness Effectiveness

(b)

6-12 Years of Experience (8 Participants)

100% 80% 60% 40% 20% 0%
Understandability Practicality Necessity Completeness Effectiveness

(c)

Strongly Agree

Slightly Agree

Neither Agree nor Disagree

Slightly Disagree

Strongly Disagree

Figure38.Resultsofthe4Stageprocesscategorizedbyexperience

142

Developers (8 Participants)
100% 80% 60% 40% 20% 0%
Understandability Practicality Necessity Completeness Effectiveness

(a)

Management / Administrative (8 Participants)

100%

80%

60%

(b)
Understandability Practicality Necessity Completeness Effectiveness

40%

20%

0%

Agile Coaches/Consultants (12 Participants)

100% 80% 60% 40% 20% 0%
Understandability Practicality Necessity Completeness Effectiveness

(c)

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree Strongly Disagree

Figure39.Resultsofthe4Stageprocesscategorizedbyrole 143

Understandability
AsFigure37shows,everyoneunderstoodallthestagesoftheprocess,with57.2% of the participants strongly agreeing to the understandability of the four stages of the process, and 42.8% slightly agreeing to it. The overall mean for all the participants is 4.48 (between slightly and strongly agreeing), with a very low standarddeviationof0.49. Whencategorizedbyyearsofexperience,asFigure38shows,atrendemerged:the moreexperiencedtheparticipantwas,themorestronglyheorsheagreedthatthe processisunderstandable.AsFigure39shows,theresultscategorizedbyrolealso reflectthistrend.Sincethe4Stageprocessprovidesguidanceaboutagileadoption efforts, it is logical, and expected, that the agile coaches would understand the processmorethanthedevelopersandmanagers.

Practicality
While none of the participants disagreed about the practicality of the 4Stage process, as Figure 37 shows, the strong consensus seen for understandability diminished, with 35.7% of the participants strongly agreeing, 53.6% slightly agreeing and 10.7% remaining neutral. The overall mean is 4.25 (a little above slightlyagree),withastandarddeviationof0.64. Interestingly, the results were almost the same regardless of the years of experience, as all parts of Figure 38 show. However, when classified by roles, the resultsdidvary.Thedevelopersandmanagerswereslightlymorehesitanttoagree tothepracticalityofthe4Stageprocess.ThisobservationisseeninFigure39aand Figure 39b, only 25% the developers and 12.5% of the managers strongly agreed while 62.5% of the developers and 75% of the managers slightly agreed to the stages practicality. The agile coaches and consultants, on the other hand, were muchstrongerintheiragreementtoitspracticality.Figure39cshowsthat58%of

144

the coaches strongly agreed while only 34% of the slightly agreed. One possible reason behind this is that since the agile coaches are the ones involved with the adoptionprocess,theyhaveagreaterabilitythanthemanagersanddevelopersto grasp the practicality of actually using the 4Stage process to guide the adoption efforts.

Necessity
Returning to Figure 37, 42.9% of all participants strongly agreed, while 39.3% slightlyagreedthatagilecommunityneedsthe4Stageprocess and17.8%neither agreed nor disagreed. The overall mean is 4.25 (a little above slightly agree), the sameasthepracticalitymean,butthestandarddeviationof0.75isalittlehigher. Theagreementlevelsfornecessityareslightlylowerthanforpracticality.Likethe drop in agreement seen for the agile levels, this drop reflects the developers responses. The developers (see Figure 39a) were hesitant to make up their minds about the necessity of the 4Stage process (37.5% neither agree nor disagree). Their hesitation can be attributed to their noninvolvement with agile adoption effortsand,therefore,notdeemingastructuredapproachnecessary.Thehighlevel of agreement from management seen in Figure 39b (87.5%) and from coaches (91.6%) seen in Figure 39c, the two groups most often involved in the actual adoptionefforts,reflectstheneedforastructuredapproachtoagileadoption.

Completeness
As Figure 37 shows, the percentage of participants who strongly agreed all the necessary components to guide an adoption effort are within the 4Stage process wasonly28.6%,while46.4%slightlyagreed,21.4%neitheragreednordisagreed, and3.6percentslightlydisagreed.Themeanforthecompletenesswas3.8(alittle belowslightlyagree),withastandarddeviationof0.78.

145

The completeness aspect of the 4Stage process had the lowest agreement percentage of all the aspects of the process. Contributing to this was the actual process used to gather the feedback. The 90 minutes allotted for presenting the whole framework to the participants, subsequent discussions, and the survey was simplynotenoughtimeforsomeonetograsptheessenceofthe wholeframework and attest to its completeness without actually sitting down and going over all its componentscarefully.Moreover,thepresentationshowntotheparticipantswason amacrolevelviewdueagaintotimeconstraints.Theparticipantsthatreturnedthe surveysatalatertimevalidatetheseobservations.Thisisbecausewithtimetolook over the framework in detail, both strongly agreed that the 4Stage process is complete.

Effectiveness
InFigure37,italsoshowsthattheagilecommunitygaveapositiveresponsetoeach ofthecomponentsof4Stagewithregardstoitseffectiveness(i.e.achievingwhatit wasdesignedfor).Fiftypercent(50%)ofthemstronglyagreed,and42.9%slightly agreed, while only 7.1% were neutral. The overall mean is 4.43 (between slightly andstronglyagreeing),withastandarddeviationof0.63. Although all parts of Figure 38 and Figure 39 show no strongly defined pattern emergingfortheeffectivenessofthe4Stageprocess,ingeneraltheresultssupport a positive perception of its effectiveness, with most of the participants, no matter their role or experience level, expressed agreement. Only a few were neutral, neither agree nor disagree, while 75% of the most experienced participants (see Figure38c)showedstrongagreement

TheExpertsResponsetothe4StageProcess
To conclude the analysis of the quantitative results, this section presents the feedbackonthe4Stageprocessgatheredfromtheagileexperts. 146

 As Figure 40 shows, what is truly noteworthy about the results gathered from surveying the experts is that they agreed 100% to all the aspects of the process. Theseresultsunderscoretheperceivedutilityoftheagileadoptionframeworkand substantiateitsvalidity.

Over 6 Years Experience Leading Agile Adoption

100% 80% 60% 40% 20% 0%
Understandability Practicality Necessity Completeness Effectiveness

Strongly Agree Slightly Agree Neither Agree nor Disagree Slightly Disagree Strongly Disagree

Figure40.Resultsforthe4StageprocessfromAgileExperts

Thenextsectionprovidesadiscussionofthequalitativefeedbackgatheredfromthe agilecommunity.

5.3. Qualitativefeedback
Despite the fact that only 78% of the participants (28 people) contributed to the quantitative feedback (via the 2page survey), all 35 participants provided qualitativefeedback.Thethreesourcesforthequalitativefeedbackarethe:

147

openendedsurveyquestionsfromthe2pagesurvey informaldiscussionsthatoccurredduringthefeedbacksessions 12pagesurveysthatwerereturned

Since during the presentation the participants expressed their many of their concerns through the informal discussions, many of them left the openended questions empty as the issues had already been discussed earlier. Consequently, reporting the results of the openended questions separately is not possible. We combined all the qualitative feedback together, whether they were written or discussed,andgroupedthemcouldtogetherbasedonthefeedbacktopic. The results of the 12page survey are included in the qualitative feedback section becauseonlytwo12pagesurveyswerereturnedmakingitimpracticaltoconduct any statistical analysis for the quantitative aspect of the results. Therefore, all the feedbackobtainedthroughthesesurveysisincludedinthissection. Due to the general consensus of the participants on the validity of the 4Stage process, and the qualitative feedback on this component of the framework tended nottoraiseproblemsthatneededtobeaddressed.Therefore,mostofwhatfollows focuses on the SAMI and is divided based on the different topics of the qualitative feedback.

5.3.1 TheSidkyAgileMeasurementIndex
Mostofthediscussionsrevolvedaroundtheagilemeasurementindex.Therewere many beneficial insights and spirited discussions about the notion of agile levels. Eachofthefollowingsubsectionspresentsthefeedbackrelatedtooneaspectofthe agilemeasurementindex.

148

TheAgileLevelsandtheCMM
While many participants favored the notion of agile levels, and an agile measurementindex,otherparticipantsexpressedconcernassoonastheyreadthe wordsagilelevelsandfoundoutthattherearefive.ImmediatelytheCMMcameto theirminds.SincemanyparticipantsapparentlydidnotliketheCMM,therewasan immediatenegativereactiontowardsthelevelsofagility.Someof theparticipants believed that the CMM causes more harm than benefit to development processes, and that it has become a mere certification process, which is hard to maintain in reality.However,whenthefocusofthediscussionshiftedfromacomparisonofthe agilelevelsandtheCMMtothefunctionalityoftheagilelevels,andthefactthatthey areassignedtoindividualprojectsandnotthewholeorganization,theparticipants viewedtheagilelevelsmorefavorably.

TheBusinessValue
Duringtheseinformalfeedbackdiscussions,severalparticipantsmentionedthatthe agile levels should be linked, or related to, the business value realized when the level is attained. This point has been mentioned and addressed earlier in the discussionofthetailorabilityoftheSAMI.(SeeChapter4) Another beneficial suggestion related to thebusiness value and agile levels was to havetheagilelevelspopulatedwithdifferentagilepractices basedonthebusiness valuetheorganizationwishestoattain.Forexample,ifthebusinessobjectiveofan organization is to have a shorter timetomarket, then the SAMI would have the same levels and principles, but all the practices and concepts would be related to achieving a shorter timetomarket. This is basically adding a third dimension, the businessvalueorobjective,totheSAMI.

149

 TheTerminologyoftheAgileLevels
DuetotheCMM,thephraseagilelevelshadanegativeconnotationforsomeofthe participants. They agreed with the functionality in the purpose of the agile levels, but the name was annoying to them. They suggested replacing agile levels with, agiledimensions,agilesets,oragileregions. Otherparticipantsacceptedthetermlevelsbutwantedtochangethenamesofthe actuallevels.Theywantedthelevelnamestoreflectthetypeofthepracticeswithin the level instead of the value achieved when adopting the practices within a level. Therefore, they suggested that the Evolutionary Level be named the Timing Level, because all the practices within the level focused, in one way or another, on the frequencyofiterationsandreleases.Theyalsosuggestedthatthe Effective Level be named the Engineering Level, and that the Encompassing Level be named the EnvironmentLevel.Incontrast,othersexplicitlypraisedthenamingofthelevels. This feedback concerning the names of the agile levels was carefully analyzed and discussed. The result was that one of the names of the agile levels was changed. Level 5, which was originally named Optimal, was changed to Encompassing, becauseencompassingseemedtobetterreflecttheessenceofthelevel,whichisto foster a vibrant environment to sustain, foster, and spread agility in the whole organization. Also, one of the coauthors of the agile manifesto recommended the change of a single word. Originally, the second agile principle plan and deliver software frequently,waswrittenasplantodeliversoftwarefrequently.Thereisasubtle, but fundamental difference between the two statements. Planning to deliver software does not necessarily ensure the delivery of the software. Therefore, the more appropriate wording for the principle was plan and deliver software frequently.

150

 OrganizationofPractices
Of course the organization of the agile practices within the agile levels provoked considerable discussion. Some participants just had gut feelings, based on their experiences, that the practices needed to be shuffled around. Others argued that practicesfound inthehigher levelsneededto bein thelower levels, because they createdtheconditionsthatmadeotherpracticeseasiertoadopt.Theseareissuesof tailorability,andtheframeworkprovidesthestructureandguidancetopopulatethe levels of agility, but does not dictate the organization of the practices within the levels. As a result of all the conversations and discussions about reorganizing the agile practices,thelocationofonepractice, reflect and tune the process,wasmovedfrom level 4 to level 1. The decision to make this change is an acknowledgment that reflectingandtuningtheprocessformoneofthecornerstoneconceptsinagilityand contributetoenhancingcommunicationandcollaborationwithintheprojectteam.

Animportantconcern:thetailorabilityoftheSAMI
One of the leaders in agility had a deeper concern with the SAMI as presented. Although he did not fundamentally disagree with the positioning of the practices within the levels (of course he had his preferences) and understood the flexibility givenbytheframeworktoreorganizethepractices,neverthelesshewasconcerned thatthe5LevelsofAgility(alongwiththeirpracticesandindicators)arecurrently the only instance of the SAMI. He was afraid that beginners within the agile communitymightlookatthefivelevels,alongwiththecurrentorganizationofagile practiceswithinthem,andthinkthatthatistheonlywayandonlyarrangementfor agilepracticeswithinagilelevels.Thisisavalidandimportantconcernthatallthe publications have addressed by stressing the fact that the SAMI presented in this

151

research is only one instance of the SAMI, which is tailorable, and that other instancescanexist.

5.3.2 TheDiscontinuingFactors(Stage1)
Another topic in several of the feedback sessions was that of the discontinuing factors.Thetwoissuesdiscussed weretheappropriateness oftwo factors and the namingofthefactors.Thefollowingtwosubsectionselaborateontheseissues.

FactorAppropriateness
The first discontinuing factor identified in the agile adoption framework is the Inappropriate Need for Agility.Originally,thisfactorreferredtothesituationwhere anorganizationdeliveredproductsontimeandwithinbudget,therateofchangeof requirements in the project was low, and there was no need for short timeto market values. In other words, adopting the agile practices would add no value to the software development process, because there were no problems. The survey participant,whowasacoauthoroftheAgileManifesto,remarkedthatmanypeople, including himself initially, believed that in such situations there was no need for adopting agility. However, he then said that he recently discovered many organizations,includingoneshehadworkedwith,wereinsuch situationsandstill adopted agility. He concluded that people adopt agility not only when there is a problemwiththeircurrentprocess,butjusttooptimizetheirdevelopmentprocess and increase efficiency. Essentially this relates to the notion of incorporating business value, because internal optimization is a business value many organizations seek. Therefore, with this new piece of information, the first discontinuingfactorwasredefinedtoincludethenewrealizations. Originallytheframeworkhadfourdiscontinuingfactors.Thefourthdiscontinuing factor was if the project developed was either mission or lifecritical. The participants agreed that a couple of years ago there was still a lot of speculation

152

aboutwhetheragilitywassuitableformissionandlifecriticalsystems.However,in light of the current status of agile software development, the majority of the participants disagreed that developing mission and lifecritical systems would be discontinuingfactor.Theseopinionswerebasedonthefactthatmanyofthemhad personally been involved with projects developing such systems that used agile practices.

TheTitlesoftheDiscontinuingFactors
Thediscussionsandsurveysalsohighlightedtheneedformoreexpressivetitlesof discontinuing factors. Originally, the first discontinuingfactor wastitled No Value Added. Although, most participants did not disagree with this title, it did confuse them.Afterfurtherexplanationofthisdiscontinuingfactor, participantssuggested bettertitlesthatwouldbemoreexpressive.Afterdueconsideration,thetitleofthe firstdiscontinuingfactorwaschangedtoInappropriateNeedforAgility. Asmallnumberoftheparticipants,allfromthesameorganization,suggestedanew set of titles for all the discontinuing factors, while adding some of their own. The discontinuingfactorstheysuggestedwere: Noneed Nosupport Nomoney Nopermission NoCourage

5.3.3 OtherComments
Several other miscellaneous comments pertaining to different areas of the frameworkaregroupedtogetherinthissection.Eachofthefollowingsubsections presentsoneofthesecomments

153

TheValidityofanAgilePractice
The feedback on one agile practice, the use of true object oriented design and construction highlighted a disagreement among agile practitioners. While some participantsbelievedthatmostofthedevelopmentdoneinagilityisbasedonobject oriented design and construction, other participants felt very strongly that this is notapracticethatisrelatedtoagility.Theyarguedconvincinglythatagilesoftware developmentcanbeusedwithotherdesignandconstructionparadigms.Asaresult of these discussions, and further research, the decision was made to remove this agilepractice.

WhyaTargetlevelofAgility
A small number of the participants expressed concern that determining a target level for a project would limit and restrict that projects agile potential. For example,eveniftheprojectisincapableofadoptingallthepracticesinlevel3,why discourage it from the rest of the practices of levels 4 and 5. The answer to this concerngoesbacktothedesignofmeasurementindex.Eachagileleveliscomposed ofacertainsetofagilepracticesthatworkinsynergytointroduceaparticularagile valueintothedevelopmentprocess.Thepracticesareorganizedandlaidoutbased on the agile principles. Within each principle, the practices and concepts build on and complement each other. If we consider the agile principles as the pillars that holduptheagilityintheorganization,thenwholebuilding(developmentprocess)is onlyasstrongasitsweakestpillar.Similarly,ifalltheagilepracticesfromlevel1to 5foralltheagileprinciplesexceptoneareadopted,thenoveralltheprojectisnot fullyagile.Itisonlyasagileasitsweakestprinciple. Therefore, when factors outside the control of the organization constrain the highest level of agility for a project, the focus should be on resolving the constrainingfactorssothatthealltheprinciplesofagilitycanrisetohigherlevelsof agility.Thisbroaderapproachisbetterandmorebeneficialthanfocusingonways

154

toadoptagilepracticesinhigherlevels,becauseconstrainingfactorswillkeepone of the principles at a lower level of agility than the rest, thereby weakening the overallagilityoftheproject.

OverallTerminology
Thethreerolesfrequentlymentionedintheframeworkaredevelopers,managers, andcustomers.Manyoftheparticipantswantedabetterandclearerdefinitionof theserolesandseveralevensuggesteddifferentdefinitionsfortheseroles.One participantdefinedtherolesusinganinterestingmetaphorworthsharing: developersarethegeekswhomakedecisionsoftechnicalvalue,customersarethe suitswhomakedecisionsofbusinessvalue,andmanagersaredoctorswhotakecare ofthehealthoftheentirecommunity. Thischapterhaspresentedandanalyzedthefeedbackgatheredfromtheindustrial agilecommunityusedtosubstantiatethevalidityoftheagileadoptionframework. Overall, based on the quantitative results obtained from 28 surveys, the feedback was positive and shows the communities in agreement as to the utility of this framework. The qualitative feedback has focused on highlighting the constructive criticismreceivedfromindustryandexplaininghowithasbeenaccommodated.

155

6. Conclusion
The creation of the Agile Adoption Framework, presented in this dissertation, is motivated by the absence of a structured approach capable of providing organizations with guidance on how to adopt agile practices. Organizations are seekingmethodstohelpdeterminewhethertheyarereadyforthechangetoagility and to identify the right agile practices to adopt. In addition, organizations are interestedinlearningmoreaboutthepreparationsnecessaryforandthepotential difficultiesintheirjourneytowardagility. The Agile Adoption Framework is a first step toward addressing the need for providing organizations with a structured and repeatable approach to guide and assistthemintheirjourneytowardagility.TheAgileAdoptionFrameworkprovides organizationswithguidancethroughastructuredandwelldefined4StageProcess. Whilethe4StageProcessisthekeycomponentoftheframework,itreliesheavily on another important component in the framework, the Sidky Agile Measurement Index(SAMI).TheSAMIisthemeasurementindexthatsupports themeasuringof the agile potential of projects and organizations, using the notion of Agile Levels. Each Agile Level consists of a set of Agile Practices categorized according to the Agile Principle they manifest. Moreover, a set of Indicators accompany each Agile Practice. These indicators are used to assess the organizations readiness to adopt theAgilePracticetheyareassociatedwith. The first stage (Identifying Discounting Factors) within the 4Stage Process concentrates on conducting a preadoption assessment to determine whether the organization is ready for the move to agility or not. The preadoption assessment focuses on determining the degree of presence of discontinuing factors. When discontinuingfactorsarefound,liketheabsenceofexecutivesupport,orthelackof sufficientfunds,thentheagileadoptionprocessissuspendeduntilthediscontinuing factorsareremoved.

156

 By utilizing the SAMI, the secondstage (Project Level Assessment) determines the agile potential for a specific project. The agile potential of a project is the highest level of agility the project can reach. Project agility is determined by assessing factors needed for the adoption of agile practices which the organization has no control over changing. On the other hand, stage 3 (Organizational Readiness Assessment)assessesthedegreetowhichtheorganizationisreadytosupportthe project in reaching its agile potential. This is determined by assessing the organizations readiness to adopt each agile practice in the projects target agile level, as defined by the SAMI. The fourth stage (Reconciliation) of the 4Stage Process reconciles any differences between the projects agile target level and the organizationsreadinesslevel.Theresultisarecommendedsetofagilepracticesfor theorganizationtoadopt. Both components of the Agile Adoption Framework, the 4Stage Process and the SAMI, were presented to over 35 members of the agile community to gather feedback about their goodness. The feedback obtained from this substantiation process is promising and conveys the perceived effectiveness of the framework alongwitheachofitscomponents. While the Agile Adoption Framework provides organizations with guidance and assistanceregardinganumberofissuesrelatedtoagileadoption,itdoesnotguide thecompleteprocessimprovementlifecycleoftheorganization.TheAgileAdoption Framework focuses on providing guidance in the initial stages of process improvement lifecycles like IDEAL. The Agile Adoption Framework has a strong assessmentfocusinordertoprepareorganizationsbeforeattemptingtoadoptagile practices. At the same time, as explained in the 4Stage Process, the assessment conducted by the framework also provides the organization with guidance regarding what changes need to occur in the organization to prepare for the adoption of certain practices. With the help of the SAMI, the framework also provides the organization with a roadmap that illustrates the steps (i.e. levels) 157

necessarytostarttheagileadoptioneffort.Theframeworkprovidesthisguidance independent of any one particular agile method or style. Thatis, the framework is notbasedonXPorSCRUMoranyotheragilestyle;itisbasedonthecorevaluesand principlesofagilityasdefinedbytheAgileManifesto.

6.1. MainContributions
The Agile Adoption Framework has contributed to the Computer Science body of knowledge, and in particular to that of Software Engineering and process improvement related to agility. The frameworks contributions are manifested throughprovidingtheagilecommunitywithastructuredapproachtoagileadoption and a measurement index for agility. These contributions originate from the two components of the framework, the 4Stage Process and the Sidky Agile MeasurementIndex. The 4Stage Process: provides a structured approach that guides and assists organizations seeking to adopt agile practices. Moreover, the four stages are sequenced in an effective manner that avoids conducting unnecessary activities, while at the same time ensuring that neither the projects potential nor the organizational characteristics are overlooked. The 4Stage process provides a numberofbenefitsandcontributions,mainly: StructuringtheAgileAdoptionProcess The 4Stage process introduces structure in the complex and unpredictable process of the agile adoption. The structuring of the process is divided into four stages: (1) Identifying Discontinuing Factors, (2) Project Level Assessment, (3) Organizational Readiness Assessment, and (4) Reconciliation.Eachstagehasclearlydefinedinputs,outputs andobjectives tocompletethe4stageprocess.

158

MakingtheAgileAdoptionProcessRepeatable By introducing four clearly defined stages and activities to help guide agile adoption efforts, the 4Stage Process has explicitly defined portions of the agileadoptionprocess.Onceaprocessisdefined,itcanberepeatedbecause different organizations can undergo the same process (agile adoption) knowingwhichactivitiesandtasksneedtobecompleted.

IntroducingthenotionofPreadoptionAssessment Stage 1 of the 4Stage Process introduces the concept of preadoption assessment, which allows organizations to determine, before the adoption starts, aspects of the organization that could cause the adoption of an agile practice to fail. Conducting a preadoption assessment before starting the agileadoptioneffortcansaveanorganizationfromneedlesslyspendingtime, moneyandeffortonanSPIthathaslittlechanceofsuccess.

DefininganApproachforDeterminingtheAgilePotentialofIndividualProjects Stage2and3inthe4StageProcessprovidetheorganizationwithtwolevels ofassessment.Thefirstisataprojectlevel(stage2)andthesecondisonan organizational level (stage 3). Stage 2, the Project Level Assessment, determines the target agile level (based on the SAMI) for the project after assessing certain organizational factors that are needed to support the adoption of certain agile practices. Stage 2 assesses only the organizational factorsthatcannotbechangedorareoutsidetheorganizationscontrol.The Organizational Readiness Assessment (stage 3), focuses on the organizationalfactorsthatcanbechangedandarewithintheorganizations control.Hence,withStage2andStage3workingtogether,theAgileAdoption Framework accommodates the uniqueness of each project and at the same time,recognizesthateachprojectissurroundedby,andisapartofanoverall organizationthatmustbereadytoadopttherequisiteagilepractices.

159

The Sidky Agile Measurement Index (SAMI): is a tailorable measurement index capableofmeasuringtheagilepotentialofprojectsandorganizationsrelativetothe essentialvaluesandqualitiesofagility.Thiscapabilitystemsfromthestructureof themeasurementindexwhereitgroupstheagilepracticesinasynergisticmanner based on the essential agile qualities and values they help introduce in the developmentprocess.TheSAMIprovidesanumberofcontributions: Auniqueapproachtomeasuringagilepotential TheSAMIhas4maincomponents:(1)AgileLevels,(2)AgilePrinciples,(3) Agile Practices, and (4) Indicators. The structure of the SAMI introduces an intuitive way for creating an agile measurement index. The units for the SAMIaretheAgileLevels.EachlevelispopulatedwithasetofAgilePractices which represent the basic measuring element of the index. The population processforeachAgileLevelisguidedbytheAgilePrinciples toensurethat each agile level manifests as many characteristics of an agile process as possible.TheIndicatorsassociatedwitheachagilepracticeprovideassessors withaquantifiablemeanstoassessthereadinessoftheorganizationforeach agile practice. The aggregated results of the indicator values indicate the agilepotentialofaprojectororganization. DefinesaHierarchyofover300Indicators To measure the readiness of an organization to adopt a particular agile practice, several different factors within the organization must be assessed. The SAMI provides a hierarchal organization of those factors in Readiness Assessment Tables (RAT). Each RAT contains the organizational factor that willbeassessed,theobjectiveoftheassessment,theassessmentmethod,and the list of indicators that are to be used for the assessment. Using this hierarchalstructure,theSAMIisabletomanageover300differentindicators toassessanorganizationsreadinessrelativeto40differentagilepractices.

160

IllustratingaRoadmapforAgility ByorganizingtheAgilePracticesintoAgileLevels,theSAMIalsoprovidesthe agilecommunitywitharoadmapforthoseaspiringtomovetowardagility. ThedefinitionofAgileLevelsintheSAMIencouragesorganizationstoadopt the practices within the first Agile Level first, then move to the practices encompassed within subsequent levels of agility. The mere structure of the SAMI,especiallytheAgileLevels,providesorganizationswitharoadmapfor theirjourneytowardagility

RedefiningWhenanOrganizationisConsideredAgile Manyorganizationsaskwhenaretheyconsideredagile.TheSAMIredefines thetermagilefrombeingadefinitestatetoaspectrum.BasedonSAMI,the level or degree of agility is dependent on the number of agile practices an organizationhasadopted.Moreover,thelevelofagilityisdependentonthe adoption of a certain group of agile practices that work together to help introduce a new value or quality into the development process. Therefore, due to the SAMI, there is now the notion of level of agility or degree of agilitynotjustwhetherornotyourorganizationisagile.

6.2. FutureWork
We view the Agile Adoption Framework as an initial contribution towards answering the complex question of how to adopt agile practices. There is much room for the framework to mature and grow through further research. The following points are some possible areas for development of the Agile Adoption Framework. Conductingalongitudinalstudy For the purpose of this dissertation, the feedback obtained from the members of the agile community regarding the Agile Adoption Framework leadtothesubstantiationoftheframework.Nevertheless,itisnecessaryto conduct a longitudinal study that gathers empirical evidence to further 161

validate the framework and empirically prove the benefits yielded from usingtheAgileAdoptionFramework. IncorporatingBusinessValueintheSAMI Theagilecommunityisalwaysconcernedaboutthebusinessvaluerealized fromeachstepofthedevelopmentprocess.Thisleadsustoask:whatarethe businessvaluesrealizedfromeachstepoftheagileadoptionprocess?Future work may include identifying the different business values associated with achievingeachAgileLevel.ThisadditiontotheSAMIisespeciallyusefulfor executivesthatneedtoseewhatvalueadoptinganewAgilelevelwouldyield totheorganizationbeforesupportingtheadoptionprocess. Enhancingthehierarchyofindicators The indicator hierarchy has two aspects that are suitable for further research:thecontentandthestructure. The content of the indicators (i.e. the actual questions) can be enhanced by conducting a study in which agile development environments are closely observedandanalyzed.Thisstudywillhelprefineandaddindicatorstothe Agile Adoption Framework in order to ensure accurate and realistic results whenusingtheindicatorsforreadinessassessment. As for the structure of the indicator hierarchy, we intend to explore the possibleacyclicnatureofthehierarchy.Thisisanimportantaspectbecause it can be used to help increase the overall efficiency of the assessment process.Morespecifically,bydeterminingthatthehierarchyofindicatorsis acyclic, positive correlations between the indicators can be identified. As a result, a smaller and more efficient set of indicators can be integrated into the readiness assessment process without affecting the quality of that assessment.

162

AutomationoftheportionsoftheFramework. Futureworkmayalsoincludedevelopingtoolstoautomatethepreadoption assessment process and assist with the evaluation of the results. For example, the indicators can be prepared on OpScan (Optical Scan) forms. Therefore, when an assessment is conducted in an organization, the developers, managers, customers and assessors are each given their respective OpScan forms. Once they answer the questions, the forms are automatically scanned and a program analyzes the results and suggests the setofagilepracticesmostsuitablefortheorganizationtoadopt.

163

6.3. Summary
In summary, we propose the Agile Adoption Framework as an approach to guide andassistorganizationsintheirquesttoadoptagilepractices.Throughidentifying andassessingthepresenceofdiscontinuingfactors,organizationscanmakeago/no godecisionregardingthemovetowardagility.Bydeterminingthe target level for a project and then assessing the organization to determine the extent to which it is ready to achieve that target level of agility, the framework manages to provide coaches with a realistic set of agile practices for the project to adopt. The 4Stage processassessment,throughitsutilizationoftheagilemeasurementindex,provides an extensive outline of the areas within the organization that need improvement beforetheadoptioneffortstarts. While we recognize that the framework has yet to reach it full potential, we are encouraged by the comments given to the Agile Adoption Framework from membersoftheagilecommunity: Ithinkthisisfantastic(work)Agileconsultantwith12yearsexperience This is the RIGHT time for this work! Excellent JobAgileconsultantwith8 yearsexperience Overall this is firstclass work and I endorse this work as legitimate in its interest and merit to our industry (paraphrased due to length) XP Coach with6yearsexperience.

164

7. References
[1] [2] [3] DeclarationofInterdependence,http://pmdoi.org/,2005. ManifestoforAgileSoftwareDevleopment,www.agilemanifesto.org,Utah,Feb 2001. P.Abrahamsson,S.Outi,J.RonkainenandJ.Warsta,Agilesoftware developmentmethodsReviewandanalysis,VTTElectronicsFinland,2002, pp.112. [4] [5] [6] [7] [8] [9] K.J.Aguanno,ManagingAgileProjects,MultiMediaPublicationsInc.,2005. S.Ambler,AgileModeling:EffectivePracticesforExtremeProgrammingand theUnifiedProcessWiley,2002. S.Ambler,CommunicationonAgileSoftwareProjects, http://www.agilemodeling.com. S.W.AmblerandP.J.Sadalage,RefactoringDatabases:EvolutionaryDatabase Design,AddisonWesleyProfessional,2006. L.AmyandC.Raylene,Effectsofagilepracticesonsocialfactors,ACMPress, St.Louis,Missouri,2005. J.ArthurandR.Nance,ManagingSoftwareQuality:AMeasurement FrameworkforAssessmentandPrediction,Springer,2002. [10] O.Balci,R.Adams,D.MyersandR.Nance,AcoollaborativeEvaluation EnviornmentforCredibilityAssessmentofModelingandSimulation ApplicationsWinterSimulationConference,2002. [11] L.Barnett,AgileSurveyResults:SolidExperienceAndRealResultsAgile Journal,2006. [12] L.BarnettandC.Schwaber,AdoptingAgileDevelopmentProcesses;Improve TimeToBenefitsForSoftwareProjectsForresterResearch,2004. [13] V.Basili,Softwaremodelingandmeasurement:theGoal/Question/Metric paradigm,UniversityofMarylandatCollegePark,1992,pp.24. [14] V.R.Basili,Softwaredevelopment:aparadigmforthefuture,1989,pp.471 485. 165

[15] F.Bauer,SoftwareEngineering,InformationProcessing71(1972). [16] Beck,TestDrivenDevelopment:ByExample,AddisonWesleyLongman PublishingCo.,Inc.,2002. [17] K.Beck,ExtremeProgrammingExplained:EmbraceChange,AddisonWesley, 2000. [18] K.Beck,R.C.Martin,A.Cockburn,M.FowlerandJ.Highsmith,Manifestofor AgileSoftwareDevleopment,www.agilemanifesto.org,Utah,Feb2001. [19] B.Boehm,GetReadyforAgileMethods,withCare,Computer,Vol.35(2002), pp.pp.6469 [20] B.BoehmandV.R.Basili,Top10list[softwaredevelopment],Computer,34 (2001),pp.135137. [21] B.BoehmandR.Turner,Managementchallengestoimplementingagile processesintraditionaldevelopmentorganizations,Software,IEEE,22(2005), pp.3039. [22] B.W.BoehmandR.Turner,BalancingAgilityandDiscipline,AddisonWesley Professional,Boston,2003. [23] A.Cockburn,PersonalCommunicationSaltLakeCity,UT,November2006. [24] A.Cockburn,AgileSoftwareDevelopmentPearsonEducation,Indianapolis, 2001. [25] A.Cockburn,AgileSoftwareDevelopment:TheCooperativeGame(2ndEdition) (AgileSoftwareDevelopmentSeries),AddisonWesleyProfessional,2006. [26] A.Cockburn,CrystalClear:AHumanPoweredMethodologyforSmallTeams AddisonWesleyProfessional,2004. [27] A.CockburnandJ.Highsmith,AgileSoftwareDevelopment:ThePeopleFactor, Computer,Volume34(2001),pp.Pages:131133 [28] M.Cohn,PersonalCommunication,Dayton,OH,October2006. [29] M.Cohn,AgileEstimatingandPlanningPrenticeHallPTR,2005. [30] M.Cohn,UserStoriesApplied,AddisonWesley,Boston,2004. [31] M.CohnandD.Ford,IntroducinganAgileProcesstoanOrganization Computer,Vol.36(2003),pp.7478.

166

[32] J.Collins,GoodtoGreat:WhySomeCompaniesMaketheLeap...andOthers Don't,Collins2001. [33] S.Datta,Agilitymeasurementindex:ametricforthecrossroadsofsoftware developmentmethodologies,Proceedingsofthe44thannualSoutheast regionalconference,ACMPress,Melbourne,Florida,2006. [34] E.DerbyandD.Larsen,AgileRetrospectives:MakingGoodTeamsGreat, PragmaticBookshelf,2006. [35] J.Drobka,D.NoftzandR.Rekha,PilotingXPonfourmissioncriticalprojects, Software,IEEE,21(2004),pp.7075. [36] P.Duvall,S.MatyasandA.Glover,ContinuousIntegration:ImprovingSoftware QualityandReducingRisk2007. [37] E.Eckman,XPTransitionRoadmap,ThirdInternationalConferenceon ProgrammingandAgileProcessesinSoftwareEngineering(XP2002),Sardinia, Italy,2002. [38] A.Elssamadisy,PersonalCommunication,Amherst,MA,October2006. [39] A.Elssamadisy,GettingBeyond"ItDepends!"BeingSpecificButNot PrescriptiveAboutAgilePracticeAdoptionAgileJournal,2006. [40] K.E.EmamandN.H.Madhavji,ElementsofSoftwareAssessment& Improvement,IEEEComputerSociety,USA,1999. [41] M.Fowler,K.Beck,J.Brant,W.OpdykeandD.Roberts,Refactoring: ImprovingtheDesignofExistingCode,AddisonWesley,Reading, Massachusetts,1999. [42] M.Gladwell,TheTippingPoint:HowLittleThingsCanMakeaBigDifference BackBayBooks,2002. [43] R.B.Grady,Successfulsoftwareprocessimprovement,PrenticeHall,Inc., 1997. [44] P.HerseyandK.Blanchard,ManagementofOrganizationalBehavior:Leading HumanResourcesPrenticeHall1982. [45] J.Highsmith,AgileSoftwareDevelopmentEcosystems,PearsonEducation, Indianapolis,2002.

167

[46] J.Highsmith,Agile:FromRogueTeamstoEnterpriseAcceptanceCutter Consortium:BusinessTechnologyTrendsandImpacts,2006. [47] G.Hofstede,CulturesandOrganizations,SoftwareoftheMind:Intercultural CooperationanditsImportanceforSurvivalMcGrawHill,1996. [48] W.S.Humphrey,Introductiontotheteamsoftwareprocess,AddisonWesley LongmanLtd.,2000. [49] W.S.Humphrey,Managingtechnicalpeople:innovation,teamwork,andthe softwareprocess,AddisonWesleyLongmanPublishingCo.,Inc.,1996. [50] A.HuntandD.Thomas,PragmaticUnitTestinginC\#withNUnit,The PragmaticProgrammers,2004. [51] J.Hunt,AgilesoftwareconstructionSpringer,London2006. [52] ISO/IEC,ISO/IEC155047:GuideforuseinProcessImprovement,Information TechnologySoftwareProcessassessmentPart7,ISO/IEC,1998,pp.43. [53] P.H.JanandJ.Jorn,AIMAbilityImprovementModel,2005. [54] B.Jason,M.John,M.Erik,B.MatthewandA.Azeem,TailoringXPforLarge SystemMissionCriticalSoftwareDevelopment,2002. [55] T.Khknen,LifeCycleModelforSoftwareProcessImprovementProject DeployinganAgileMethod,ICAM2005InternationalConferenceonAgility, Helsinki,Finland,2005. [56] W.Kelly,P.Mary,M.Ron,S.NancyVanandP.Bill,AgileMethodsforSafety CriticalSoftwareDevelopment,2004. [57] A.S.Koch,Agilesoftwaredevelopment:evaluatingthemethodsforyour organization,ArtechHouse,Boston,MA2005. [58] S.KomiSirvi,DevelopmentandEvaluationofSoftwareProcess ImprovementMethods,VTTPublications2004. [59] S.Kuppuswami,K.Vivekanandan,P.RamaswamyandP.Rodrigues,The effectsofindividualXPpracticesonsoftwaredevelopmenteffort,SIGSOFT Softw.Eng.Notes,28(2003),pp.66. [60] C.Larman,AgileandIterativeDevelopment,PearsonEducation,Boston,2004.

168

[61] A.LawandR.Charron,Effectsofagilepracticesonsocialfactors,Proceedings ofthe2005workshoponHumanandsocialfactorsofsoftwareengineering, ACMPress,St.Louis,Missouri,2005. [62] T.Little,Contextadaptiveagility:managingcomplexityanduncertainty, Software,IEEE,22(2005),pp.2835. [63] T.Little,F.Greene,T.Phillips,R.PilgerandR.Poldervaart,AdaptiveAgilityin I.Software,ed.,AgileDevelopmentConference(ADC'04),IEEESoftware,2004, pp.pp.6370. [64] R.C.Martin,AgileSoftwareDevelopment,Principles,Patterns,andPractices, PrenticeHall2002. [65] P.W.Mattessich,M.MurrayCloseandB.Monsey,Collaboration:WhatMakes ItWork,2ndEdition:AReviewofResearchLiteratureonFactorsInfluencing SuccessfulCollaborationAmherstH.WilderFoundation,2004. [66] R.McFeeley,IDEAL:AUser'sGuideforSoftwareProcessImprovement, SoftwareEngineeringInstitute(SEI),1996,pp.222. [67] S.Nerur,R.MahapatraandG.Mangalaraj,Challengesofmigratingtoagile methodologies,Commun.ACM,48(2005),pp.7278. [68] J.W.NewkirkandR.C.Martin,ExtremeProgramminginPracticePrentice Hall,2001. [69] M.C.Paulk,AgileMethodologiesandProcessDiscipline,CrossTalk:The JournalofDefenseSoftwareEngineering(2002). [70] K.Peterson,Collaboration:TheKeytoEnterpriseAgileAdoptionCutterIT Journal,July05(2005). [71] A.Pukinskis,5stumblingblocksfornewcorporateagileprojects,theagile blog,2005. [72] D.Rosenberg,M.StephensandM.CollinsCope,Agiledevelopmentwith ICONIXprocess:people,process,andpragmatismApressBerkeley,CA2005. [73] A.Rueping,AgileDocumentation:APatternGuidetoProducingLightweight DocumentsforSoftwareProjectsJohnWiley&Sons2003. [74] O.Salo,EnablingSoftwareProcessImprovementinAgileSoftware DevelopmentTeamsandOrganisationsVTTPublications,2006. 169

[75] A.Sanjiv,PersonalCommunication,Reston,VA,October2006. [76] B.SchatzandI.Abdelshafi,Primaveragetsagile:asuccessfultransitionto agiledevelopment,Software,IEEE,22(2005),pp.3642. [77] K.SchwaberandM.Beedle,AgileSoftwareDevelopmentwithSCRUM,Prentice Hall,,2002. [78] A.SidkyandJ.D.Arthur,DeterminingtheApplicabilityofAgilePracticesto MissionandLifecriticalSystems,The31stAnnualSoftwareEngineering Workshop(inconjunctionwith3rdIEEESystemsandSoftwareWeek), Baltimore,Maryland,March2007. [79] M.K.Spayd,Evolvingagileintheenterprise:implementingXPonagrand scale,2003,pp.6070. [80] J.Tabaka,CollaborationExplained;FacilitationSkillsforSoftwareProject Leaders,AddisonWesley,2005. [81] W.Wake,PersonalCommunication,Richmond,VA,September2006. [82] W.C.Wake,ExtremeProgrammingExplored,AddisonWesleyProfessional, 2001. [83] L.H.Werth,LectureNotesonSoftwareProcessImprovement,Software EngineeringInsitute1993. [84] L.WilliamsandR.Kessler,PairProgrammingIlluminated,AddisonWesley LongmanPublishingCo.,Inc.,2002. [85] L.Williams,R.R.Kessler,W.CunninghamandR.Jeffries,Strengtheningthe caseforpairprogramming,Software,IEEE,17(2000),pp.1925. [86] I.WilsonandJ.Wyer,ThePowerofCollaborativeLeadership::Lessonsforthe LearningOrganizationButterworthHeinemann,2000.

170

Appendix A: Indicators
Indicators are essentially questions used by an assessor to measure certain characteristics of an organization or project, such as its developers, culture, management, software process, tools, project management practices, and physical environment. Asetofindicators,orquestions,mustaccompanyeach agilepracticeorconceptin the measurement index. The agile coach uses these indicators (or questions) to measuretheextenttowhich Most indicators are based on a 5point Likert summated scale, from 1 strongly disagreeto5stronglyagree.Asmallnumberofindicatorsarebasedonother5 pointscalesthataremoreappropriatetothecharacteristicbeingassessed. The Agile Adoption Framework contains a set of over 300 suggested indicators, howevertheassessorperformingtheactualassessmentmayaddotherquestionsif needed. discontinuingfactorsarepresentinanorganization theorganizationisreadytoadoptanagilepracticeorconcept

OrganizationoftheIndicators
Theindicatorsusedtoassesseachagilepracticeordiscontinuingfactoraregrouped together in an assessment table. An assessment table captures the different organizational characteristics that need to be assessed for a practice and which indicator(s)shouldbeusedtoassesseachcharacteristic.Thetablebelowshowsthe assessment table used to assess the extent to which the organization is ready to adopttheagilepractice,CodingStandard.

171


Categoryof Assessment People Areatobeassessed Characteristicto beassessed BuyIn Todetermine: Whetherthedevelopersseethebenefitand arewillingtoapplycodingstandards Whetherthereexistsanykindofcoding standardsthatareused Assessment Method Interviewing Sample Indicators OR1_D21, OR1_D22 OR1_A2

Developers

Process

CodingStandards

Existence

Observation

Assessmenttableusedtomeasureorganizationalreadinessforanagilepractice The table above shows that in order to assess the organizations readiness for codingstandards,theassessorfirstlooksatthepeopleintheorganizationwitha particularfocusonthedevelopers.Thecharacteristicthatneedstobeassessedwith regardstothedevelopersistheirbuyin.Theassessmentofthedevelopersbuyin willhelptodeterminewhetherornotthedeveloperscanrecognizethebenefitsof codingstandardsandarewillingto adoptthem. The 5thcolumn intheassessment table suggests a method of the assessment process; in this case it is interviewing. Thelastcolumncontainsthelistofindicatorsthatcanbeusedfortheassessment process.Theassessorisfreetouseotherassessmentmethodsorindicatorsaslong asthecharacteristicsthatneedtobeassessingarevalidlymeasured. Each agile level in the agile measurement index contains a set of practices. Therefore, from an assessment viewpoint, each agile level will contain the assessmenttablesforallthepracticesencompassedwiththelevel.Foreachlevel,all theindicatorsassociatedwiththelevelaregroupedtogetherbasedonthegroupof people the question is targeted toward. This group is identified by the first letter after the underscore in the indicators name. For example, the indicator OR1_D21 shouldbeansweredbyadevelopersincethecharacteraftertheunderscoreisaD. The codes used to denote the four different groups of people the indicators are targetedtowardare: A:denotesanindicatorthatneedstobeansweredbythe assessor(theone conductingtheassessment)

172

D:denotesanindicatorthatneedstobeansweredbya developer (anyoneon thedevelopmentsideoftheproject) M: denotes an indicator that needs to be answered by a manager (anyone performingmanagementrelatedtaskswithregardstotheproject) C:denotesanindicatorthatneedstobeansweredbya customer executive (a decisionmakerfromtheentitycontractingtodevelopthesoftware)

Asforthelettersbeforetheunderscore,theyrepresentthestagewithintheprocess thatusuallyusestheindicator.Forexample,OR1impliesthatthisindicatorisused to measure the Organizational readiness for Agile Level 1. The list of all the codes usedbeforetheunderscoreandtheirmeaningsare: DC: represents indicators that used during Stage 1: Identifying the DiscontinuingFactors PL: represents indicators that are used during Stage 2: Project Level Assessment ORx: represents indicators that are used during Stage 3: Identifying the OrganizationalReadiness,relativetoAgilelevelx

EvaluationoftheIndicatorsResults
This section presents the evaluation methodology used after all the indicators are assessed.Thesampleassessmenttablebelowisusedtoexplainthemethodology. Each discontinuing factor or agile practice uses an assessment table similar to the onebelow.

173

Categoryof Assessment

Areatobe assessed

Characteristic assessed Interaction

Todetermine: Whether there exists any levels of interaction between people hence laying a foundation for moreteamwork Whether people believe in group work and helping others or are they just concerned about themselves Whetherpeoplearewillingtoworkinteams

Assessment Method Interviewing

Sample Indicators I1,I2,I3

Collectivism People Developers

Interviewing Interviewing Interviewing

I4 I5,I6 I7,I8

BuyIn

Whether people recognize that their input is valuableingroupworkornot

After the assessor gathers the results from the surveys, he or she start a series of stepstoevaluatetheresults.Thesestepsandtheevaluationmethodologyusedare based off of the framework of the Evaluation Environment [10]. To use an automatedtooltoconductanevaluationoftheresults,ortolearnmoreaboutthe evaluationenvironmentpleasevisit:http://www.orcacomputer.com/ee. Step1:Computeaweightforeachindicator Thefirststepistoassignaweighttoeachindicator.Aweightisafractionalvalue between0and1thatexpressestheindicatorslevelofinfluenceontheparentfactor or organizational characteristic. The weights of all the indicators belonging to the same factor must sum to 1. We will assume that all the indicators have an equal weight,howeverevaluatorsarefreetoassignindicatorshigherweightsthanother. Therefore looking at the first factor in the example above, the weights can be computedasfollows(undertheassumptionallindicatorshaveanequalinfluenceof theparentfactor) 1 (sumofallweights)/ 3 (numberofindicators)= 0.334(approximateweightper indicator) Step2:Computeweighedinterval Afterwecomputedtheweightforeachoftheindicators,thenextstepistocompute the weighted intervals for each of the indicators. For the above example we will

174

assumethefollowinganswersweregiventothesampleindicatorsofthefirstfactor beingassessed.
Indicator SampleQuestion V 0%15% W 15%40% X NormalizedCategories X Y 40%60% 60%85% X Z 85%100%

I1 Question1 X I2 Question2 I3 Question3 XRepresentstheanswerthatwaschosenforthatindicator

Onceyouhavetheanswersfromthesampleindicatorsthenextstepistomultiple theweightoftheindicatorbythehighandlowendoftheintervalrangeselectedfor theindicator

Indicator Number I1 I2 I3 Computed Weight 0.33334 0.33334 0.33334 Interval LowEnd 0 40 85 Interval HighEnd 15 60 100 Interval Low End X Weight 0X0.3334=0 40X0.3334=13 85X0.3334=28 Interval High End X Weight 15X0.3334=5 60X0.3334=20 100X0.3334=33

Step3:CalculateResultRange The next step is to compute the Result Range by calculating the optimistic and pessimistic range for each factor. This is accomplished by summing up all the weighed intervals wegotfrom the previousstep.Theexamplebelow highlights in moredetailhowthisisdone. PessimisticResult=SumofalltheweighedlowendresultsfromStep2 PessimisticResult:0+13+28=41 OptimisticResult=SumofalltheweighedhighendresultsfromStep2 OptimisticResult:5+28+33=58 YourResultRange=4158 175

Step4:TranslatetoNominalScore In many cases the assessment table indicates that several aspects need to be assessed in order to completely assess a certain characteristic ofafactor. In those cases we do not compute and nominal value, rather we perform another round of aggregation,asdemonstratedabove,butonthenextleveluptillwereachthelevel of the characteristic being assessed. In the assessment table presented earlier you can see that to assess Interaction and Collectivism we do not have to go through anothercycleofaggregation.Howevertoassessthebuyinwehavetoaggregatethe indicatorsandthenwehavetoaggregatethe2differentaspectsofbuyinthatwe are assessing before we can move to the step that determines the nominal assessmentresultforthecharacteristicbeingassessed. Once you have a result range for that a particular characteristic, and you are sure you do not have to perform more aggregation the next step is to map the result rangetooneofthenominalvaluespresentedbelow.Thesenominalvaluesarethe onesthatareusedtoevaluatethefulfillmentofaparticularfactorornot.
NotAchieved PartiallyAchieved LargelyAchieved FullyAchieved 0%35% 35%65% 65%85% 85%100%

NominalValues

IfthePessimisticOptimistic(FromStep3)rangefitswithinoneoftheseintervals thenthatsuffices,iftheydonotthenobtainanaverageandthenplacethataverage initsnecessarynominalrange. Inourexampletheresultantscorewillbe:PartiallyAchieved Belowisasampleoftheevaluationtemplatethatwouldbeusedfortheassessment tableexamplegivenearlier

176


Categoryof Assessment Areatobe assessed Characteristic assessed Nominal Value Weight Low High Indicator I1 Interaction 1 I2 I3 Project Management Developers Collectivism 1 0.5 BuyIn 0.5

Weight 0.333 0.333 0.333 1.000 0.500 0.500 0.500 0.500

Low

High

I4 I5 I6 I7 I8

EvaluationTemplateforanAssessmentTable Onceanominalscoreisreachedforeachorganizationalcharacteristicsbeing assessed,theirnominalvaluesarepluggedintotheevaluationmatrixsimilartothe tablebelowtodeterminewhichareasneedtobeaddressedbeforetryingtoadopt thatparticularagilepractice.

AgilePractices forAgileLevel1 Categoryof Assessment Areatobe assessed Characteristic assessed Not Achieved 0%35% LargeGap ManagementStyle Management Collaborative Planning People Developers Project Management Collaborative Teams Project Management People Process People Process Planning BuyIn Transparency PowerDistance BuyIn Existence Interaction Developers Collectivism BuyIn Coding Standards Developers Coding Standards Developers Managers Knowledge Sharing BuyIn Existence BuyIn BuyIn Availability X X Partially Achieved 35%65% MediumGap X X Largely Achieved 65%85% SmallGap X X X X X FullyAchieved 85%100% MinimalGap X X X X X

Knowledge Sharing

SampleEvaluationMatrixforAgileLevel1

177

The rest of this appendix presents the indicators contained in the Agile Adoption Framework. The indicators are grouped depending on which stage in the 4Stage process they are usedin.Thefirst sectioninthis appendix presentsthe indicators used to assess the discontinuing factors. The next section presents the indicators usedtoconductaprojectlevelassessment(toidentifythetargetlevelofagilityfora project). Then the last sections include all the indicators used in Stage 3 to assess theorganizationalreadinessforeachindividualagilepractice. Each section starts with an indicator map illustrating the hierarchy of indicators used during the associated stage. Following the indicator map are the assessment tables. Finally, the actually surveys where the indicators are found are grouped together based on who the indicator is addressed to (e.g. developers, managers, assessors,orcustomers).

178

Indicatorsrelatedto Stage1:DiscontinuingFactors

179

IndicatorMap

Discontinuing Factors
Inappropriate Need for Agility Historical Project Schedules and Budgets (A=2) Challenges with current software process (D=3,M=3) Rate of Change of Project Requirements (M=3) Time to Market Needed for Project (M=1) Lack of Sufficient Funds Availability of Funds (M=6) Absence of Executive Support Executive Management Buy-in (M=3)

180

Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicators question.

AssessmentTablesforDiscontinuingFactors

DiscontinuingFactor1:InappropriateNeedforAgility

Categoryof Assessment Areatobe assessed ProjectHistory Characteristic(s)to beassessed ScheduleandBudget Todetermine: Whetherornottheorganizationhasahistoryofhavingprojects thatgoovertimeandbudget Whetherornottheorganizationisfacinganyproblemsor dissatisfactionwiththecurrentsoftwareprocess Whetherornottheprojectsrequirementsareclearandwell defined,thuspredictingnochange,orwhetherornotthe requirementsneedtobeflexibleand/ormightchange Whetherornottheprojecthastobedevelopedquicklyinorder tointroduceittothemarketassoonaspossible Assessment Method Observation SampleIndicators

Organization

DC_A1,DC_A2 DC_D1,DC_D2,DC_D3, DC_M1,DC_M2,DC_M3 DC_M5,DC_M6,DC_M7 DC_M4

SoftwareProcess Requirements Project Delivery

Problems RateofChange TimetoMarket

Interviewing Interviewing Interviewing

DiscontinuingFactor2:LackofSufficientFunds

Categoryof Assessment Organization Areatobe assessed Budget Characteristic(s)to beassessed AvailabilityofFunds Todetermine: Whetherornottheorganizationhasfundstobespentonthe adoptionprocessofagileprocessesandiswillingtospendthem ontheadoptionprocess Assessment Method Interviewing SampleIndicators DC_M10,DC_M11, DC_M12,DC_M13, DC_M14,DC_M15

181

DiscontinuingFactor3:AbsenceofExecutiveSupport

Categoryof Assessment People Areatobe assessed Managers/ Executives Characteristic(s)to beassessed Buyin Todetermine: Whetherornotexecutivelevelmanagementcanseebenefitsof adoptingagileprocessesandwillbuyintothedevelopmentof agilesoftware Assessment Method Interviewing SampleIndicators DC_M3,DC_M8,DC_M9

182

TheSurveysEncompassingtheIndicators
SurveyforDevelopers

DC_D1 DC_D2 DC_D3

Statements Therearemanyareasinthedevelopmentprocessthatalwayscauseproblemsand/orare inefficient. Thecurrentdevelopmentprocessisinsufficientand/ordoesnotproducegoodsoftware. Thereisaneedtochangethesoftwareprocessintheorganization.

V Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree StronglyAgree StronglyAgree

SurveyforAssessors

Indicator

Statements Itcanbeconcludedfromthepreviousprojectplansandtheprojectdeliverydocumentsthatthe organizationhasbeenontimewhendeliveringitsprojects. Itcanbeconcludedfrompreviousprojectestimatesandtheprojectdeliverydocumentsthatthe organizationhasbeenwithinbudgetforitsdeliveredprojects.

V Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree

Z StronglyAgree

DC_A1

DC_A2

StronglyAgree

183

SurveyforManagers/Executives

Indicator DC_M1 DC_M2

Statements Therearesomeareasinthecurrentdevelopmentprocessthatfrequentlycauseproblems and/orareinefficient. Thecurrentdevelopmentprocessisinsufficientand/ordoesnotproducegoodsoftware.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree StronglyAgree

DC_M3 DC_M4 DC_M5

Thereisaneedtochangethesoftwareprocessintheorganization. Thecustomer/clientneedstointroducetheproducttothemarketquickly.(shorttimeto market). Thereisahighprobabilitythatrequirementswillchangeduringthedevelopmentprocess.

StronglyAgree StronglyAgree StronglyAgree

DC_M6 DC_M7 DC_M8

Notalltherequirementswillbeknownbeforedevelopmentstartsfortheproject. Thedeliverablesforthisprojectareunknown. Ingeneral,employingagileprocesseshelporganizationsovercometheirsoftwaredevelopment challengesand/orrespondbettertocustomerrequests. AnAgileDevelopmentapproachisidealfortheupcomingproject. Theorganizationhasmoneyallocatedfortraining. Theorganizationhasmoneyallocatedforprocessimprovementand/ororganizationalchange.

StronglyAgree StronglyAgree StronglyAgree

DC_M9 DC_M10 DC_M11

StronglyAgree StronglyAgree StronglyAgree

DC_M12 DC_M13 DC_M14

TheorganizationiswillingtospendontrainingpeopleaboutAgileProcesses. TheorganizationiswillingtospendwhateverittakesforprojecttoadoptanAgileDevelopment approach. Theorganizationhasthenecessaryfundstoundergotheprocessofadoptinganagile developmentapproachfortheupcomingproject. Ifadoptinganagileprocessmeansbuyingnewsoftware,theorganizationisableandreadyto spendonsuchsoftware.

StronglyAgree StronglyAgree StronglyAgree

DC_M15

StronglyAgree

184

 Indicatorsrelatedto Stage2:ProjectLevelAssessment

185

IndicatorMap

Agile Level 1 Agile Level 2 Agile Level 3

Customer Commitment to work with Developing Team Customer Contract reflective of Evolutionary Development Frequent face-to-face communication between the team Have around 30% of Cockburn Level 2 and Level 3 people on team CRACK Customer Immediately Accessible

Collaboration Willingness (C=3) Collaboration History (C=1) Willingness to use Evolutionary Process (C=3) Contract Structure (C=1) Distribution of team (A=4) Developers Competence (M=1) Customer Representatives Authority (C=1) Customer Representatives Knowledge (C=1) Customer Representatives Collaboration (C=1) Customer Representatives Availability (C=1) Customer Representatives Accessibility (C=1) Contract Structure and Format (C=4) Feasibility (M=3) Developers Competence (M=1) Customers Willingness (C=2)

Agile Level 4

Customer contract revolves around commitment of collaboration, not features Ideal Agile Physical Setup

Agile Level 5

No/Minimal number of Cockburn Level -1 or 1b People on team Frequent Face-to-face interaction between developers & Users (Collocated)

Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicators question.

186

AssessmentTablesforLimitingAgilePractices
LimitingAgilePracticewithinAgileLevel1

CustomerCommitmenttoworkwithDevelopingTeam
Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Willingness Customer Collaboration History Todetermine: Whetherornotthecustomeriscommittedtoworkwith DevelopingTeam Whetherornotthiscustomerhascollaboratedwithany developmentteambefore Assessment Method Interviewing Interviewing SampleIndicators PL_C1,PL_C3,PL_C4 PL_C2

LimitingAgilePracticewithinAgileLevel2
CustomerContractreflectiveofEvolutionaryDevelopment

Categoryof Assessment Areatobe assessed Evolutionary Process Contract Characteristic(s)to beassessed Willingness Structure Todetermine: Whetherornotthecustomeragreestoanevolutionary developmentapproach Whetherornotthecustomercontractcanbereflectiveof evolutionarydevelopment Assessment Method Interviewing Interviewing SampleIndicators PL_C5,PL_C6,PL_C8 PL_C7

Customer

187

 LimitingAgilePracticeswithinAgileLevel3
Frequentfacetofacecommunicationbetweentheteam

Categoryof Assessment People Areatobe assessed Location Characteristic(s)to beassessed Distribution Todetermine: Whetherornotfrequentfacetofacecommunicationbetween teammembersisachievable Assessment Method Observation SampleIndicators PL_A1,PL_A2,PL_A3, PL_A4

Havearound30%ofCockburnLevel2andLevel3peopleonteam

Categoryof Assessment People Areatobe assessed Developers Characteristic(s)to beassessed Competence Todetermine: Whetherornotthedevelopmentteamhasaround30%of Level2andLevel3peopleonteam Assessment Method Interviewing SampleIndicators PL_M1

LimitingAgilePracticeswithinAgileLevel4

Collaborative,Representative,Authorized,Committed,Knowledgeable(CRACK)Customer ImmediatelyAccessible

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Authority Knowledgeable Collaborative Availability Todetermine: Whetherornotthecustomerrepresentativehasauthority Whetherornotthecustomerrepresentativehasdetailed knowledgeabouttheproduct Whetherornotthecustomerrepresentativeiscollaborative Whetherornotthecustomerrepresentativeisavailable Assessment Method Interviewing Interviewing Interviewing Interviewing SampleIndicators PL_C9 PL_C10 PL_C11 PL_C12

Customer

Representative

188

Accessibility

Whetherornotthecustomerrepresentativeisimmediately accessible

Interviewing

PL_C13

Customercontractrevolvesaroundcommitmentofcollaboration,notfeatures

Categoryof Assessment Customer Areatobe assessed Contract Characteristic(s)to beassessed Structureandformat Todetermine: Whetherornotthecustomerscontractcanrevolvearound commitmentofcollaboration,notfeatures Assessment Method Interviewing SampleIndicators PL_C14,PL_C15,PL_C16, PL_C17

LimitingAgilePracticeswithinAgileLevel5

IdealAgilePhysicalSetup

Categoryof Assessment Organization Areatobe assessed PhysicalLayout Characteristic(s)to beassessed Feasibility Todetermine: Whetherornotitisfeasibletohaveanidealagilephysical setup Assessment Method Interviewing SampleIndicators PL_M3,PL_M4,PL_M5

No/MinimalnumberofCockburnLevel1or1bPeopleonteam

Categoryof Assessment People Areatobe assessed Developers Characteristic(s)to beassessed Competence Todetermine: WhetherornotnooraminimalnumberofLevel1or1b peopleexistsonthedevelopmentteam Assessment Method Interviewing SampleIndicators PL_M2

FrequentFacetofaceinteractionbetweendevelopers&Users(Collocated)

189

Categoryof Assessment Customer

Areatobe assessed FacetoFace Collaboration

Characteristic(s)to beassessed Willingness

Todetermine: Whetherornotthefrequentfacetofaceinteractionbetween developersandcustomerisachievable

Assessment Method Interviewing

SampleIndicators PL_C18,PL_C19

TheSurveysEncompassingtheIndicators
SurveyforCustomerExecutives

Indicator PL_C1 PL_C2 Statements Iamwillingtodedicatetimetotakeanactiveroleinthisproject. Inthepast,Ihavededicatedtimetocollaboratewiththedevelopmentteam. Ibelievethatthedevelopmentteamshouldmakemostoftheeffortandthatthecustomer shouldhavetodolittleotherthancheckontheprojectsstatusanddoafinalacceptance. Iamcommittedtoworkingwiththedevelopmentteam. Iagreetohavethesystemdevelopedinaniterative/incrementalfashionasopposedtothe approachofabigdeliveryattheendofthecontractedtime. Iamwillingtosignacontracttostartdevelopmentofaproductwhoserequirementscannotbe knownaheadoftimewithcertainty. Iamwillingtochangethecontractstructuretoreflectanevolutionarydevelopmentapproach. Evolutionarydevelopmentimpliesthattherequirements,plan,estimates,andsolutionevolve orarerefinedoverthecourseoftheiterations,insteadofbeingfullydefinedandfrozenina majorupfrontspecificationeffortbeforethedevelopmentbegins. Iamwillingtoacceptanoverallprojectplanandadetailedplanofthenextiterationonly.The customerdoesnothaveaproblemwithnotreceivingaGANTTorPERTchartofthewhole projectupfront. Thecustomerrepresentative(s)interactingwiththecontractedorganizationis(are)authorized tomakedecisionsonthespotregardingtheproductspecifications V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Z StronglyAgree StronglyAgree

PL_C3 PL_C4 PL_C5

StronglyAgree StronglyAgree StronglyAgree

PL_C6

StronglyAgree

PL_C7

StronglyAgree

PL_C8 PL_C9

StronglyAgree StronglyAgree

190

PL_C10

Thecustomerrepresentative(s)interactingwiththecontractedorganizationis(are) knowledgeableabouttheproductdomain(i.e.he/sheisadomainexpertorsubjectmatter expert). Thecustomerrepresentative(s)interactingwiththecontractedorganizationis(are) representativeoftheproductsactualusers. Thecustomerrepresentativeisavailableforthedevelopmentteamtocontactifitneedshis/her inputonsomething. Acustomerrepresentativeisimmediatelyaccessibletothedevelopmentteamifneeded. Iamwillingtosignacontractthatdoesnothaveadetailedenumerationoffeaturesand functionsbutbroadgoalsandthesuccesscriteria.Thisallowsthecustomermoreflexibilityto changeandaddrequirementsthroughoutthedevelopmentprocess. Iamwillingtoacceptacontractinwhichthetimeandbudget,butnotthefeaturestobe delivered,arefixed. Iamwillingtoacceptacontractthatcommitsbothsidestoadegreeofinteractionand collaborationinsteadofasetofdetailedrequirements. Iamwillingtochangeitstypicalcontractstructuretoreflectanewagiledevelopmentapproach. Anagiledevelopmentapproachwillgivethecustomertheflexibilitytochangeitsrequirements throughoutthedevelopmentprocess,andwilldeliversoftwareearlierandinincrements. Thecustomerwillbeavailableforfrequentfacetofaceinteractionwiththedevelopmentteam. Thecustomeriswillingtobecollocatedwiththedevelopmentteam.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree

PL_C11 PL_C12 PL_C13

StronglyAgree StronglyAgree StronglyAgree

PL_C14 PL_C15 PL_C16

StronglyAgree StronglyAgree StronglyAgree

PL_C17 PL_C18 PL_C19

StronglyAgree StronglyAgree StronglyAgree

SurveyforManagers/Executives

Indicator PL_M1 PL_M2 PL_M3

Statements WhatpercentageofthefulltimestaffisofCockburnLevel2orLevel3experts IndicatethepercentageoffulltimestaffwhoareCockburnLevel2orLevel3experts. Theorganizationcanhaveallthedevelopmentpersonnelinacommonroomratherthan separateofficesorcubicles. Theorganizationcansetupthedevelopmentroomstobettersupportagiledevelopment (furnitureawayfromthewalls).

V 05% 30%orhigher Strongly Disagree Strongly Disagree

W 510% 1530% Tendto Disagree Tendto Disagree

NominalValues X 1015% 1015% NeitherAgreenor Disagree NeitherAgreenor Disagree

Y 1530% 510% Tendto Agree Tendto Agree

Z 30%orhigher 05% StronglyAgree

PL_M4

StronglyAgree

191

PL_M5

Theorganizationcansetupanenvironmentwhereasmuchprojectinformationaspossibleis displayedonthewalls(viawhiteboards,clingsheets,orprojectors).

Strongly Disagree

Tendto Disagree

NeitherAgreenor Disagree

Tendto Agree

StronglyAgree

SurveyforAssessors

Indicator PL_A1

Statements Thedevelopmentteamislocatedwherememberscanhavefrequentfacetoface communication. Thegeographicdistributionofthedevelopmentteamcanbebestdescribedas Logistically,thedevelopmentteamcanmeetfacetoface. Itislikelyforthedevelopmentteamtohavefrequentfacetofacecommunication.

V Strongly Disagree WithinFlying Distance Yearlyor never Strongly Disagree

W Tendto Disagree Longdistance driving Monthly Tendto Disagree

NominalValues X NeitherAgreenor Disagree WithinDaily DrivingDistance Weekly NeitherAgreenor Disagree

Y Tendto Agree Withinthe same building Daily Tendto Agree

Z StronglyAgree Inthesame room Hourly StronglyAgree

PL_A2 PL_A3 PL_A4

192

Indicatorsrelatedto Stage3:OrganizationalReadinessAssessment

193

Collaborative Planning

Management Style (M=7,D=4) Managers Buy-in (M=2) Management Transparency (M=4) Power Distance (M=1,D=4) Developers Buy-in (D=1) Planning Activity Exists (M=2,A=1) Managements Buy-in (M=2) Developers Buy-in (D=1) Interaction between developers (M=1,D=1) Belief in Collectivism (D=1) Developers Buy-in (D=4) Empowerment of Developers (M=2,D=3) Motivation of Developers (D=6) Managers Trust to Developers (M=4,D=1) Developers Buy-in (D=2) Existence of Coding Standards (A=1) Developers Buy-in (M=1,D=2) Managers Buy-in (M=5) Availability of Knowledge Sharing Tools (A=1) Developers Buy-in (D=1) Managers Buy-in (M=1) Ability to change and improve process (M=3,D=3)
Existence of Requirements Engineering (M=2,A=1) Experience with Requirements Engineering (M=1,D=1) Managements level of uncertainty avoidance (M=3) Managers Competence with Eliciting Requirements (M=2) Managers Buy-In (M=5) Developers level of uncertainty avoidance (D=2) Developers Buy-In (D=3) Developers Competence (D=2) Existence of Software tools for SCM (A=1) Managers Competence with Multi-level Planning (M=5) Managers Buy-in to Continuous Planning (M=2) Organizations Experience with Multi-level Planning (M=1) Any Software Development Process Exists (M=2,D=2,A=1) Experience with Iterative Development Process (M=2,D=2) Managements level of stress tolerance (M=1) Managers Competence with Incremental Development (M=2) Managers Buy-In (M=2) Developers level of stress tolerance (D=1) Developers Buy-In (D=3) Developers Competence (D=2) Existence of any Monitoring and Reporting (M=2,D=2) Managers Buy-in (M=1) Developers Buy-in (D=1) Previous Design Experience (M=2) Managers Buy-in (M=3) Developers Buy-in (D=3)

Task Volunteering not Task Assignment Collaborative Teams

Agile Level 1
Empowered and Motivated Teams Coding Standards Knowledge Sharing

Reflect and Tune Process

Evolutionary Requirements Software Configuration Management Planning at Different Levels

Agile Level 2
Continuous Delivery

Forbestview,pleaseviewthispageusingaportraitorientation

Tracking Iteration Progress through Working Software No Big Design Up Front

Risk Driven Iterations Continuous Improvement (Refactoring) Self-Organizing Teams

Managers Competence with Risk Assessment (M=3,D=1) Managers Buy-in (M=1) Developers Buy-in (D=1) Organizations Experience with Risk Assessment (M=1,D=1) Developers Buy-in (D=2) Developers Competence (M=1) Experience with Continuous Improvement (M=2,D=2) Managers Buy-in (M=1) Managers Competence overlooking self-organizing teams (M=5) Developers Buy-in (D=3) Developers Buy-in (D=4) Existence of Software Tools for Continuous Integration (A=1)

Agile Level 3

Agile Levels
Maintenance of a list of all remaining features (backlog) Unit Tests

Continuous Integration

Managers Buy-in (M=1) Method for tracking remaining work currently exists (M=1,A=1)

Managers Buy-in (M=2) Developers Competence with writing Unit Tests (D=3) Developers Buy-in (D=3) Appropriate tools for writing and running unit tests exists (A=1) Managers Buy-in (M=3)

Client Driven Iteration Continuous Customer Satisfaction Feedback

Method to obtain customer feedback exists (M=2) Managers Buy-in (M=3) Developers Buy-in (D=3) Managements level of stress tolerance (M=1) Managers Buy-In (M=1) Developers level of stress tolerance (D=1) Developers Buy-In (D=1) Smaller and more frequent Releases Adaptive Planning Daily Progress Tracking Meetings Managers Buy-in (M=2) Regular progress meeting currently exists (M=1,D=1) Managers Buy-in (M=1) Developers Buy-in (D=1) Managers Buy-in (M=1) Developers understanding of agile documentation (D=2) Managers understanding of agile documentation (M=2) External Regulations (M=2) Agile Documentation User Stories Managers Buy-in (M=2) Developers Competence writing User Stories (D=1) Regulations related to format of requirements (M=1) Process regulations related to ceremony (M=2,A=1) Fear of responsibility among people (M=1) Managers Buy-In (M=2) Managements trust to the Developers (D=2) Developers Buy-In (D=2) Low Process Ceremony Availability Historical Projects Estimations (A=1) Experience with Estimation (A=1) Current Estimation method (M=2) Managers Competence with Estimation (M=3) Developers Competence with Estimation of efforts (D=3) Managements level of Collaboration (M=3) Agile Project Estimation

Agile Level 4

Agile Level 5
Paired Programming

Managers Buy-In (M=2) Developers Buy-In (D=3) Measure of productivity (M=1) Collaborative Organizational Culture (M=1,D=2) Developers Competence with unit tests (D=5,M=1) Developers Perception (D=1) Developers Buy-In (D=1) Managers Buy-In (M=2) Availability of Automation tools for testing (M=1,A=1) Test Driven Development

194

IndicatorMapforAgileLevel1

Collaborative Planning

Management Style (M=7,D=4) Managers Buy-in (M=2) Management Transparency (M=4) Power Distance (M=1,D=4) Developers Buy-in (D=1) Planning Activity Exists (M=2,A=1) Managements Buy-in (M=2) Developers Buy-in (D=1) Interaction between developers (M=1,D=1) Belief in Collectivism (D=1) Developers Buy-in (D=4) Empowerment of Developers (M=2,D=3) Motivation of Developers (D=6) Managers Trust to Developers (M=4,D=1) Developers Buy-in (D=2) Existence of Coding Standards (A=1) Developers Buy-in (M=1,D=2) Managers Buy-in (M=5) Availability of Knowledge Sharing Tools (A=1) Developers Buy-in (D=1) Managers Buy-in (M=1) Ability to change and improve process (M=3,D=3)

Task Volunteering not Task Assignment Collaborative Teams

Agile Level 1

Empowered and Motivated Teams Coding Standards Knowledge Sharing

Reflect and Tune Process

Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicators question. 195

196

AssessmentTablesforAgilePracticeswithinAgileLevel1

CollaborativePlanning(Customers,DevelopersandManagementplantogether)

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Todetermine: Whetherornotacollaborativeoracommandcontrolrelation existsbetweenmanagersandsubordinates.Themanagement styleisanindicationofwhetherornotmanagementtruststhe developersandviceversa. Whetherornotmanagementissupportiveoforresistiveto havingacollaborativeenvironment Whetherornotmanagementcanbeopenwithcustomersand developersNopoliticsandsecrets Whetherornotpeopleareintimidated/afraidtogivehonest feedbackandparticipationinthepresenceoftheirmanagers Whetherornotthedevelopersarewillingtoplanina collaborativeenvironment Whetherornottheorganizationdoesbasicplanningforits projects Assessment Method SampleIndicators OR1_M1,OR1_M2, OR1_M3,OR1_M4, OR1_M5,OR1_M14, OR1_M17,OR1_D1 OR1_D2,OR1_D3, OR1_D4, OR1_M9,OR1_M10, OR1_M6,OR1_M7, OR1_M8,OR1_M13 OR1_M11,OR1_D6, OR1_D7,OR1_D8, OR1_D9 OR1_D5 OR1_A1 OR1_M16,OR1_M18

ManagementStyle Management People BuyIn Transparency PowerDistance Developers BuyIn

Interviewing

Interviewing Interviewing Interviewing Interviewing Observation Interviewing

ProjectManagement

Planning

Existence

TaskVolunteeringnotTaskAssignment

Categoryof Assessment Areatobe assessed Management People Developers BuyIn Characteristic(s)to beassessed BuyIn Todetermine: Whetherornotmanagementwillbewillingtobuyintoand canseebenefitsfromemployeesvolunteeringfortasks insteadofbeingassigned Whetherornotdevelopersarewillingtoseethebenefitsfrom volunteeringfortasks Assessment Method Interviewing Interviewing SampleIndicators OR1_M12,OR1_M15 OR1_D10

197

CollaborativeTeams

Categoryof Assessment Areatobe assessed Characteristic(s)tobe assessed Interaction Collectivism People Developers BuyIn Todetermine: Whetherornotanylevelsofinteractionexistbetweenpeople thuslayingafoundationformoreteamwork Whetherornotpeoplebelieveingroupworkandhelping othersorarejustconcernedaboutthemselves Whetherornotpeoplearewillingtoworkinteams Whetherornotpeoplerecognizethattheirinputisvaluablein groupwork Assessment Method Interviewing Interviewing Interviewing Interviewing SampleIndicators OR1_M1,OR1_D15 OR1_D16 OR1_D12,OR1_D11 OR1_D23,OR1_D13

EmpoweredandMotivatedTeams

Categoryof Assessment Areatobe assessed Characteristic(s)tobe assessed DecisionMaking Developers People Managers Motivation Trust Whetherornotpeoplearetreatedinawaythatmotivates them Whetherornotmanagerstrustandbelieveinthetechnical teaminordertotrulyempowerthem Interviewing Interviewing Todetermine: Whetherornotmanagementempowersteamswithdecision makingauthority Assessment Method Interviewing SampleIndicators OR1_M3,OR1_D4, OR1_D14,OR1_D17, OR1_M14 OR1_D14,OR1_D13, OR1_D23,OR1_D24, OR1_D25,OR1_D15 OR1_M13,OR1_M14, OR1_M6,OR1_M12, OR1_D2

CodingStandards

Categoryof Assessment People Process Areatobe assessed Developers CodingStandards Characteristic(s)to beassessed BuyIn Existence Todetermine: Whetherornotthedevelopersseethebenefitandarewilling toapplycodingstandards Whetherornotanykindofcodingstandardsexiststhatare used Assessment Method Interviewing Observation SampleIndicators OR1_D21,OR1_D22 OR1_A2

198

KnowledgeSharing

Categoryof Assessment Areatobe assessed Developers People Managers Tools Knowledge Sharing BuyIn Availability Characteristic(s)to beassessed BuyIn Todetermine: Whetherornotdevelopersbelieveinandcanseethebenefits ofhavingprojectinformationcommunicatedtothewhole team Whetherornotmanagersbelieveinandcanseethebenefitsof havingprojectinformationcommunicatedtothewholeteam Whetherornotknowledgesharingtoolsareavailableand accessible(Wikis,Blogsetc.) Assessment Method Interviewing Interviewing Observation SampleIndicators OR1_D18,OR1_D19, OR1_M19 OR1_M6,OR1_M7, OR1_M20,OR1_M21, OR1_M22 OR1_A3

ReflectandTuneProcess

Categoryof Assessment Areatobe assessed Developers People Managers Process Process improvement Buyin Capability Characteristic(s)to beassessed Buyin Todetermine: Whetherornotdevelopersarewillingtocommittoreflecting aboutandtuningtheprocessaftereachiterationorrelease Whetherornotmanagementiswillingtocommittoreflecting aboutandtuningtheprocessaftereachiterationorrelease Whetherornottheorganizationcanhandleprocesschangein themiddleoftheproject Assessment Method Interviewing Interviewing Interviewing SampleIndicators OR1_D26 OR1_M23 OR1_D27,OR1_D28, OR1_D29,OR1_M24, OR1_M25,OR1_M26

199

TheSurveysEncompassingtheIndicators
SurveyforDevelopers

Indicator OR1_D1 OR1_D2

Statements Yourmanagerlistenstoyouropinionsregardingtechnicalissues Yourmanagerdoesnotmicromanageyouoryourwork.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree

Z StronglyAgree StronglyAgree

OR1_D3 OR1_D4 OR1_D5

Yourmanagerencouragesyoutobecreativeanddoesnotdictatetoyouwhattodoexactly. Yourmanagergivesyoutheauthoritytomakedecisionswithoutreferringbacktohim/her. Youwouldliketoparticipateintheplanningprocessoftheprojectyouwillworkon. Ifyourmanagersaidordidsomethingwrong,itisacceptableforyoutocorrectand/or constructivelycriticizehim/herfacetoface. Itisacceptableforyoutoexpressdisagreementwithyourmanager(s)withoutfearingtheir retribution. Inagroupmeeting,thecustomersuggestedsomethingabouttheproduct.Youdisagreeandhave abetteridea;itisacceptableforyoutoexpressdisagreementwithyourcustomerandsuggest somethingbetter. Otherpeoplestitlesandpositionsintimidatepeopleintheorganization. Youwoulddoabetterjobchoosingyourowntaskonaprojectinsteadofbeingassignedoneby yourmanager. Youpreferworkinginagroup.

StronglyAgree StronglyAgree StronglyAgree

OR1_D6 OR1_D7 OR1_D8

StronglyAgree StronglyAgree StronglyAgree

OR1_D9 OR1_D10 OR1_D11

StronglyAgree StronglyAgree StronglyAgree

OR1_D12 OR1_D13

Indicatehowoftenyouworkingroups. Wheninagroup,youfeelthatyourparticipationisimportant.

Always StronglyAgree

200

OR1_D14 OR1_D15

Yourmanagerseeksyourinputontechnicalissues. Yourteammembersseekyourinputontechnicalissues.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree StronglyAgree

OR1_D16 OR1_D17 OR1_D18

Whenyourunintotechnicalproblems,youusuallyaskyourteammembersaboutthesolution. Youusuallyparticipateintheplanningprocessoftheprojectyouareworkingon. Projectinformationshouldbecommunicatedtothewholeteam.

StronglyAgree StronglyAgree StronglyAgree

OR1_D19 OR1_D20 OR1_D21

Thereshouldbeamechanismforpersistentknowledgesharingbetweenteammembers. Peopleshoulduseawikiorablogforknowledgesharing. Thereshouldexistacodingstandardfordevelopment. Iftheorganizationhasacodingstandard,thendevelopersshoulduseitwhencoding,evenin crunchtime. Theorganizationvaluesyouandyourexpertise. Yourmanagerhashighexpectationsofyou.

StronglyAgree StronglyAgree StronglyAgree

OR1_D22 OR1_D23 OR1_D24

StronglyAgree StronglyAgree StronglyAgree

OR1_D25 OR1_D26 OR1_D27 OR1_D28 OR1_D29

Youaremotivatedbyyourjob. Youarewillingtodedicatetimeaftereachiteration/releasetoreviewhowtheprocesscouldbe improved. Youarewillingtoundergoaprocesschangeevenifitrequiressomereworkingofalready completedworkproducts. Ifthereisaneedforprocesschange,thatchangeshouldnotbeconsideredaburdenontheteam evenifsignificantprocesschangeshavebeenmadepreviouslyduringtheproject. Processchangeinthemiddleoftheprojectshouldnotbeconsideredadisruptionsincethe processchangeisworththebenefititwillbring.

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree

201

SurveyforManagers/Executives

Indicator OR1_M1

Statements Youactivelyencourageinteractionamongyoursubordinates.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree

OR1_M2 OR1_M3 OR1_M4

Irrelevantofyourpersonalpreferences,youencourageteamworkoverindividualwork. Youusuallyseekyoursubordinatesopinionsbeforemakingadecision. Youfrequentlybrainstormwithyoursubordinates.

StronglyAgree StronglyAgree StronglyAgree

OR1_M5 OR1_M6

Youfrequentlyencourageyoursubordinatestofindcreativesolutionstoproblems. Itisimportantforyoutoshareprojectmanagementinformationwithyoursubordinates. Ifyouareneededandunreachable,atanypointintimeyoursubordinateshaveenough informationtoupdatethecustomerabouttheexactstatusoftheproject. Ifaproblemoccursthatmayaffectthescheduleorrequirementsofaproject,youwouldupdate yourclientrightaway. Developersshouldaidintheplanningofaproject.

StronglyAgree StronglyAgree

OR1_M7 OR1_M8 OR1_M9

StronglyAgree StronglyAgree StronglyAgree

OR1_M10 OR1_M11 OR1_M12

Customersshouldbepartoftheplanningofaproject. Otherpeoplestitlesandpositionsintimidatepeopleintheorganization. Youallowyoursubordinatestochoosetheirowntasksforaproject

StronglyAgree StronglyAgree StronglyAgree

OR1_M13 OR1_M14

Yoursubordinateshaveunregulatedaccesstothecustomer. Youfrequentlyseektheinputofyoursubordinatesontechnicalissues.

StronglyAgree StronglyAgree

202

OR1_M15

Youbelievethatsubordinateswouldperformbetterandbemoreeffectiveiftheyweretochoose theirowntasks. Youalwayscreateplansforasoftwaredevelopmentproject. Itisimportanttoinvolveotherpeoplewhilepreparingtheprojectplan. Theprojectplansarealwaysdocumented. Whenyouprepareaprojectplan,itshouldnotincludethedetailsoftheprojectfromstartto end;itshouldbefocusedonthenextiterationwhilegivinganoverviewoftheoverallwork Projectinformationshouldbecommunicatedtothewholeteam. Thereshouldbeamechanismforpersistentknowledgesharingbetweenteammembers.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree

OR1_M16 OR1_M17 OR1_M18

StronglyAgree StronglyAgree StronglyAgree

OR1_M19 OR1_M20 OR1_M21

StronglyAgree StronglyAgree StronglyAgree

OR1_M22 OR1_M23 OR1_M24 OR1_M25 OR1_M26

Iftherewasawikiorablogsetupforknowledgesharing,youbelievepeoplewoulduseit. Youarewillingtodedicatetimeaftereachiteration/releasetoreviewhowtheprocesscouldbe improved. Youarewillingtoundergoaprocesschangeevenifitrequiressomereworkingofalready completedworkproducts. Ifthereisaneedforprocesschange,thatchangeshouldnotbeconsideredaburdenontheteam evenifsignificantprocesschangeshavebeenmadepreviouslyduringtheproject. Processchangeinthemiddleoftheprojectshouldnotbeconsideredadisruptionsincethe processchangeisworththebenefititwillbring.

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree

203

SurveyforAssessors

Indicator

Statements Oldprojectdocumentsshowthatpreviousprojectshaveaprojectplan. Areviewofdocumentsorotherinformationshowsyouthattheorganizationhasacoding standard. Areviewofthetoolsavailableforusebythedevelopersshowsyouthattheorganizationhas andusesknowledgesharingtools(Wikis,Blogsetc.).

V Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree StronglyAgree StronglyAgree

OR1_A1 OR1_A2 OR1_A3

204

IndicatorMapforAgileLevel2

Existence of Requirements Engineering (M=2,A=1) Experience with Requirements Engineering (M=1,D=1) Managements level of uncertainty avoidance (M=3) Managers Competence with Eliciting Requirements (M=2) Managers Buy-In (M=5) Developers level of uncertainty avoidance (D=2) Developers Buy-In (D=3) Developers Competence (D=2) Existence of Software tools for SCM (A=1) Managers Competence with Multi-level Planning (M=5) Managers Buy-in to Continuous Planning (M=2) Organizations Experience with Multi-level Planning (M=1) Any Software Development Process Exists (M=2,D=2,A=1) Experience with Iterative Development Process (M=2,D=2) Managements level of stress tolerance (M=1) Managers Competence with Incremental Development (M=2) Managers Buy-In (M=2) Developers level of stress tolerance (D=1) Developers Buy-In (D=3) Developers Competence (D=2) Existence of any Monitoring and Reporting (M=2,D=2) Managers Buy-in (M=1) Developers Buy-in (D=1) Previous Design Experience (M=2) Managers Buy-in (M=3) Developers Buy-in (D=3)

Evolutionary Requirements Software Configuration Management Planning at Different Levels

Agile Level 2
Continuous Delivery

Tracking Iteration Progress through Working Software No Big Design Up Front

205

 Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicatorsquestion.

AssessmentTablesforAgilePracticeswithinAgileLevel2

EvolutionaryRequirements

Categoryof Assessment Areatobe assessed Characteristic(s)tobe assessed Existence Experience UncertaintyAvoidance Competence Todetermine: Whetherornottheorganizationhasaninstitutionalized proceduretogatherrequirementsfromitsclients Whetherornottheorganizationhasdevelopedprojectsusing theevolutionaryrequirements Whetherornotmanagementacceptsandiscomfortablewith theuncertaintyinvolvedwithdecidingonrequirementsand featuresaslateaspossible Whetherornotthemanagerscanrecognizehighlevel (architecturallyinfluential)requirementsanddifferentiate themfromdetailrequirements Whetherornotmanagementiswillingtoacceptchangesfrom thecustomerandthatallchangesarereversible Whetherornotmanagementiswillingtotryevolutionary requirementsoverbigupfrontrequirementsgathering Whetherornotthedevelopersacceptandarecomfortable withtheuncertaintyinvolvedwithdecidingonrequirements andfeaturesaslateaspossible Whetherornotthedevelopersarewillingtoacceptchanges fromthecustomerandthatallchangesarereversible Whetherornotthedeveloperscanrecognizehighlevel (architecturallyinfluential)requirementsanddifferentiate themfromdetailrequirements Assessment Method Observation Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing SampleIndicators OR2_A1 OR2_M,OR2_M2 OR2_D1,OR2_M3 OR2_M4,OR2_M5,OR2_M6 OR2_M7,OR2_M8 OR2_M6,OR2_M9,OR2_M0 OR2_M1,OR2_M2 OR2_D2,OR2_D3 OR2_D4,OR2_D7,OR2_D8 OR2_D5,OR2_D6

Process

Requirements Engineering

Management

BuyIn People UncertaintyAvoidance

Developers

BuyIn Competence

SoftwareConfigurationManagement

206

Categoryof Assessment Environment

Areatobe assessed SoftwareTools

Characteristic(s)to beassessed Existence

Todetermine: Whetherornottheorganizationhastoolsforsoftware configurationmanagement

Assessment Method Observation

SampleIndicators OR2_A3

ContinuousDelivery(IncrementalIterativedevelopment)

Categoryof Assessment

Areatobe assessed

Characteristic(s)to beassessed

Todetermine: Whetherornottheorganizationhasanyprocessinplacefor developmentandisnotrelyingonhaphazardandadhoc approachestosoftwaredevelopment Whetherornottheorganizationhaspreviouslyusedan incrementaliterativeapproachfordevelopingsystems Whetherornotmanagementwillbewillingtousean iterativeincrementaldevelopmentapproach Whetherornotmanagerscanhandletheadditionalstressof overseeingthedeliveryofworkableiterationsevery14 weeks Whetherornotthemanagersunderstandtheprinciplesof incrementaliterativedevelopment Whetherornotthedeveloperscanhandlethestressof deliveringaworkableiterationevery14weeks Whetherornotdeveloperswillbewillingtouseaniterative incrementaldevelopmentapproach Whetherornotthedevelopersunderstandtheprinciplesof incrementaliterativedevelopment

Assessment Method Observation Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing Interviewing

SampleIndicators OR2_A2 OR2_D9,OR2_D10, OR2_M13,OR2_M14 OR2_M15,OR2_M16 OR2_D11,OR2_D12 OR2_M17,OR2_M18 OR2_M19 OR2_M20,OR2_M21 D_15 OR2_D13,OR2_D14, OR2_D18 OR2_D16,OR2_D17

ProcessDefinition Process Lifecycle

Existence

Experience BuyIn

Management

Stress

People

Competence
Stress

Developers

BuyIn Competence

Planningatdifferentlevels

Categoryof Assessment People Areatobe assessed Managers Characteristic(s)tobe assessed Competence Todetermine: Whetherornotmanagementunderstandstheprinciplesand significanceofmultilevelplanning Assessment Method Interviewing SampleIndicators OR2_M22,OR2_M23, OR2_M24,OR2_M25,

207

OR2_M26 Whetherornotmanagementiswillingtocommittothe processofcontinuouslyplanningversusdevelopingaone timeplan Whetherornottheorganizationisexperiencedwithmulti levelornot

Buyin Process Planning Experience

Interviewing Interviewing

OR2_M27,OR2_M28 OR2_M29

TrackingIterationProgressthroughWorkingSoftware

Categoryof Assessment Process Areatobe assessed Process Management Managers People Developers Buyin Characteristic(s)to beassessed Monitoring& Reporting Buyin Todetermine: Whetherornotamechanismexiststomonitortheiteration progressismonitored Whetherornotthemanagerscanseethatworkingsoftwareis avalidprogressindicator Whetherornotthedeveloperscanseethatworkingsoftware isavalidprogressindicator Assessment Method Interviewing Interviewing Interviewing SampleIndicators OR2_M30,OR2_D19, OR2_D21,OR2_M31 OR2_M32 OR2_D20

NoBigDesignupFront(BDUF)

Categoryof Assessment Process Areatobe assessed Design Developers People Managers Buyin Characteristic(s)to beassessed Experience Buyin Todetermine: Whetherornotdesignisacontinuousprocess,ordoneonceat thebeginningofthedevelopmentprocess Whetherornotthedevelopersagreetothefactthatnobig designupfrontisavalidandefficientapproachforagile development Whethermanagersagreetothefactthatnobigdesignupfront isavalidandefficientapproachforagiledevelopment Assessment Method Interviewing Interviewing Interviewing SampleIndicators OR2_M36,OR2_M37 OR2_D22,OR2_D23, OR2_D24 OR2_M33,OR2_M34, OR2_M35

208

TheSurveysEncompassingtheIndicators
SurveyforDevelopers

Indicator OR2_D1 OR2_D2 OR2_D3 OR2_D4 OR2_D5 OR2_D6 OR2_D7 OR2_D8 OR2_D9 OR2_D10 OR2_D11 OR2_D12 OR2_D13

Statements Indicatehowoftenareyouinvolvedinaprojectinwhichalltherequirementsarenotknown upfrontandanevolutionaryrequirementsapproachisused. Youarewillingstartadevelopmentofaprojectwithoutknowingtheexactrequirementsofthe wholeproject. Ifcircumstancesdictatethatallthedetailsarenotavailablebeforeyoustartaproject,youdonot mindtheuncertaintyandfloatingtargets. Youdonotmindstartingaprojectknowingthatitsrequirementswillevolveorchangeinthe future. Youcantellthedifferencebetweenrequirementsthatwilltheinfluencethearchitectureand designofaprojectandrequirementsthatwillnotinfluenceit. Inaproject,youcanrecognizehighlevelrequirementsthatmostprobablywillnotchange versuslowlevelrequirementsthatmightchange. Throughouttheprojecttheclienthasfullrighttochangetherequirementsinordertomeet his/herbusinessneeds. Inordertodelivervaluablesoftwaretoclients,changeshouldbewelcomedbutnotconstrained. Softwaredevelopmentinthisorganizationisnotadhocorhaphazard;thereisaclearandknown processinplace. Everyprojectinvolvesaclearsetofactivities.Eachoftheseactivitieshasclearstandardized deliverables. Indicatehowoftenyouhaveworkedonaprojectthatwasdevelopedinanincrementaliterative approach. Itisacommonpracticetodividethesystemupintominiprojects.Thesystemisseldom developedasonelargeproject. Theincrementaliterativeapproachhasmorebenefitsthanthewaterfallapproach.

V Never Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree

W Seldom Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree

NominalValues X Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Usually Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree

Z Always StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree Always StronglyAgree

StronglyAgree

209

OR2_D14 OR2_D15 OR2_D16 OR2_D17 OR2_D18 OR2_D19 OR2_D20 OR2_D21 OR2_D22 OR2_D23 OR2_D24

Youarewillingtousetheincrementaliterativeapproachtodevelopsoftware. Deliveringaworkingincrementevery14weekswillnotcauseyouanyadditionalstress.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree StronglyAgree

Nobigupfrontanalysisshouldbeconductedwhenusingtheincrementaliterativeapproach. Youfullyunderstandtheprinciplesoftheincrementaliterativedevelopmentapproach. Youarewillingtodomoreintegration(integrateaftereachiteration)inordertoaccommodate theincrementaliterativedevelopmentapproach. Theorganizationhasausableandefficientmethodforreportingprojectstatus. Workingsoftwareshouldbetheprimarymeasureofprogressinaproject. Duringdevelopmentyoudeliverasoftwareiteration/releaseatleastoncewithinthe organizationalstatusreportingwindow(usuallyonemonth). Developmentofthefirstiterationcanstartwithoutacompletedetaileddesignofthewhole system. Designcanstartwithoutalltherequirementsbeingknownexceptthosethatarearchitectural influential. Designshouldberevisitedbeforethestartofeachiteration.

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

210

SurveyforManagers/Executives

Indicator OR2_M1 OR2_M2 OR2_M3 OR2_M4 OR2_M5 OR2_M6 OR2_M7 OR2_M8 OR2_M9 OR2_M10 OR2_M11 OR2_M12 OR2_M13 OR2_M14

Statements Theorganizationemployeesknowtheprocedurestogatherrequirementsfromclients.

V Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree

Inanyprojectrequirementsarealwaysgatheredfromthecustomer. Indicatehowoftenyoumanageaprojectinwhichalltherequirementsarenotknownupfront andanevolutionaryrequirementsapproachisused. Youcanstartadevelopmentofaprojectwithoutknowingtheexactrequirementsofthewhole project. Ifcircumstancesdictatethatallthedetailsarenotavailablebeforeyoustartaproject,youdonot mindtheuncertaintyandfloatingtargets. Youdonotmindstartingaprojectknowingthatitsrequirementswillevolveorchangeinthe future. Youcantellthedifferencebetweenrequirementsthatwilltheinfluencethearchitectureand designofaprojectandrequirementsthatwillnotinfluenceit. Inaproject,youcanrecognizehighlevelrequirementsthatmostprobablywillnotchange versuslowlevelrequirementsthatmightchange. Throughouttheprojecttheclienthasfullrighttochangetherequirementsinordertomeet his/herbusinessneeds. Inordertodelivervaluablesoftwaretoclientschangeshouldbewelcomednotconstrained. Anevolutionaryrequirementsgatheringapproachcouldworkbetterthanabigupfront approach. Youarewillingtotryanevolutionaryrequirementsgatheringapproach. Softwaredevelopmentinthisorganizationisnotadhocorhaphazard;thereisaclearandknown processinplace. Everyprojectinvolvesaclearsetofactivities.Eachoftheseactivitieshasclearstandardized deliverables.

StronglyAgree Always StronglyAgree

StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree

211

OR2_M15 OR2_M16 OR2_M17 OR2_M18 OR2_M19 OR2_M20 OR2_M21 OR2_M22 OR2_M23 OR2_M24 OR2_M25 OR2_M26 OR2_M27 OR2_M28 OR2_M29 OR2_M30

Indicatehowoftenyoudevelopaprojectusinganincrementaliterativeapproach. Itisacommonpracticetodividethesystemupintominiprojects.Thesystemisseldom developedasonelargeproject. Theincrementaliterativeapproachhasmorebenefitsthanthewaterfallapproach. Youarewillingtousetheincrementaliterativeapproachtodevelopsoftware.

Never Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree

Seldom Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree

Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree

Usually Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree

Always

StronglyAgree StronglyAgree StronglyAgree

Deliveringaworkingincrementevery14weekswillnotcauseyouanyadditionalstress. Nobigupfrontanalysisshouldbeconductedwhenusingtheincrementaliterativeapproach. Youfullyunderstandtheprinciplesoftheincrementaliterativedevelopmentapproach. Planningtheprojectfrommultiplelevelsorperspectives(iterations,releasesetc)isbetterthan havingoneplanforthewholeproject. Youunderstandtheimportanceofplanningtheprojectintermsofiterationsandreleases. Youcandifferentiatebetweenplanningfeaturesandplanningtasks.

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

Planningforeachiterationshouldoccuronlyrightbeforetheactualiteration. Planningofreleasesshouldnotbedetailed,exceptforthenext/currentrelease. Indicateyourwillingnesstostartaprojectthatisnotcompletelyplannedoutuntiltheend. Indicateyourwillingnesstocommittoplanningsmalliterationandreleasescontinuously throughouttheprojectandnottodeveloponebigplanatthebeginningoftheproject. Indicatehowoftenyoucreatemultilevelplanningdocumentswhenplanningaproject. Theorganizationhasausableandefficientmethodforreportingprojectstatus.

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree Always StronglyAgree

212

OR2_M31 OR2_M32 OR2_M33 OR2_M34 OR2_M35 OR2_M36 OR2_M37

Duringdevelopmentyoudeliverasoftwareiteration/releaseatleastoncewithinthe organizationalstatusreportingwindow(usuallyonemonth). Workingsoftwareshouldbetheprimarymeasureofprogressinaproject. Developmentofthefirstiterationcanstartwithoutacompletedetaileddesignofthewhole system. Designcanstartwithoutalltherequirementsbeingknow,exceptthosethatarearchitectural influential. Designshouldberevisitedbeforethestartofeachiteration. Intheorganization,designisacontinuousprocessthatspansthewholedevelopmenteffortand isnotdoneonlyonetimeupfront. Indicatehowoftentheorganizationdoesnotundertakedesignasabigupfrontactivity,and insteaddesignsinsmallincrementsthroughoutthedevelopmentprocess.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually

StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree Always

SurveyforAssessors

OR2_A1 OR2_A2 OR2_A3

Statements Areviewofpoliciesandproceduresshowsthattheorganizationhasaprocessitusestogather requirementsfromitsclients. Areviewofthepoliciesandproceduresshowsthattheorganizationhasaprocessitusestodevelop software.Thisprocessshouldincludeasetofactivitieswithdeliverablesandstandards. Inspectionofthesoftwaredevelopmentenvironmentshowsthattheorganizationhassufficient anduseableSoftwareConfigurationToolsforagiledevelopment.

V Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree

StronglyAgree StronglyAgree

213

IndicatorMapforAgileLevel3

Managers Competence with Risk Assessment (M=3,D=1) Managers Buy-in (M=1) Developers Buy-in (D=1) Organizations Experience with Risk Assessment (M=1,D=1) Developers Buy-in (D=2) Developers Competence (M=1) Experience with Continuous Improvement (M=2,D=2) Managers Buy-in (M=1) Managers Competence overlooking self-organizing teams (M=5) Developers Buy-in (D=3) Developers Buy-in (D=4) Existence of Software Tools for Continuous Integration (A=1)

Risk Driven Iterations Continuous Improvement (Refactoring) Self-Organizing Teams

Agile Level 3

Continuous Integration Maintenance of a list of all remaining features (backlog) Unit Tests

Managers Buy-in (M=1) Method for tracking remaining work currently exists (M=1,A=1)

Managers Buy-in (M=2) Developers Competence with writing Unit Tests (D=3) Developers Buy-in (D=3) Appropriate tools for writing and running unit tests exists (A=1)

Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicatorsquestion.

214

 AssessmentTablesforAgilePracticeswithinAgileLevel3
RiskDrivenIterations

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Competence Managers People Developers Process RiskAssessment BuyIn BuyIn Experience Todetermine: Whetherornotthemanagersarecompetentriskassessors Whetherornotmanagersagreetohaverisksdrivethescope ofeachiteration Whetherornotthedevelopersagreetohaverisksdrivethe scopeofeachiteration Whetherornottheorganizationhasanyexperiencedoingrisk assessmentornot Assessment Method Interviewing Interviewing Interviewing Interviewing SampleIndicators OR3_M1,OR3_M2, OR3_M3,OR3_D2 OR3_M4 OR3_D3 OR3_M1,OR3_D1

ContinuousImprovement

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Buyin People Developers Competence Process Continuous Improvement Experience Todetermine: Whetherornotthedevelopersagreetoadoptanapproachof continuousimprovementwhiledevelopingsoftware Whetherornotthedevelopersarecompetentenoughto refractorcodewithoutjeopardizingtheexistingfunctionality andqualityofthecode Whetherornottheorganizationisalreadyinvolvedin continuousimprovement Assessment Method Interviewing Interviewing Interviewing SampleIndicators OR3_D4,OR3_D5 OR3_M5 OR3_D6,OR3_D7, OR3_M6,OR3_M7

ContinuousIntegration

Categoryof Assessment People Environment Areatobe assessed Developers SoftwareTools Characteristic(s)to beassessed BuyIn Existence Todetermine: Whetherornotthedevelopersarewillingtocommitto continuousintegration? Whetherornottheorganizationhasthetoolstoaidin continuousintegration Assessment Method Interviewing Observation SampleIndicators OR3_D14,OR3_D15, OR3_D16,OR3_D17 OR3_A1

215

SelfOrganizingTeams

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Buyin Management People Developers Competence BuyIn Todetermine: Whetherornotmanagementagreestohaveselforganizing teams Whetherornotmanagementisreadytotreattheteamasa trueselforganizingteam Whetherornottheemployeesfeelcomfortableworkingas selforganizingteams Assessment Method Interviewing Interviewing Interviewing SampleIndicators OR3_M11 OR3_M8,OR3_M10, OR3_M9,OR3_M12, OR3_M13 OR3_D8,OR3_D9, OR3_D10

MaintenanceofaListofAllRemainingFeatures(Backlog)

Categoryof Assessment People Areatobe assessed Management Characteristic(s)to beassessed Buyin Todetermine: Whetherornotmanagementiswillingtomaintainanupto datelistofalltheremainingfeaturesfortheproject(backlog) Whetherornottheorganizationcurrentlykeepsanuptodate listofalltheworkthatremainstobedone Assessment Method Interviewing Interviewing Observation SampleIndicators OR3_M16 OR3_M15 OR3_A2

Process

Project Management

Existence

UnitTests

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Buyin Developers People Managers Environment SoftwareTools Competence BuyIn Existence Todetermine: Whetherornotdevelopersarewillingtowriteunittests duringthedevelopmentprocess Whetherornotthedevelopershavethecompetenceand previousexperiencewritingunittests Whetherornotthemanagementacceptsthatdeveloperswill investadditionaltimetowriteunittestswhilecoding Whetherornottheorganizationhasthetoolsthatsupport writingandrunningunittests Assessment Method Interviewing Interviewing Interviewing Observation SampleIndicators OR3_D18,OR3_D19, OR3_D21 OR3_D20,OR3_M19, OR3_D22 OR3_M17,OR3_M18 OR3_A3

216

TheSurveysEncompassingtheIndicators
SurveyforDevelopers

Indicator OR3_D1 OR3_D2 OR3_D3 OR3_D4 OR3_D5 OR3_D6 OR3_D7 OR3_D8 OR3_D9 OR3_D10 OR3_D11 OR3_D12

Statements Fortheprojectsthatyouhaveworkedon,indicatehowoftenriskassessmentwasperformed duringtheprojectandcommunicatedtothewholeteam. Yourmanagerisverycompetentwhencomingtoriskassessmentsandmitigationplans. Theriskiest,mostdifficultelementsshouldbeapproachedfirstintheearlyiterationsofthe developmenteffort. Itisimportanttoputeffortintoimprovingthedesignandcodeofacomponent,evenifitisalready working. Youarewillingtoadoptanapproachofcontinuousimprovementduringsoftwaredevelopment. Itisacommonpracticeintheorganizationtorevisitaworkingcomponenttoimproveitsdesignor codestructure. Indicatehowoftenyourevisitaworkingcomponenttoimproveitsdesignorcodestructure. Youliketoworkonateamthatmanagementregardsasoneentity;notaddressingindividualteam membersinrewardsortasks,butasoneteam. Youdonotmindworkingwithoutdirectmanagerialsupervisionaslongasyouareonateamthatis treatedasapartnerwithmanagement. Youconsideryourselfcompetentanddisciplinedenoughtoworkonselforganizingteams IndicatehowoftenyoudevelopsoftwareprojectsusingtheObjectOriented(OO)principlesand techniques. YouunderstandtheOOprinciplesandtheoriesverywell.

V Never Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree

W Seldom Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree

NominalValues X Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree

Y Usually Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree

Z Always StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

Always StronglyAgree StronglyAgree

StronglyAgree Always StronglyAgree

217

OR3_D13 OR3_D14 OR3_D15 OR3_D16 OR3_D17 OR3_D18 OR3_D19 OR3_D20 OR3_D21 OR3_D22

IndicatehowoftentheorganizationtakestheOOapproachindevelopmentofsoftwareprojects. Theusualtimeittakestocreateabuildthesystemis: Insteadofintegratingthesystemattheendofthedevelopmenteffort,itisbettertoregularly integratethesystemthroughoutthewholedevelopmentprocess. YouaretrainedtousetheSoftwareConfigurationManagementtoolforcontinuousintegration. Youarewillingtointegrateyoursoftwarethroughoutthedevelopmentprocess,evenifitmeans moreworkforyou. Itisimportanttowriteunittestsformethodsandfunctionswhilecodingthemevenifthatwilltake additionaltime. Writingunittestsforcodeisasimportantaswritingnewcodeformorefunctionality. Indicatehowoftenyouwriteunittestsforeverymethodorfunctioninyourcode. Youarewillingtocommittowritingunittestswhileyoucodeforeverymethodorfunctioninyour code. Youconsideryourselfcompetentenoughtowritegoodandcomprehensiveunittestsforthe methodsandfunctionsinyourcode.

Strongly Disagree Morethan1 hour Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree

Tendto Disagree Under1 hour Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree Under15minutes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Under10 minutes Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree

StronglyAgree Under5 minutes StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree Always

StronglyAgree Strongly Agree

218


SurveyforManagers/Executives

Indicator

Statements Indicatehowoftendoyouperformriskassessmentandmitigationtechniquesduringaproject.

V Never Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never

W Seldom Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom

NominalValues X Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes

Y Usually Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually

Z Always

OR3_M1 OR3_M2 OR3_M3 OR3_M4 OR3_M5 OR3_M6 OR3_M7 OR3_M8 OR3_M9 OR3_M10 OR3_M11 OR3_M12 OR3_M13 OR3_M14

Youhavebeentrainedtoperformriskassessments. Youareverycompetentperformingriskassessmentandmitigationplans. Theriskiest,mostdifficultelementsshouldbeapproachedfirstintheearlyiterationsofthe developmenteffort. Thedevelopersarecompetentenoughtorefractorcodewithoutjeopardizingtheexisting functionalityandqualityandbreakinganyunittests(iftheyexist). Itisacommonpracticeintheorganizationtorevisitaworkingcomponenttoimproveitsdesign orcodestructure. Indicatehowoftenyoumakesurethatyoursubordinatesrevisitaworkingcomponentto improveitsdesignorcodestructure. Youcantrustyouremployeescapabilitiestodeterminethebestwaytoaccomplishtasksby themselveswithoutyour(managements)interference. Employeesarecompetentanddisciplinedenoughtoworkinselforganizingteams.

StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

Always StronglyAgree StronglyAgree

Youarewillingtoallowspacefortheselforganizingteamtogrowandnotmicromanageit. Youagreethatitisveryimportantfortheemployeestoworkinteamswheretheycandividethe teamtasksamongthemselves. Theteamisanentitythathasitsknowledge,perspective,motivationandexpertiseandshould betreatedasapartnerwithmanagementandthecustomer. Theselforganizingteamcannegotiatecommitments. IndicatehowoftenyourorganizationtakestheOOapproachinsoftwaredevelopment

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree Always

219

OR3_M15 OR3_M16 OR3_M17 OR3_M18 OR3_M19

Whenworkingonaprojectyoukeepanuptodatelistofalltheworkthatremainstobedone. Youarewillingtokeepanuptodatelistofalltheworkthatremainstobedone. Itisimportantfordeveloperstowriteunittestsfortheirmethodsandfunctionswhiletheycode, evenifthatwilltakeadditionaltimefromthem. Writingunittestsforcodeisasimportantaswritingnewcodeformorefunctionality. Thedevelopersarecompetentenoughtowritegoodunittestsforthemethodsandfunctionsin thecode.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

SurveyforAssessors

OR3_A1 OR3_A2 OR3_A3

Statements Afterlookingatthesoftwaredevelopmenttools,youknowthattheorganizationhastheSCMtools andprocessestosupportcontinuousintegration. Afterinspectingpreviousprojects,youknowthateachprojecthadamechanismbywhichallthe remainingworkinaprojectwasknownatanypointintime. Afterlookingatthesoftwaredevelopmenttools,youknowthattheorganizationhasthenecessary toolstowriteandrununittestswithinthedevelopmentIDE.

V Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree StronglyAgree StronglyAgree

220

IndicatorMapforAgileLevel4

Client Driven Iteration Continuous Customer Satisfaction Feedback

Managers Buy-in (M=3) Method to obtain customer feedback exists (M=2) Managers Buy-in (M=3) Developers Buy-in (D=3) Managements level of stress tolerance (M=1) Managers Buy-In (M=1) Developers level of stress tolerance (D=1) Developers Buy-In (D=1) Managers Buy-in (M=2) Regular progress meeting currently exists (M=1,D=1) Managers Buy-in (M=1) Developers Buy-in (D=1) Managers Buy-in (M=1) Developers understanding of agile documentation (D=2) Managers understanding of agile documentation (M=2) External Regulations (M=2) Managers Buy-in (M=2) Developers Competence writing User Stories (D=1) Regulations related to format of requirements (M=1)

Smaller and more frequent Releases

Agile Level 4

Adaptive Planning Daily Progress Tracking Meetings

Agile Documentation

User Stories

Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicatorsquestion. 221

AssessmentTablesforAgilePracticeswithinAgileLevel4

ClientDrivenIterations

Categoryof Assessment People Areatobe assessed Managers Characteristic(s)to beassessed Buyin Todetermine: Whetherornotmanagersarewillingtogivethecustomerthe powertodictatethescopeoftheiterations Assessment Method Interviewing SampleIndicators OR4_M1,OR4_M2, OR4_M3

ContinuousCustomerSatisfactionFeedback

Categoryof Assessment Process

Areatobe assessed Customer Feedback Developers

Characteristic(s)to beassessed Existence Buyin Buyin

Todetermine: Whetherornottheorganizationhasamethodbywhichthey gathercontinuousfeedback/criticismfromthecustomer duringthedevelopmentprocess Whetherornotthedevelopersacceptthefactthatthe customersareencouragedtocontinuallyrethinktheir requirements Whetherornotthemanagersacceptthefactthatthe customersareencouragedtocontinuallyrethinktheir requirements

Assessment Method Interviewing Interviewing Interviewing

SampleIndicators OR4_M4,OR4_M5 OR4_D1,OR4_D2, OR4_D3 OR4_M2,OR4_M6, OR4_M7

People Managers

222

SmallerandmoreFrequentReleases

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Buyin Managers Stress People Buyin Developers Stress Todetermine: Whetherornotthemanagersunderstandtheimportanceof havingsmallerandmorefrequentreleasestogivethe customerquickerfeedback Whetherornotmanagerscanhandletheadditionalstressof overseeingthedeliveryoffullyfunctionalreleasesevery48 weeks Whetherornotthedevelopersunderstandtheimportanceof havingsmallerandmorefrequentreleasestogivethe customerquickerfeedback Whetherornotthedeveloperscanhandletheincreasedstress ofdeliveringfullyfunctionalreleasesevery48weeks Assessment Method Interviewing Interviewing Interviewing Interviewing SampleIndicators OR4_M12 OR4_M13 OR4_D8 OR4_D9

AdaptivePlanning

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Todetermine: Whetherornotmanagementiswillingtobasetheplanningfor thenextiterationontheclientsfeedbackfromthecurrent (previous)iteration Whetherornotmanagementiswillingtoplanaslateas possibleforaniteration(immediatelybeforetheiteration) Assessment Method Interviewing Interviewing SampleIndicators OR4_M14 OR4_M15

People

Management

Buyin

DailyProgressTrackingMeetings

Categoryof Assessment Areatobe assessed Management People Developers BuyIn Characteristic(s)to beassessed BuyIn Todetermine: Whetherornotmanagementiswillingtomeetdailyfor progressupdate Whetherornotthedevelopersarewillingtomeetdailyfor progressupdates Assessment Method Interviewing Interviewing SampleIndicators OR4_M16 OR4_D10

223

Process

Project management

Progressmeetings

Howoftentheteammeetsregularlytodiscusstheprogressof aproject

Interviewing

OR4_M17,OR4_D11

AgileDocumentation(fromAgileModeling)

Categoryof Assessment Areatobe assessed Developers People Management BuyIn Process Documentation Regulations Characteristic(s)to beassessed Competence Competence Todetermine: WhetherornotthedevelopersunderstandwhatanAgile approachtodocumentationis WhetherornotmanagementunderstandswhatanAgile approachtodocumentationis WhetherornotmanagementiswillingtotakeanAgile approachtodocumentation Whetherornotexternalregulatoryrequirementsexistthat dictatetheproductionofheavy(detailed)documentationfor everyaspectoftheprocess Assessment Method Interviewing Interviewing Interviewing Interviewing SampleIndicators OR4_D12,OR4_D13 OR4_M18,OR4_M19 OR4_M20 OR4_M21,OR4_M22

UserStories

Categoryof Assessment Areatobe assessed Management People Developers Process Requirements Competence Regulations Characteristic(s)to beassessed BuyIn Todetermine: Whetherornotmanagementiswillingtouseuserstoriesas anelicitationmethod/formforhighlevelrequirements Whetherornotthedevelopershavethe understanding/knowledgeofhowtouseuserstories Whetherornotthereareregulatoryrequirementsforthe elicitationoftherequirements(theyhavetospecifiedina certainform) Assessment Method Interviewing Interviewing Interviewing SampleIndicators OR4_M23,OR4_M24 OR4_D14 OR4_M25

224

TheSurveysEncompassingtheIndicators
SurveyforDevelopers

Indicator

Statements Customersshouldbeencouragedtoregularlychangetheirexpectationsfortheproductbeing developedtoensurethattheproductsatisfiesthebusinessprioritiesoftheorganization. Astheperceptionofwhattheyneedchanges,customersareexpectedtoarticulatethesechanges andthusaffecttheproductbeingbuilt. Thecustomershouldgivehis/herfeedbackthroughoutthedevelopmentprocessevenifitmeans thatrequirementsmustbechanged. Smallerandmorefrequentreleasesareimportantinordertogivethecustomerameansby whichhe/shecangivemoreandquickerfeedback. Deliveringsmallerandmorefrequentfullyfunctionalreleasesevery48weekswillnotcause youanyadditionalstress. Youarewillingtomeetdailytocheckinandsynchronizeeffortswithyourteammembers. Indicatehowoftenyoumeetwiththerestoftheteamtodiscussandupdateeachotheraboutthe progressoftheproject. DocumentationexistswithinanAgiledevelopmentprocess YouunderstandtheroleofdocumentationwithinanAgiledevelopmentprocess Youcanuseuserstoriesinsteadofrequirementstodevelopthearchitecturalframeworkofthe system.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Lessfrequent thanmonthly Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Monthly Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Everycoupleof weeks NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Weekly Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree

OR4_D1

OR4_D2 OR4_D3 OR4_D8 OR4_D9 OR4_D10 OR4_D11 OR4_D12 OR4_D13 OR4_D14

StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

Daily/Hourly StronglyAgree StronglyAgree

StronglyAgree

225

SurveyforManagers/Executives

Indicator

Statements Astheperceptionofwhattheyneedchanges,customersareexpectedtoarticulatethosechanges byprioritizingthefeaturestheywouldliketoseeinthenextiteration. Customersshouldbeencouragedtoregularlychangetheirexpectationsfortheproductbeing developedtoensurethattheproductsatisfiesthebusinessprioritiesoftheorganization. Thecustomershouldbegiventheauthoritytodirectwhatisbeingdevelopedinwhichiteration. Thecustomerhastheopportunitytogivehis/herfeedbackabouttheproductthroughoutthe developmentprocessbymeansofinteractingwithaworkingpieceofsoftwareoraleasta prototype. Theorganizationhasamethodbywhichitgatherscontinuousfeedback/criticismfromthe customerduringthedevelopmentprocess. Astheperceptionofwhattheyneedchanges,customersareexpectedtoarticulatethosechanges andsoaffecttheproductbeingbuilt. Thecustomershouldgivehis/herfeedbackthroughoutthedevelopmentprocessevenifitmeans thatrequirementsmustbechanged. Smallerandmorefrequentreleasesareimportantinordertogivethecustomerameansby whichhe/shecangivemoreandquickerfeedback. Deliveringsmallerandmorefrequentfullyfunctionalreleasesevery48weekswillnotcause youanyadditionalstress. Theplanforupcomingiterationmaychangebasedoncustomerfeedbackfromthepreviousor currentiteration. Youagreewithdevelopingthedetailedplanforaniterationonlyaftertheconclusionofthe previousiteration. Youarewillingtomeetdailyfortheprogressupdateofaproject. Indicatehowoftenyoumeetwiththerestoftheteamtodiscussandupdateeachotheronthe progressoftheproject. DocumentationexistswithinanAgiledevelopmentprocess.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Lessfrequent thanmonthly Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Monthly Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Everycoupleof weeks NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Weekly Tendto Agree

Z StronglyAgree StronglyAgree

OR4_M1 OR4_M2 OR4_M3 OR4_M4 OR4_M5 OR4_M6 OR4_M7 OR4_M12 OR4_M13 OR4_M14 OR4_M15 OR4_M16 OR4_M17 OR4_M18

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree Daily/Hourly StronglyAgree

226

OR4_M19 OR4_M20 OR4_M21 OR4_M22 OR4_M23 OR4_M24 OR4_M25

YouunderstandtheroleofdocumentationwithinanAgiledevelopmentprocess.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree

YouwillallowyoursubordinatestotakeanAgileapproachtodocumentation. Stakeholdersdonotrequireheavy(detailed)documentationforanyactivitiesoraspectsofthe developmentprocess. Youarenotrequiredbyanyexternalauditorytomaintainfineheavy(detailed)documentation foractivitiesoraspectsofthedevelopmentprocess. Youarewillingtoadoptuserstoriesasamethodforhighlevelrequirementselicitation. Userstoriescanbeusedinsteadoflargerequirementsdocuments. Noregulatoryconstraintsexistthatpreventtheuseofuserstoriesasameansofcapturinghigh levelrequirementsfromtheuser.

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

227

IndicatorMapforAgileLevel5

Process regulations related to ceremony (M=2,A=1) Fear of responsibility among people (M=1) Managers Buy-In (M=2) Managements trust to the Developers (D=2) Developers Buy-In (D=2) Availability Historical Projects Estimations (A=1) Experience with Estimation (A=1) Current Estimation method (M=2) Managers Competence with Estimation (M=3) Developers Competence with Estimation of efforts (D=3) Managements level of Collaboration (M=3) Managers Buy-In (M=2) Developers Buy-In (D=3) Measure of productivity (M=1) Collaborative Organizational Culture (M=1,D=2) Developers Competence with unit tests (D=5,M=1) Developers Perception (D=1) Developers Buy-In (D=1) Managers Buy-In (M=2) Availability of Automation tools for testing (M=1,A=1)

Low Process Ceremony

Agile Project Estimation

Agile Level 5
Paired Programming

Test Driven Development

Thenumberofwithintheparenthesisindicatorsdenotesthenumberofindicatorsusedtomeasuretherelatedorganizational characteristic.Theletterprecedingthenumberofindicatorsdenoteswhoshouldprovidetheanswertotheindicatorsquestion.

228

AssessmentTablesforAgilePracticeswithinAgileLevel5

LowProcessCeremony(ProcessCeremonyisthelevelofpaperworkinvolvedwithaprocess)

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Todetermine: Assessment Method Interviewing Observation Interviewing Interviewing Interviewing Interviewing SampleIndicators OR5_M1,OR5_M2 OR5_A1 OR5_M3 OR5_D1,OR5_D2 OR5_M4,OR5_M5 OR5_M6,OR5_M7

Process

Ceremony

Regulations

Whetherornottheorganizationneedstomaintainahigh processceremonyduetocertainauditsorregulations Whetherornotthereisafearofresponsibility/blameamong people,thussupportingthehighlevelofprocessceremony Whetherornotthedevelopersfeelcomfortabledecreasingthe levelofprocessceremony Whetherornotthemanagersfeelcomfortabledecreasingthe levelofprocessceremony Whetherornotthemanagementtruststhedevelopersto makedecisionsontheirownwithouttheirapproval

Culture

Organizational Developers

Responsibility Buyin Buyin

People Management

Trust

AgileProjectEstimation

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Experience Process Estimation Existence Method Developers People Management Management Competence Competence Collaboration Todetermine: Whetherornottheorganizationisexperiencedinestimation Whetherornotdataexistsfrompreviousprojectstoaidwith theestimation Whetherornottheestimationprocessseparatesthe estimationofeffortfromtheestimationofduration Whetherornotthedevelopersarecompetentinmakingtheir ownestimatesofeffort. Whetherornotthemanagersarecompetentinmaking estimates. Whethermanagementwillencouragetheestimationprocess tobedonebythewholeteamorbyonlythem Assessment Method Observation Observation Interviewing Interviewing Interviewing Interviewing SampleIndicators OR5_A2 OR5_A3 OR5_M8,OR5_M9 OR5_D3,OR5_D4, OR5_D5 OR5_M10,OR5_M11, OR5_M12 OR5_M13,OR5_M14, OR5_M15

229

PairedProgramming

Categoryof Assessment Areatobe assessed Management People Developers Process Culture Project Management Organizational Buyin Measurementof Productivity Collaboration Characteristic(s)to beassessed Buyin Todetermine: Whetherornotmanagementcanseethebenefitfrompaired programming Whetherornotdevelopersarewillingtotrypaired programming Whattheorganizationconsiderstobeameasureofsoftware productivity Whetherornotanatmosphereofassistanceexistsinthe organization Assessment Method Interviewing Interviewing Interviewing Interviewing SampleIndicators OR5_M16,OR5_M17 OR5_D6,OR5_D7, OR5_D8 OR5_M18 OR5_D9,OR5_D10, OR5_M19

TestDrivenDevelopment

Categoryof Assessment Areatobe assessed Characteristic(s)to beassessed Todetermine: Whetherornotthedevelopersarecompetentand experiencedwithwritingunittests Whetherornotthedevelopershaveaverystrong understandingofOOconcepts Whetherornotthedevelopersaremotivatedandwillingto applytestdrivendevelopment WhetherornotthedevelopersthinkthatTestdriven developmentisahardtaskornot Whetherornotmanagementwillencouragetestdriven developmentandtoleratethelearningcurve Whetherornottheorganizationhasorcanprovidetoolsfor creatingandmaintainingautomatedtestsuites Assessment Method Interviewing Interviewing Interviewing Interviewing Interviewing Observation Interviewing SampleIndicators OR5_D11,OR5_D12, OR5_D13 OR5_D14,OR5_D15, OR5_M20 OR5_D16 OR5_D17 OR5_M21.OR5_M22 OR5_A4 OR5_M23

Competence Developers People BuyIn Perception Management BuyIn

Environment

SoftwareTools

TestAutomation

230

TheSurveysEncompassingtheIndicators
SurveyforDevelopers

Indicator

Statements Youfavoracceptingresponsibilityandbeingheldaccountablewhenthingsgowrongover multiplelayersofformalsteps,reviews,andprocedures. Youdonotsupporttheexistenceofvariousformalstepsandreviewstoreduce(spread) accountabilitywhensomethinggoeswrong. Indicatehowoftenyoumakesize/effortestimatesfortheprojectoracomponentoftheproject thatyouwillbeworkingon. Youhavebeentrainedonhowtomakefeatureestimates. Youarecompetentenoughtomakeyourownestimatesofsize/effort. Pairedprogrammingincreasesproductivitycontrarytowhatotherssayaboutpaired programmingdecreasingproductivitybyhalf. Indicatehowoftenyouprograminpairs. Youarewillingtoprograminpairs. Anatmosphereofassistanceexistsintheorganization.

V Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree

W Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree

Z StronglyAgree StronglyAgree Always

OR5_D1 OR5_D2 OR5_D3 OR5_D4 OR5_D5 OR5_D6 OR5_D7 OR5_D8 OR5_D9 OR5_D10 OR5_D11 OR5_D12

StronglyAgree StronglyAgree StronglyAgree

Always StronglyAgree StronglyAgree

Wheneveryouneedhelppeoplearewillingtohelpyou. Indicatehowoftenyouwriteunittestsforeveryfunctionormethodonewritingcode. Youhavenoproblemsorchallengeswritingunittestsforfunctionsandmethods.

StronglyAgree Always StronglyAgree

231

OR5_D13 OR5_D14 OR5_D15 OR5_D16 OR5_D17

Thesuiteofunitteststhatyouwriteiscomprehensiveandusuallyencompassesallpossibletest scenarios. Indicatehowoftenyouprogramintheobjectoriented(OO)paradigm.

Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree

StronglyAgree Always

Youhaveaverystrongunderstandingofobjectorientedconceptsandprinciples. Youarewillingtoemployatestdrivenapproachtodevelopment. Testdrivendevelopmentiseasy.

StronglyAgree StronglyAgree StronglyAgree

SurveyforAssessors

Indicator OR5_A1 OR5_A2 OR5_A3 OR5_A4

Statements Areviewofpoliciesandproceduresshowsthatthereisnoneedforahighprocessceremonyin thisorganization. Areviewofpreviousprojectdocumentationshowsthattheeffortestimateswerewithin acceptablerangetotheactualeffortthatwasputintodeliveringtheproject. Previousprojectdocumentation,includingeffortandsizeestimations,areavailableand accessible. Aninspectionofthesesoftwaretoolsshowsthattheorganizationhasaccessibleandusabletools forcreatingandmaintainingautomatedtestsuites.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree

Z StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

232

SurveyforManagers/Executives

Indicator OR5_M1 OR5_M2 OR5_M3 OR5_M4 OR5_M5 OR5_M6 OR5_M7 OR5_M8 OR5_M9 OR5_M10 OR5_M11 OR5_M12 OR5_M13 OR5_M14 OR5_M15

Statements Therearenoregulationsorauditoryrequirementsthatdictatetheneedforhighprocess ceremony. Yourorganizationisinformalandflexible.Therearenotmanyformalsteps,policiesor procedures. Peopleintheorganizationarenotafraidoftakingresponsibility. Youfavoracceptingresponsibilityandbeingheldaccountablewhenthingsgowrongover multiplelayersofformalsteps,reviews,andprocedures. Youdonotsupporttheexistenceofvariousformalstepsandreviewstoreduce(spread) accountabilitywhensomethinggoeswrong. Youtrustyoursubordinatestomakedecisionswithintheirscopeofworkwithoutreferringback toyouforapproval. Yoursubordinatesarecompetenttomaketheirowndecisionswithoutreferringbacktoyoufor approval. Whenpreparingaprojectestimation,youestimatethesizefirstandderivefromthataduration estimate. Theestimationprocessemployedbytheorganizationseparatestheestimationofeffortfromthe estimationofduration. Indicatehowoftenyoumakesize/effortestimatesforprojects.

V Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree Strongly Disagree Strongly Disagree Never Strongly Disagree

W Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree Tendto Disagree Tendto Disagree Seldom Tendto Disagree

NominalValues X NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree Sometimes NeitherAgreenor Disagree

Y Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree Tendto Agree Tendto Agree Usually Tendto Agree

Z StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

StronglyAgree StronglyAgree Always

Youhavebeentrainedonhowtomakeprojectestimates. Youarecompetentandexperiencedenoughtomakerealisticestimatesofsize/effort. Thewholeteamparticipatinginprojectestimationwillyieldbetterandmoreaccurateresults.

StronglyAgree StronglyAgree StronglyAgree

Indicatehowoftenthewholeteamhasparticipatedincreatingprojectestimates. Youwillencouragethewholedevelopmentteamtoactivelyparticipateindevelopingaproject estimate.

Always StronglyAgree

233

OR5_M16 OR5_M17 OR5_M18 OR5_M19 OR5_M20

Paired programming increases productivity contrary to what others say about paired programmingdecreasingproductivitybyhalf. Youencourageyourdevelopmentteamtousepairedprogramming. Productivityisabouthowmuchcustomervaluecanyoucreateperdollarspentnotabouthow manylinesofcode,classescodedorUseCasesperdollarspent. Anatmosphereofassistanceexistsintheorganization. Thedevelopmentteamhasaverystrongunderstandingofobjectorientedconceptsand principles. Testdrivendevelopmentwillproducebettersoftwarewithfewerbugs Youarewillingtotoleratethelearningcurveofthedevelopmentteamwhiletheytransitionto testdrivendevelopment. Theorganizationwillbewillingtoprovidesoftwaretoolsforcreatingandmaintaining automatedtestsuites.

Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree Strongly Disagree

Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree Tendto Disagree

NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree NeitherAgreenor Disagree

Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree Tendto Agree

StronglyAgree StronglyAgree

StronglyAgree StronglyAgree StronglyAgree

OR5_M21 OR5_M22 OR5_M23

StronglyAgree StronglyAgree StronglyAgree

234

Appendix B: Empty and Completed Surveys

This appendix includes the surveys used during the substantiation process and the results obtained. First an empty 2-page survey, used to gather high-level feedback about the measurement index and the 4-stage process, is presented. It is proceeded by 28 completed surveys. Then an empty 12-page survey which was used for gathering detailed feedback is presented along with 2 ones that were completed.

235

Empty 2-Page Survey (Overview)

VIRGINIA POLYTECHNIC INSTITUTE AND STATE UNIVERSITY Assessment Questionnaire: Process for Adoption of Agile Practices in Projects

Date:

Reference # (for archiving purposes): SECTION 1: ASSESSORS INFORMATION

Name (Optional): Organization / Institute: Official Position: Email : Years in position : Phone Number :
Not familiar None Never None

Please rate your familiarity with Agile software development Please rate your highest level of involvement in development efforts that used Agile practices How frequently have you aided entities in adopting Agile practices Please rate your level of familiarity with general process assessment and/or process improvement

2 2 2 2

3 3 3 3

somewhat familiar participant occasionally participant

5 5 5 5

6 6 6 6

expert leader constantly leader

SECTION 2: AGILE LEVELS

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

COMPREHENSIVENESS The 5 Agile Levels are comprehensive enough to depict the various states and levels most organizations could be at relative to agility? The 5 Agile Levels are defined in a valid and logical order? PRACTICALITY One of our objectives is to make sure that the agile levels are practical and can be used in industry. In light of this, to what extent would you agree that these Agile Levels can be used to classify, and/or aid in the transition of, currently employed software development efforts? NECESSITY The classification of agility into five Agile Levels as presented would be beneficial to the software engineering industry? RELEVANCE Each of the Agile Levels presented encompass a set of agile practices and concepts. To what extent would you agree that those practices and concepts are relevant and correctly assigned to their respective agile levels? Would you add, remove or redefine any of the 5 agile levels? If so please explain why.

Do you of any further comments about the Agile Levels?

SECTION 3: THE OVERALL PROCESS FRAMEWORK

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable Overall objective of this process framework Discontinuing Factors 5 Agile Levels Project Level Assessment Organizational Assessment Gap Analysis PRACTICALITY One of our objectives is to make sure that the process framework is practical and can be used in industry. In light of this to what extent would you agree that process framework would be practical and feasible to employ? NECESSITY The process framework is beneficial to the software engineering industry? COMPLETENESS All the necessary components are present in this process framework in order to achieve its overall goal of aiding an organization in the adoption of agile development for its various projects? The steps and activities in the process framework are organized in a logical and valid sequence in order to achieve its overall goal of an assisting agile adoption? EFFECTIVENESS To what extent do you agree that each of the components in this process framework is necessary and sufficient for the framework to achieve its purpose? Discontinuing Factors 5 Agile Levels Project Level Assessment Organizational Assessment Gap Analysis Would you add, remove or redefine any components of this process framework? If so please explain why.

Do you have any additional comments about the process framework?

SECTION 5: FURTHER EVALUTION Would you like to participate in an extensive, more detailed, evaluation of this research? YES NO MAYBE

Completed 2-page Surveys (Overview)

Empty 12-Page Survey (Detailed)

VIRGINIA POLYTECHNIC INSTITUTE AND STATE UNIVERSITY Assessment Questionnaire: Process for Adoption of Agile Practices in Projects

Date:

Reference # (for archiving purposes): ASSESSORS INFORMATION

Name (Optional): Organization / Institute: Official Position: Email : Years in position : Phone Number :
Not familiar None Never None

Please rate your familiarity with Agile software development Please rate your highest level of involvement in development efforts that used Agile practices How frequently have you aided entities in adopting Agile practices Please rate your level of familiarity with general process assessment and/or process improvement

2 2 2 2

3 3 3 3

somewhat familiar participant occasionally participant

5 5 5 5

6 6 6 6

expert leader constantly leader

1. STAGE 1: DISCONTINUING FACTORS (PAGES 5-9)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The 4 discontinuing factors The assessment table for each of the discontinuing factors The sample indicators LEVEL OF DETAIL To what extent do you agree that the material about discontinuing factors is presented at a sufficient level of detail? EFFECTIVENESS To what extent do you agree that the 4 discontinuing factors are sufficient to fulfill the objective of identifying all the major showstoppers that might be present before adopting an agile process? PRACTICALITY One of our objectives is to make sure that the proposed assessment framework and indicators are practical and can be used in industry. In light of this to what extent would you agree that these factors and indicators can be used practically? RELEVANCE Each of the discontinuing factors is associated with the set of sample questions or indicators. To what extent do you agree that those sample indicators are relevant and valid for the assessment of the discontinuing factors? Would you add or remove any factors from the proposed set of discontinuing factors? If so please explain why.

Do you have any further comments about the discontinuing factors presented in this section

2. STAGE 2: PROJECT LEVEL ASSESSMENT (PAGES 10-16)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The idea behind assessing project-level agile constraints (project-level assessment) The actual constraining agile practices and concepts that are assessed for each of the five agile levels The sample indicators and questionnaires used for the assessment of the constraining agile practices and concepts LEVEL OF DETAIL To what extent do you agree that the material about project level assessment is presented at a sufficient level of detail? COMPREHENSIVENESS Project characteristics related to agility can differ from one project to another even within the same organization. To what extent do you agree that the factors identified in the section about project-level assessment are outside the projects or organizations control To what extent do you agree that the factors presented in this section sufficiently represent all project characteristics that could constrain the potential level of agility of any project? PRACTICALITY One of our objectives is to make sure that the project level agile characteristics identified in this section is truly reflective of what can be encountered in industry. In light of this to what extent would you agree that these project level agile characteristics would in real life constrain the level of agility that a project may aspire to? To what extent do you agree to the importance of assessing project level agile characteristics in order to determine the highest level of agility a project may hope to adopt? RELEVANCE Each of the project level agile characteristics presented in this section was associated to one of the five agile levels. To what extent do you agree that the project level agile characteristics were identified from their correct and relevant agile level? Would you add or remove any project level agile characteristics? If so please explain why.

Do you of any further comments about the project level agile characteristics?

3.1 STAGE 3: ORGANIZATIONAL READINESS FOR AGILE LEVEL 1 (PAGES 18-25)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The objective or theme of Agile Level 1 The agile practices and concepts identified in Agile Level 1 The sample indicators and questions related to each agile practice or concept LEVEL OF DETAIL To what extent do you agree that the material about Agile Level 1 is presented at a sufficient level of detail? PRACTICALITY One of our objectives is to make sure that the Agile Levels are practical and can be used in industry. In light of this to what extent would you agree that if the agile practices and concepts presented in agile level 1 were used during the project that they would enhance the overall communication and collaboration? To what extent do you agree that the results of the questionnaires (indicators) legitimately reflect the readiness of the organization to adopt the agile practices and concepts identified in agile level 1? EFFECTIVENESS To what extent do you agree that the agile practices and concepts identified in Agile Level 1 are sufficient enough to achieve the objective of this agile level which is enhancing communication and collaboration? To what extent would you agree that the first level of agility should focus on enhancing communication and collaboration? RELEVANCE To what extent do you agree that the agile practices in Agile Level 1 are relevant to their associated agile principals? Collaborative planning Collaborative teams Empowered and motivated teams Coding standards Knowledge-Sharing tools Task volunteering not task assignment For each of the agile practices and concept in this level, to what extent do you agree that the sample indicators and questions are relevant and correctly linked to their respective agile practice or concept? Collaborative planning Collaborative teams Empowered and motivated teams Coding standards Knowledge-Sharing tools Task volunteering not task assignment Would you add or remove any agile practices or concepts to this agile level? If so please explain why.

Do you of any further comments about agile level 1

3.2 STAGE 3: ORGANIZATIONAL READINESS FOR AGILE LEVEL 2 (PAGES 26-34)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The objective or theme of Agile Level 2 The agile practices and concepts identified in Agile Level 2 The sample indicators and questions related to each agile practice or concept LEVEL OF DETAIL To what extent do you agree that the material about Agile Level 2 is presented at a sufficient level of detail? PRACTICALITY One of our objectives is to make sure that the Agile Levels are practical and can be used in industry. In light of this to what extent would you agree that if the agile practices and concepts presented in agile level 2 were used during the project that they would better ensure delivering software early and continuously? To what extent do you agree that the results of the questionnaires (indicators) legitimately reflect the readiness of the organization to adopt the agile practices and concepts identified in agile level 2? EFFECTIVENESS To what extent do you agree that the agile practices and concepts identified in Agile Level 1 are sufficient enough to achieve the objective of this agile level which is delivering software early and continuously? To what extent would you agree that the first level of agility should focus on delivering software early and continuously? RELEVANCE To what extent do you agree that the agile practices in Agile Level 2 are relevant to their associated agile principals? Evolutionary requirements Continuous delivery (incremental- iterative development) Planning get different levels Software configuration management Tracking the iteration progress through working software No Big Design Up Front For each of the agile practices and concept in this level, to what extent do you agree that the sample indicators and questions are relevant and correctly linked to their respective agile practice or concept? Evolutionary requirements Continuous delivery (incremental- iterative development) Planning get different levels Software configuration management Tracking the iteration progress through working software No Big Design Up Front Would you add or remove any agile practices or concepts to this agile level? If so please explain why.

Do you of any further comments about agile level 2

3.3 STAGE 3: ORGANIZATIONAL READINESS FOR AGILE LEVEL 3 (PAGES 35-41)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The objective or theme of Agile Level 3 The agile practices and concepts identified in Agile Level 3 The sample indicators and questions related to each agile practice or concept LEVEL OF DETAIL To what extent do you agree that the material about Agile Level 3 is presented at a sufficient level of detail? PRACTICALITY One of our objectives is to make sure that the Agile Levels are practical and can be used in industry. In light of this to what extent would you agree that if the agile practices and concepts presented in agile level 3 were used during the project that they would aid in the production of quality working software? To what extent do you agree that the results of the questionnaires (indicators) legitimately reflect the readiness of the organization to adopt the agile practices and concepts identified in agile level 3? EFFECTIVENESS To what extent do you agree that the agile practices and concepts identified in Agile Level 3 are sufficient enough to achieve the objective of this agile level which is producing quality software? To what extent would you agree that the first level of agility should focus on producing quality software? RELEVANCE To what extent do you agree that the agile practices in Agile Level 3 are relevant to their associated agile principals? Risk driven iterations Continuous improvement Self-organizing teams The use of true object oriented design and construction Continuous integration Maintaining the list of all remaining features Unit tests For each of the agile practices and concept in this level, to what extent do you agree that the sample indicators and questions are relevant and correctly linked to their respective agile practice or concept? Risk driven iterations Continuous improvement Self-organizing teams The use of true object oriented design and construction Continuous integration Maintaining the list of all remaining features Unit tests Would you add or remove any agile practices or concepts to this agile level? If so please explain why.

Do you of any further comments about agile level 3

3.4 STAGE 3: ORGANIZATIONAL READINESS FOR AGILE LEVEL 4 (PAGES 42-48)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The objective or theme of Agile Level 4 The agile practices and concepts identified in Agile Level 4 The sample indicators and questions related to each agile practice or concept LEVEL OF DETAIL To what extent do you agree that the material about Agile Level 4 is presented at a sufficient level of detail? PRACTICALITY One of our objectives is to make sure that the Agile Levels are practical and can be used in industry. In light of this to what extent would you agree that if the agile practices and concepts presented in agile level 4 were used during the project that they would become more responsive to change? To what extent do you agree that the results of the questionnaires (indicators) legitimately reflect the readiness of the organization to adopt the agile practices and concepts identified in agile level 4? EFFECTIVENESS To what extent do you agree that the agile practices and concepts identified in Agile Level 1 are sufficient enough to achieve the objective of this agile level which is responding to change through multiple levels of feedback? To what extent would you agree that the first level of agility should focus on responding to change through multiple levels of feedback? RELEVANCE To what extent do you agree that the agile practices in Agile Level 4 are relevant to their associated agile principals? Client driven iterations Continuous customer satisfaction feedback Reflect and tune process Smaller and more frequent releases Adaptive planning Daily progress tracking meetings Agile documentation (from agile modeling) User stories For each of the agile practices and concept in this level, to what extent do you agree that the sample indicators and questions are relevant and correctly linked to their respective agile practice or concept? Client driven iterations Continuous customer satisfaction feedback Reflect and tune process Smaller and more frequent releases Adaptive planning Daily progress tracking meetings Agile documentation (from agile modeling) User stories Would you add or remove any agile practices or concepts to this agile level? If so please explain why.

Do you of any further comments about agile level 4

3.5 STAGE 3: ORGANIZATIONAL READINESS FOR AGILE LEVEL 5 (PAGES 49-55)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The objective or theme of Agile Level 5 The agile practices and concepts identified in Agile Level 5 The sample indicators and questions related to each agile practice or concept LEVEL OF DETAIL To what extent do you agree that the material about Agile Level 5 is presented at a sufficient level of detail? PRACTICALITY One of our objectives is to make sure that the Agile Levels are practical and can be used in industry. In light of this to what extent would you agree that if the agile practices and concepts presented in agile level 5 were used during the project that they would establish a true Agile development environment? To what extent do you agree that the results of the questionnaires (indicators) legitimately reflect the readiness of the organization to adopt the agile practices and concepts identified in agile level 5? EFFECTIVENESS To what extent do you agree that the agile practices and concepts identified in Agile Level 1 are sufficient enough to achieve the objective of this agile level which is establishing a true agile development environment? To what extent would you agree that the first level of agility should focus on establishing a true agile development environment? RELEVANCE To what extent do you agree that the agile practices in Agile Level 5 are relevant to their associated agile principals? Low process ceremony Agile project estimation Paired programming Test-driven development For each of the agile practices and concept in this level, to what extent do you agree that the sample indicators and questions are relevant and correctly linked to their respective agile practice or concept? Low process ceremony Agile project estimation Paired programming Test-driven development Would you add or remove any agile practices or concepts to this agile level? If so please explain why.

Do you of any further comments about agile level 5

APPENDIX B: INDICATOR AGGREGATION (PAGES 60-64)

strongly disagree slightly disagree neither disagree nor agree slightly agree strongly agree

UNDERSTANDABILITY For the topics listed below designate the degree to which you agree that they are understandable The directions on how to use the automated method How to compute a weight for each indicator How to compute the weighed interval How to calculate optimistic and pessimistic results How to translate the results into a nominal score LEVEL OF DETAIL To what extent do you agree that the material about the indicator aggregation was presented with a sufficient level of detail? PRACTICALITY One of our objectives is to make sure that our proposed method for indicator aggregation is practical and can be used in industry. In light of this to what extent would you agree that this approach to indicator aggregation can be used practically? RELEVANCE If this approach is used to aggregate a set of indicators, to what extent would you agree that the results would legitimately reflect a valid and relevant outcome? EFFECTIVENESS To what extent do you agree that this approach to indicator aggregation is a sufficient and valid one in aggregating the various sets of indicators throughout the process framework?

Do you of any further comments about the method of indicator aggregation?

Completed 12-page Surveys (Detailed)

Vita

Ahmed Sidky is a senior agile consultant with Tangible Software. He graduated as Valedictorian with a Bachelor's degree in Computer Science from the Modern Science and Arts (MSA) University in Cairo, Egypt. While working as an Internet Solution Developer for one of the leading corporations in Egypt, he received the award for the Best Creative Solution for that year. With his research focused on Requirements Engineering, he earned a Masters degree in Software Engineering from Virginia Tech. Ahmed's research interests then moved towards Agile Software Development Methodologies and he is completing his doctorate in the Spring of 2007 in that field. His latest research is a process framework for the adoption of agile practices known as the Agile Adoption Framework.

236