Why agile is best for managing projects in principle but not always in practice
Download as DOCX, PDF0 likes177 views
The document discusses the principles of agile project management and argues that while agile principles are good in theory, they are not always practical to implement. It outlines the 12 principles of the Agile Manifesto which focus on satisfying customers, welcoming changing requirements, frequent delivery of working software, collaboration between business and development teams, self-organizing motivated individuals, sustainable development pace, working software as a progress measure, face-to-face conversation, technical excellence, simplicity, self-organizing teams, and regular reflection and adaptation. However, it notes that in practice, principles may not leave teams better off, ensure improvements, or provide clear guidance for different contexts.
Why agile is best for managing projects in principle but not always in practice
- 1. Why Agile Are Best for Managing Projects in Principle But Not Always In Practice Let’sstart withthe 12 principlesof the Agile Manifesto Our highestpriorityisto satisfythe customerthrough earlyand continuousdelivery of valuable software Welcome changing requirements,evenlate in development.Agileprocesses harnesschange forthe customer’scompetitive advantage Deliverworkingsoftware frequently,fromacouple of weekstoa couple of months, withpreference tothe shorter time scale. Businesspeople and developermustworktogether dailythroughoutthe project Buildprojectsaround motivatedindividuals.Give themthe environmentand supporttheyneed,andtrust themto getthe jobdone. Agile processes promote sustainable development. Sponsors,developers,and usersshouldbe able to maintaina constantpace indefinitely Workingsoftware isthe primarymeasure of progress The mosteffective and efficientmethodof conveying informationtoandwithinthe developmentteamis face–to– face conversation. Continuousattentionto technical excellence andgood designenhancesagility Simplicity–the art of maximizingthe amountof work not done – is essential The bestarchitectures, requirements,anddesigns emerge fromself–organizing teams. Atregularintervals,the teamreflectsof how to become more effective,then tunesandadjustsit behavior accordingly These 12 principleshave beenaround fora while andhave become the basisof muchof the literature on agile software development.Likeall goodmanifestostheyare takenasgospel.Andlike all good gospel’stheyare sacredtextstobe studied,puttouse,admired,andleftunchallenged. Let’slookat the taxonomyof these 12 principlesinlightof the principlesof management. 1. Managementprinciplesshould do notharm,thatistheyshouldleave the people,processes,and toolsbetteroff thanbefore theywere applied. 2. Managementprinciple shouldmake improvementswheneverpossible.Withoutsome formof improvementwhybother. 3. Principlesshouldbe applicable inknow ways,withknownorknowable beneficial outcomes. These outcomesshouldtrytohave some measuresof effectiveness,efficiency, and performance. 4. In the endthe managementprinciplesshouldprovide guidance fortheirapplicationtospecific situations,domains,andcontextsinthatdomain.
- 2. Let’slookat the 12 inlightof the inversionof statement. We don’treallywhatto satisfyourcustomers,they’re the lowestpriorityforour efforts.Theirneedsanddesires are notreallyourconcern. Nothingcan change.We’re lockedintoourapproach,our budget,outschedule,our productsand services. The software we deliver doesn’treallyhave towork.We don’treallycare if it works. We want to be leftalone by the businesspeople.we have no desire tointeractwiththem, leave usalone,we’llgetbackto youwhenwe’re done. workingon thisprojectwill be trulybad experience foryou and yourteam mates.We’ll try as hard as we can to make this a veryunpleasantexperience. We’re goingto go out of our wayto burn people out,get themto leave the project,treat themlike slave laborand generallymake thisabadplace to work. Have the software actually workis the leastof our concerns, Nobodygetsto talkto talk to anybodyaboutanything.Our workis secret What getsproducedis generallyok.Qualityisour lowestpriority We’re goingtomake this as complex aspossible.Noone will be able tofigure outwhat we’re doingorhowwe did it. Architecture willbe handeddownfromon highand nothinginthe worldisgoingto change it,it’scast instone. Atthe endof every deliverable,we’regoingto ignore everythingthat happened –both goodand bad.