Proiektuen kudeaketa tradizionala esaten diogu honako ezaugarri hauek dituzten proiektuetan egiten den kudeaketari:

• Eskakizun-multzo itxia
• Aurrekontu itxia

Horrelako proiektuek porrot-kopuru handia dute. Porrot egiteko arrazoiak hainbat izaten dira:

• Eskakizunen multzoa ez dago benetan itxita. Bezeroa ez da gai bere beharrizan guztiak behar bezala zerrendatzeko, eta hornitzailea ez da gai konpondu beharreko arazoaren tamaina behar bezala aurreikusteko. Horren ondorioz, bezeroaren itxaropenak ez dira betetzen, epeak eta kostuak arrazoizko mugetatik baino askoz harago desbideratzen dira, etab. Oro har, bezeroak gehiago ordaindu behar izaten du, edo hornitzaileak dirua galtzen du, bezeroak onar dezan ematen zaiona.
• Softwarearen garapena ez da eraikuntza, diseinua baizik. Baso osoak soildu dira, softwarearen ingeniaritzaz, softwarearen eraikuntzaz eta Factory softwareaz diharduten liburuak fabrikatzeko. Izen ponposoak dira horiek, bizitza errealean softwarea inoiz garatu ez duten pertsonek formulatutako teorietarako. Softwarearen garapenak ez dauka eraikuntzak duen errepikakortasunik, neurgarritasunik eta aurresangarritasunik. Horrelakorik ez dauka, softwarea garatzea berori diseinatzea delako (eraikuntzan diseinua eta plano teknikoak bezalakoa da, baina askoz handiagoa); softwarea eraikitzea, berriz, hura konpilatzea eta/edo instalatzea da. Programatzea diseinatzea da, berdin dio aldez aurretik zer diseinu sortu den. Beti hartu behar dira diseinu-erabakiak zerbait programatzen denean. Horrek esan nahi du nekez kalkula daitekeela, aurrez aurretik, zenbat denbora beharko den garapen bat egiteko, batez ere betebehar zehatzik ez dagoenean, baina baita betebehar horiek daudenean ere; izan ere, eskakizunen azterketa aski zehatza egitea bada konponbidea diseinatzearen parekoa.
• Bezeroarengan bete ezin diren itxaropenak sortzen dira. Bezeroari beti esaten diogu epeak beteko ditugula eta sistemak egingo duela hark nahi duen guztia (eta, gainera, oso merkea izango dela!). Ez dira inoiz epeak betetzen, eta sistemak ez du inoiz bezeroak nahi duen guztia egiten, bezeroari, aplikazioa ikusi bezain laster, egin beharko lituzkeen gauza berriak bururatzen zaizkiolako. Bezeroak ez du kontrolik proiektuaren kostuen gainean: bezeroak txeke zuri bat besterik ez du, proiektuaren kostuaren zifra hotz, erraz eta argia jaso duelako, eta aplikazioari berak nahi dituen xehetasun guztiak eskatuko dizkiolako. Bezeroak ez du jasotzen xehetasun bat oso garestia izan daitekeela dioen informaziorik; proiektuen onerako, funtzionaltasuna kostuaren aurrean hartu behar da kontuan beti.
• Bezeroaren beharrak aldatu egiten dira. Agian, bezeroaren beharrak aldatu dira enpresa edo ingurunea aldatu direlako edo beste aukera interesgarriago batzuk agertu direlako.

Binovon, Ágil softwarea Garatzeko Manifestua sinatu genuen, eta, horrenbestez, honako hauek baloratzen ditugu:

• Pertsonak eta haien arteko harremanak, prozesuen eta tresnen aurrean.
• Funtzionatzen duen softwarea, dokumentazio zehatzaren aurrean.
• Bezeroekiko lankidetza, kontratuen negoziazioaren aurrean.
• Aldaketari erantzutea, plan bati jarraitu baino gehiago.

Esaldien bigarren zatiek balioa badute ere, guk uste dugu lehen zatiek askoz balio handiagoa dutela.
Horregatik, honako printzipio hauei jarraitzen diegu:

• Lehentasuna bezeroa asetzea da, harentzat baliotsua den softwarea azkar eta etengabe entregatuz.
• Aldaketak onartzen ditugu betekizunetan, garapenaren amaieran bada ere. Uste dugu aldaketak beharrezkoak direla gure bezeroek abantaila lortzeko lehian.
• Funtzionatzen duen softwarea maiz entregatzea: 2 aste eta 2 hilabete artean, betiere denborarik laburrena nahiago badugu ere.
  Negozioa ezagutzen duten pertsonek eta garatzaileek egunero elkarrekin lan egin behar dute proiektuan zehar.
• Proiektuak pertsona motibatuengan oinarriturik eraikitzen ditugu. Behar duten giroa eta babesa ematen dizkiegu, eta konfiantza dugu lana aurrera aterako dutela.
• Garapen-talde bati (eta batean) informazioa partekatzeko modurik eraginkorrena aurrez aurreko komunikazioa da.
• Aurrerapen-metrika nagusia funtzionatzen duen softwarea da.
• Prozesu bizkorrek garapen iraunkorra sustatzen dute. Sustatzaileek, garatzaileek eta erabiltzaileek erritmo konstante mugagabea mantentzeko aukera izan behar dute.
• Bikaintasun teknikoari eta diseinu onari etengabe arreta eskaintzeak bizkortasuna hobetzen du.
• Sinpletasuna, egin gabeko lana maximizatzeko artea, funtsezkoa da.
• Arkitektura, betekizun eta diseinu onenak autoantolatutako ekipoetatik sortzen dira.
• Erregulartasunez, taldeak erakusten du nola bihurtu eraginkorrago, bere portaera modu kontsekuentean doituz.