Reviews, dvs. det at en eller flere evaluere et resultat af nogle andres arbejde fungere sjældent optimalt i projekter. Dette er selvom de fleste er enige om at det principielt er en sund ting at få et par ekstra sæt øjne til at kigge ens arbejde igennem en gang i mellem.

Problemet her er som regel at man benytter sig af 2 review implementeringer, som ikke helt giver den værdi man have forventet. Det drejer sig om:

• Klassiske reviews: Disse er karakteriseret ved en høj grad af formalisme, dvs. reviewet skal planlægges og dokumenteres på passende vis. Dette har den (teoretiske) fordel at reviews'ene kan planlægges til blive afholdt på passende tidpunkter, at det er synligt for andre hvad der ligger i reviewet, og disse informationer er fastholdt. Problemet er at omkostningen ved at gennemføre et review bliver alt for stor i form af dokumenter og regneark der skal udfyldes og vedligeholdes. Resultatet er at der bliver udført meget få, om nogen reviews.
• Agile reviews: Disse reviews (walkthroughs, gennemgange etc) er foregår typisk ved at man ad-hoc sætter sig ned sammen med en anden og kigger ens arbejde igennem en gang i mellem. Dette har mange fordele, men man får ikke høstet de fordele man finder i de formelle reviews, nemlig planlægning, synlighed og fastholdelse.

For at kunne udnytte fordelene ved begge typer reviews forsøger vi i Agilis at:

• Lave en review proces implementering vha. Crucible (eller andet letvægtværktøj), der gør det praktisk muligt at koble blivende, fælles tilgængelige informationer på review indhold og resultater.
• Udvide og formalisere de daglige arbejdegang med review aktiviteter, så de indgår som en naturlig del af udviklingsarbejdet.
• Beholde løbende ad-hoc reviews (jf. XP principper).
• Tæt kobling mellem review information og materialet der skal reviewes.