Vaikka iteraatio ei välttämättä lisää niin paljon toiminnallisuutta, että tuotteen julkaisu olisi järkevää, ketterä ohjelmistokehitysprojekti pyrkii periaatteessa julkaisukelpoiseen ohjelmistoon jokaisen iteraation lopussa. Iteraation lopussa projekti arvioi uudelleen projektin prioriteetit ja päättää seuraavan iteraation sisällöstä. Ketterät menetelmät pitävät suoraa viestintää (mieluiten kasvokkain) tärkeämpänä kuin kirjoitettuja dokumentteja. Useimmat ketterät tiimit työskentelevät samassa työtilassa, ja tiimiin kuuluvat kaikki, joita tarvitaan ohjelmiston saamiseen valmiiksi. Tämä tarkoittaa vähintään ohjelmoijia ja heidän "asiakkaitaan". (Asiakkaat määrittelevät tuotteen ja voivat olla tuotepäälliköitä, liiketoiminta-analyytikkoja tai varsinaisia käyttäjiä. ) Tiimiin voi kuulua myös testaajia, käyttöliittymäsuunnittelijoita, teknisiä kirjoittajia ja päälliköitä. Ketterät menetelmät korostavat toimivan ohjelmiston olevan ensisijainen edistyksen mittari eikä dokumentaatiolla ole samaa itseisarvoa kuin useissa perinteisemmissä malleissa.
Ihmissuhde- tai viestintätaitoja mitattiin lähinnä sillä, kuinka projektisuunnitelmaan tehty viestintäsuunnitelma on toteutunut. Uudet projektimenetelmät ovat muuttaneet projektien luonnetta ja osin siitä syystä mutta myös yleisesti projektipäällikön rooli on muuttunut. Projektipäällikkö ei ole enää vain projektin hallinnoija ja työnjohtaja (manager) vaan ihmisten johtaja, valmentaja ja sparraaja (leader). Uusimpien projektihallintamenetelmien lähtökohta on, että tiimin jäsenet osallistetaan projektiin ja päätöksiin entistä tiiviimmin. Projektipäällikön tulee motivoida ja sitouttaa tiimiläiset yhteiseen tavoitteseen. Projektipäällikkö on fasilitaattori, joka antaa tiimiläisten loistaa, kerää ja kannustaa antamaa ideoita, on tasapuolinen ja kunnioittava. Samalla projektien tehtävät tulee jakaa jokaisen tiimin jäsenen osaamisen ja vahvuuksien mukaisesti. Ihmisten johtamisessa sekä projektin sidosryhmätyössä projektipäällikön viestinnällinen osaaminen on yksi merkittävimpiä tekijöitä projektien onnistumisessa.
SAFe – Scaled Agile Framework on yleisimmin käytetty skaalatun ketteryyden viitekehys. SAFe antaa riittävät rakenteet ja tarvittavia käsitteitä, rooleja ja konkreettisia käytäntöjä, jotta tuottavasti ja tehokkaasti arvoa tuottavat tiimitason ketterät periaatteet (kuten Scrum) saadaan tuottamaan asiakasarvoa myös suurissa organisaatioissa. Muita skaalattuja viitekehyksiä ovat mm. Nexus ja LeSS. Koulutukset
Washington, DC: IEEE Computer Society. (englanniksi) Cohen D., Lindvall M. & Costa P. : An Introduction to Agile Methods. Advances in Computers, 2004, nro 62, s. 1–66. (englanniksi) Shore, James: The Art of Agile Development. Sebastopol: O'Reilly, 2007. (englanniksi) Lähteet [ muokkaa | muokkaa wikitekstiä] Aiheesta muualla [ muokkaa | muokkaa wikitekstiä] Agile Alliancen kotisivut. (englanniksi) Agile Finland ry:n kotisivut. (englanniksi)
Ketterän kehittämisen malli perustuu continuous delivery ja Kanban -periaatteisiin, jossa tehtävät pyritään saamaan valmiiksi jatkuvassa kehitysvirrassa ja mahdollisimman pienissä erissä. Prosessin tarkoitus on tuoda julki jokainen työvaihe, jolloin kaikilla osapuolilla on jatkuvasti nähtävissä projektin eteneminen ja missä vaiheessa jokainen tehtävä kulloinkin on. Periaatteet Tavoitteena on saada yksi käyttäjätarina valmiiksi mahdollisimman tehokkaasti. Kehitysjonosta otetaan käyttäjätarinoita samassa tahdissa kuin kehittäminen etenee. Ei siis tehdä tarkennusta kaikille tehtäville etukäteen eikä oteta kaikkea kerralla työnalle. Keskitytään aina yhden toiminnallisen kokonaisuuden, käyttäjätarinan ja sitä vastaavan hyväksymistestitapauksen valmiiksi saamiseksi mahdollisimman nopeasti. Tehdään yksi tehtävä valmiiksi alusta loppuun asti (vrt. 39 tehtävää kehitteillä ja kesken) jokaisella vaiheella kehittämisen prosessissa on rajallinen määrä tehtäviä jokaisessa kehityksen Kanban-taulun sarakkeessa olevien tehtävien lukumäärä rajataan, jotta suurilta välivarastoilta vältytää Uusia parannusehdotuksia on äärimmäisen helppo keksiä koska tahansa.