Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Why agile is best for managing projects in principle but not always in practice


Published on

The 12 principles of agile and their inversion for managing projects

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Why agile is best for managing projects in principle but not always in practice

  1. 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. 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.