Agile Success Factors

3y ago
741.76 KB
27 Pages
Last View : 12d ago
Last Download : 4m ago
Upload by : Angela Sonnier

Agile Success FactorsA qualitative study about what makesagile projects successfulProf. Martin KroppUniversity of Applied Sciences and ArtsNorthwestern SwitzerlandAndreas MeierZurich University of Applied SciencesSwitzerland

AuthorsAndreas MeierZurich University of Applied Sciences (ZHAW)WinterthurProf. Martin KroppUniversity of Applied Sciences and ArtsNorthwestern Switzerland (FHNW)WindischPublisher: FHNW and ZHAWDate of publication: May 2015Website: www.swissagilestudy.chISSN: 2296-24762

1Management Summary. 42Introduction. 53Acknowledgment . 64Overwiew of the Interview Study . 75Results of the qualitative study . 96Other Findings . 147Conclusion . 168References . 179Contact . 1811 Appendix A - Theory of Complex Adaptive Systems and Agile Competences . 1912 Appendix B – Project Report Forms . 223

1 MANAGEMENT SUMMARYVarious studies show great improvementsin software projects when agile softwaredevelopment is applied. However, thereare still remaining problems and there arealso reports about project failures in theagile community. This raises the questionof what factors distinguish successful agilesoftware projects and teams from lesssuccessful ones?The authors of the Swiss Agile Studywanted to shed some light on these questions. We conducted a qualitative interview study with eight successful agile ITcompanies. We asked them about theessential success factors in their agile projects. The findings are divided into threedifferent categories: Engineering practices, management practices and the values,or culture, they live.On the engineering level it was found thatthese companies apply many technicalpractices in a very disciplined way, with astrong emphasis on quality assuring practices like unit testing, continuous integration and automation, and clean coding.On the management level it was pointedout that clear requirements, which areverified and validated in very close collaboration with the customer, are essential.The same was true for very close communication within the team. The third aspectthat was found, was that in each successful team there was a kind of Agile Cham-pion who motivated and inspired the teamto use agility.On the value level we found that successful agile teams live a culture of opennessand transparency. They establish an agileculture at least on the team and organizational level (we found only one companywho had established the agile method inthe whole company). Third, they live anattitude of craftsmanship, being proud oftheir work and striving for high qualitywork.Finally we noticed, that while putting highemphasize on the above practices, matureagile teams start adapting these practicesand the agile process to their needs, whenthey notice that some of the practices donot work or that following the recipe isinsufficient. A constant probing, sensingand appropriate responding was observed. This is the typical pattern for moving forward in complex adaptive systems.Applying a sense-making methodology likethe Cynefin framework, theoretically explains the observations in the presentstudy. Companies should therefore beaware, that software projects are oftenlocated in the complex domain, i.e. can bemodeled as complex adaptive systems.These kinds of problems rather requireemergent practices instead of good orbest practices and an understanding of theimplications of complexity theory is ofmerit.

2 INTRODUCTION2.1 Motivation2.2 Scope and Goal of the StudyThe Swiss Agile Study, an online survey onthe state of software development inSwitzerland, was conducted in 2012 and2014. The studies clearly show significantimprovements as compared to traditionalapproaches, i.e. faster time-to-market,improved change management, and higher satisfaction with the overall process.However, the studies also show, that asignificant part of the agile projects faildue to various reasons, though most ofthe recommended good practices for agiledevelopment were applied. So the studiesalso raised new questions. The predominant question was: What makes agileteams successful? Which factors distinguish successful software projects andteams from unsuccessful ones?With the new study the authors wanted tofind out, what the essential factors forsuccessful agile projects are. For this theyconducted an interview study among eightSwiss IT companies about their most successful agile projects.The main goals of the study were to findout: What the essential criteria are thatmake an agile software project successfulIf patterns of behavior can be identified for successful projectsIf these patterns can help others conduct successful projects5

3 ACKNOWLEDGMENTThe authors would like to thank the SwissHasler Foundation,,which has generously funded the AgileSuccess Factors project. In 2012, the Hasler Foundation also funded our first SwissAgile Study, a quantitative study on software development in Switzerland, whichhas run now in a bi-annual survey. TheSwiss Agile Study was the inspiration forthis project.6We would also like to thank all the participating companies of the study for takingthe time and their willingness to answerall our questions. Last but not least wewould like to thank Jenny C. Ivarsson forproofreading and improving our study.

4 OVERWIEW OF THE INTERVIEW STUDY4.1 Interview MethodThe aim of our study was to show by example how agility is successfully realizedin various kinds of projects and differentkinds of companies and branches. To dothis we conducted an interview studyamong eight Swiss IT companies that haveadopted agile methods in their softwaredevelopment. The companies were askedto provide a written description in advance of their most successful agile project, including a reasoning why they considered the described project as successful– from their own point of view and fromtheir customers’ point of view.We conducted eight semi-structured individual interviews and used a selfdeveloped interview guide. We structuredour interview questions according to theAgile Competence Pyramid (see Figure 1)with the three different competence levels engineering, management and agilevalues, as formulated in [7]. Since all interviews took place in the German speaking part of Switzerland, all interviews wereconducted in German.The interviewed companies operate nationally, internationally and globally. Thefollowing table gives an overview of theindustry branches covered.Table 1. Branches covered in studyBranches# CompaniesProduct Development2Public Service1Manufacturing2Insurance1IT Supplier2The interviews were conducted with atotal of nine participants (at one company,we had two interviewees). The participants were mostly project leaders, groupleaders, or department leaders. The interview duration was between one and almost two hours. All interviews were audiorecorded and later transcribed. The transcription facilitated the evaluation of theinterviews with a statistical text-analysistool.Figure 1. Pyramid of Agile Competences (from [7])

4.2 Organizational Level of AgilityIn this paper we use the terms team, organization and company to describe onwhich organizational level Agility was introduced:Team refers to the software developers,testers, Scrum Masters, Product Ownersetc., i.e. the people who are directly involved in the software development. Allthe teams in the study follow an agilemethodology like Scrum.Organization refers to the team plus otherpeople who are involved in the project, i.e.customers, end-users, and managementsponsors. They work together with theteam in an agile or non-agile environment.In the former case, the team supports theorganization in becoming agile. In the latter case, the team provides an “interface”to facilitate the communication betweenthe different environments.Company refers to the enterprise withinwhich the software development projectis executed. Currently, most of the companies we questioned are not agile. In ourinterviews, we had seven non-agile companies where at least one team or organization was agile.In seven of the eight companies the agileapproach was applied either for one ormore organizations within the company oron the team level for the project teams. In8these companies, agile methodologieswere either introduced bottom-up or topdown. This means that those team wheretypically embedded in a classical, hierarchical organization within its own company. In one company, agile methodologywas introduced in the whole company, i.e.was applied also on management level.4.3 Interview QuestionsIn preparation for the interview the interviewees were asked to send us a shortdescription of the selected project, including some basic information like duration,effort, and team size. Additionally, theyhad to answer the following questions: What makes the project successfulfrom your point of view?What makes the project successfulfrom your customer’s point of view?In the one-hour interview (in average), theinterviewee had to provide further information about the company and the project (industry sector, company size, inhouse/contract work/product development, main project technology).We asked the questions listed in Table 2about the topics, Success, Engineering,Organization and Management, Cultureand Values, and Improvements.

TABLE 2. INTERVIEW QUESTIONSSuccess1. What makes the project successful from your point of view?2. What makes the project successful from your customer’s point of view?3. What are the reasons for the success from your point of view?Engineering4. How much do the engineering practices (according to [7]) contribute to the success?5. Which engineering practices do you apply regularly?Organization/Management6. How much do the management practices (according to [7]) contribute to the success?7. Which management practices do you apply regularly?Culture & Values8. How much do the cultural aspects / values (according to [7]) contribute to the success?9. Which cultural aspects / values do you apply regularly?Improvements10. What would you change to make the project even more successful?5 RESULTS OF THE QUALITATIVE STUDYas scrum-of-scrum teams.5.1 Basic Project FiguresTable 3 showsan overview of the basic project figures. The projects ranged fromsmall projects to intermediate sized projects, and covered in-house projects, embedded software projects and productdevelopment. The team size ranged from5 to 12 persons; the latter being organized5.2 What is Success in Projects?The question about why the selected project was considered successful was answered in very many different ways.TABLE 3. PROJECT FIGURESP1P2P3P4P5P6P7P8Type useIn-HouseProductCompanyIT SolutionPublicserviceManufacturerManufacturerIT ServiceProviderInsuranceIT crumScrumScrumScrumSize24 PM30 PM30 PM100 PM30 PM12 PM72 PM 120 PMDuration3M10 M12 M9M10 M8M24 M Team5P10 P5P3x4P6P8P5P5 (current)9

The most frequent answers were: Very good communication in the teamContinuous deliveryDelivery on timeVery few bugsSatisfied customersNo overtimeWhen asked for the reasons for the success, the following main aspects werementioned: All team members were committedContinuous and extensive testingRequirements were very clearVery close communication with andintensive feedback from customersTeam workshops for team building5.3 Engineering PracticesIn the interviews, all teams reported thatthey emphasize applying engineeringpractices. These practices are seen as veryimportant and as a kind of foundation,which ensures that software can be developed in short iterations with the requiredquality. There is a constant process of improvement and refining of these practices.Depending on the maturity of the teamand organization, this is triggered by theagile champion (see below), the teammembers or, in the case of an agile company, even by the management. This canhappen ad hoc or formalized. Engineeringpractices are mostly well-known good orbest practices. Many of them have beenpopularized in eXtreme Programming [8].A quantitative overview can be found in[1], [3].Refactoring, automated tests, continuousintegration and deployment, pair programming, test-driven development [18],etc. are the tools of the trade [19]. Unittesting, continuous integration and cleancoding were mentioned as the core and10most important practices in most organizations.5.3.1 TestingIn almost all the organizations automatedtesting on unit level is well established andis seen as an absolute must for providing agood software quality. More mature organizations also apply automated testingon acceptance testing level using new approaches like Automated Acceptance Testing (ATDD) and Behavior Driven Development (BDD).5.3.2 Continuous IntegrationContinuous integration is seen as an absolute must for being able to deliver software with high frequency. Thus all organizations have established an automatedbuild and test environment, which provides immediate feedback to the developers about the quality of the system beingbuilt. Some organizations already strivefor continuous delivery to automate thedelivery process for faster and safer delivery to customers with less effort.5.3.3 Clean CodeContinuously paying attention to writinggood code from the very beginning is considered more and more important. Someof the organizations started applying theClean Code [13] approach with the goal ofestablishing a constantly high code quality. These teams also apply further practices like continuous quality control, regularor even institutionalized code reviews, andregular pair programming.5.4 Management and OrganizationPractices for SuccessThe success criteria on management levelthat were mentioned most often were theshort iterations (typically two weeks) andthe self-organization of teams. Other important issues mentioned were User StoryGrooming meetings during the Sprint;

close communication with externals; openoffice. Management support was also argued to be very important by one company. For one company, that has remoteteams, daily meetings with visual communication tools like Skype was very important.In the eight observed projects, many different practices and paradigms were used.Their usage depended on the size anddomain of the project but also on the culture of the respective company. We founda small but powerful set of underlyingcharacteristics common in all agile projects. The interviewed companies especially emphasized the following managementaspects:5.4.1 Customers and RequirementsIn all the interviews, it was pointed outthat an intensive and frequent communication with the customer was of utmostimportance.Successful agile teams are implicitly orexplicitly aware of the fact, that technology sometimes brings solutions previouslyunknown to the users. Because of this,gathering user requirements can be aproblem. The users cannot know theywant something if they do not even knowthat it exists. It is important to note thatsoftware is developed in a co-evolutionarysystem with technology.In all the successful projects there was avery good understanding of the neededrequirements by all team members.Communication solely with the ProductOwner is unsatisfying. Developers feel theneed to communicate directly with andget feedback from the end-users.User Stories [16] were the premier method used to express functional and evennon-functional requirements on cards inthe interviewed companies.5.4.2 Agile ChampionLeaders on all levels of agile organizationsneed to adopt a Catalyst Leadership style.These leaders thrive by inspiring otherswithout losing the cohesion within theentire system. They know they can trustthe organization and its individual members. Most importantly they know, at leastby own experience, that software development takes place in several domains(see appendix A) at the same time.In the interviews we found, that in all theprojects there was at least one personwho was championing agility and wetherefore use the term Agile Champion torefer to the role of that person. Why issuch a role needed? When an organizationwants to become agile, change is inevitable. Of course, it would be nice if positivechange happened magically with no effort.Unfortunately, experience shows that itdoes not. On the contrary, change is verychallenging.What is the role of the agile champion? To lead and inspire agilityTo help define which change is necessaryTo convince and bring on board others to support the changeTo help show that the change is happening and is bringing good resultsTo avoid “cowboy” agility and backsliding to the former approach (e.g.waterfall)To lead modifications to the changeTo remove impediments from thechangeTo lead the people to the next level, ifit starts to plateau11

This all requires huge amounts of talkingto people. The role of the agile championis not to tell them what to do, but to inspire them with a vision of where they andthe project could be. It is more a role ofpulling than of pushing.5.4.3 Collaboration and CommunicationIntensive and open communication amongall stakeholders is seen to be one of thekey elements for successful agile projects.In our interviews we identified the following three major communication scenarios.Firstly, the team members themselvesmust communicate intensively with eachother. Secondly, the team as a whole mustcommunicate with the customers andend-users, and finally the team must establish good communication with themanagement (which is often organized ina classical hierarchical way).To foster communication in teams, almostall organizations implement co-locatedteams in an open office environment.Most communication is then carried outinformally at the desks. This helps to reduce official meeting time significantly andmake the necessary meetings much moreefficient.Regular communication with the customers is established through short iterationswith reviews and continuous feedbackloops. However, developers have a clearneed to communicate directly with theend-users instead of the product owners.Communication and collaboration withremote teams is always seen as challenging. Companies invest a lot in establishinga good communication between theseteams. Means are regular chat sessions,remote participation in meetings, and video conferencing. Despite its high costs,some companies value bringing the people together physically at regular intervals.A week of common work usually “refresh12es” relationships for about 5-6 weeks, andthen the next physical meeting is due.5.5 Agile ValuesAll interviewed organizations realized thatdeveloping agile is not only a matter ofchanging processes, but foremost, achange of the culture in an organization.Thus values become more important.Scrum defines the following five Scrumvalues [17] (in no particular order): Commitment, Focus, Openness, Respect andCourage. Extreme Programming [8] defines the values a bit d

Method Scrum Scrum Scrum Scrumban Scrum Scrum Scrum Scrum Size 24 PM 30 PM 30 PM 100 PM 30 PM 12 PM 72 PM 120 PM Duration 3 M . Continuous delivery Delivery on time testing on unit le

Related Documents:

1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18

1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma

Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .

Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.

1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.

The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .

The Agile Customer . 9/6/2012 6 Agile Development Team Agile Analyst . 9/6/2012 7 Agile Programmer Agile Tester . 9/6/2012 8 Agile Manager Agile Usability Designer . 9/6/2012 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any

The Agile Customer. 9/4/2013 6 Agile Development Team Agile Analyst. 9/4/2013 7 Agile Programmer Agile Tester. 9/4/2013 8 Agile Manager Agile Usability Designer. 9/4/2013 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any software