Friday, July 11, 2008

Agile Development 'nadelen'

written by Daniel Rijkhof

This blog entry is a reply on an article that’s in Dutch, this is why the blog entry is in Dutch to.

Vandaag las ik een artikel over Agile Development op de site van computable.

In dit artikel worden een aantal nadelen van AD genoemd, waar ik het niet mee eens ben. De nadelen die ik op de schop doe zijn:

• In AD fungeren ontwikkelaars tegelijkertijd als informatie-analist, software-architect en tester
• AD is alleen geschikt voor senior ontwikkelaars
• Ontwikkelaars hebben te weinig skills
• Het werk van de bureaucraten, moet worden gedaan door de specialisten.
• Stakeholders worden niet tevoren gedwongen om hun eisen en verwachtingen te formuleren.
• Planning en budget zijn moeilijk te bepalen
• Belangrijke beslissingen op ad-hoc basis
• Slecht doordachte architectuur en modellen, risico op spaghetti-code
• Veel code weggegooid

De eerste drie
De eerste drie nadelen komen voort uit de gedachte dat een team alleen ontwikkelaars mag bevatten van het zelfde niveau:

• In AD fungeren ontwikkelaars tegelijkertijd als informatie-analist, software-architect en tester
• AD is alleen geschikt voor senior ontwikkelaars
• Ontwikkelaars hebben te weinig skills

Is dit werkelijk een eigenschap van AD?

Het Agile Manifesto is gebaseerd op een aantal principes. De toepasselijke principes voor deze nadelen zijn:

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

De principes achter het Agile Manifesto zeggen niets over het samenstellen van een team! Mag je dan zelf bepalen wie er in je team komen? Zou het zo kunnen zijn dat het team zelf weet waar de gaten vallen binnen het team? Zouden de bovenstaande 3 principes, een basis vormen om daar achter te komen, en het probleem op te lossen? Ik denk het wel.

Er is geen verplichting om een team te nemen waarin elk persoon dezelfde hoge kwaliteiten heeft. Er is geen regel in AD die zegt dat dit niet mag. Kan je een team samenstellen met requirements specialisten, architect(s), developer(s) en tester(s)? AD laat je hier vrij in. Als het werkt voor jou, doe het dan.

De gedachte dat je alleen ontwikkelaars in je team hebt zitten, is niet correct, en daardoor vervallen deze drie nadelen.

Meer ‘nadelen’:
• Het werk van de bureaucraten, moet worden gedaan door de specialisten.
• Stakeholders worden niet tevoren gedwongen om hun eisen en verwachtingen te formuleren.

Deze nadelen komen voort uit het idee, dat AD alles beschrijft dat in een bedrijf moet gebeuren om succesvol software te ontwikkelen.

Het volgende agile principe geeft aan dat het de bedoeling is, zo snel en vaak mogelijk waardevolle software op te leveren:
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Stel je voor dat stakeholders niet vertellen wat hun eisen en verwachtingen zijn. Wat moet er nu gedaan worden? Het is een AD noodzaak om te weten wat de stakeholders willen. Vervolgens willen we ook nog weten welke waarde de stakeholders aan hun eigen eisen toekennen, zodat ze zo snel mogelijk werkelijke waarde opgeleverd krijgen. Het nadeel dat ze niet gedwongen worden om hun eisen te formuleren, verwerp ik.

Wie er achter de stakeholders aan gaat om te zorgen dat hun eisen bekent worden, wordt niet gespecificeerd door AD. Zou het een bureaucraat mogen heten? Niets in AD verwerpt dit. Zou het iemand in het team kunnen zijn? Ook dit wordt niet verworpen door AD.

Zou deze ‘bureaucraat’ een specialist zijn op exact dit gebied? Zou dat toch eens mooi zijn!

Planning en budget zijn moeilijk te bepalen

Is dit nadelen toe te kennen aan AD?

Mijn ervaring met non-AD projecten, is dat de planning nooit klopte, en het budget niet te bepalen was. De bedoeling van AD is, om zo snel en vaak mogelijk waardevolle software op te leveren. We kunnen dus kortere planningen maken, en budget voor vrij maken. Het is dan ook makelijker om een correcte planning te maken in vergelijking met non-AD projecten. Het los krijgen van budget is vast makelijker als jou planningen kloppen. Dit kan geen nadeel van AD zijn.

Belangrijke beslissingen op ad-hoc basis

Belangrijke beslissingen, zullen altijd gebeuren, en vrijwel nooit aangekondigd. Ik heb nog nooit gehoord dat een bedrijf een geweldige kans op een vergroting van de winst, heeft uitgesteld omdat er nog een planning vast stond.
Flexibiliteit van het ontwikkel proces is dan ook gewenst, zodat er niet te veel waarde verloren gaat.

Het volgende agile principe is de basis voor flexibiliteit:
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

In non-AD projecten, komt het voor dat er nog geen waarde opgeleverd is, en ook niet zal gebeuren in een korte tijd. In AD projecten word er elke iteratie waarde opgeleverd. Het verlies van waarde wordt geminimaliseerd door een korte iteratie tijd. Er is ook nog de optie, om de iteratie af te maken, waardoor er geen waarde verloren gaat, natuurlijk ten koste van een beetje tijd.

Het volgende agile principe maakt mijn argument af:
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Omgaan met ad-hoc beslissingen, gaat beter met AD projecten vergeleken met non-AD. Dit nadeel is wordt door AD zelfs niet gezien als nadeel, maar als een eigenschap van de business.

Slecht doordachte architectuur en modellen, risico op spaghetti-code

Het volgende agile principe zegt voldoende:
• Continuous attention to technical excellence and good design enhances agility.

In het geval dat dit nadeel toch voorkomt, dient het team zichzelf aan te passen. Zie weer het volgende agile principe:
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Veel code weggegooid

Het zou kunnen voorkomen dat er code is geschreven dat vervangen moet worden, of zelfs niet meer in gebruik is, en weg gehaald dient te worden. Als deze code is geschreven in een vorige AD iteratie, dan was deze code waardevol. Zie weer het volgende agile principe:
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

In dit geval was de code ooit waardevol, en is het nodig om deze code aan te passen om de software nog waardevoller te maken. Waar is het nadeel? Ik zie het niet.


Is AD perfect?

Niets is perfect. Wanneer ik AD vergelijk met de oudere manieren van software ontwikkeling, concludeer ik dat AD geweldig is, een stap richting perfectie.

2 comments:

Marcelloooohhh said...

Ik ben relatief nieuw in agile development. Ik heb de indruk dat Agile met namen geschikt is voor single application development.

Echter, ik vraag me hoe het kan werken voor large scale service development (iets waar ik wel veel ervaring mee heb) waarbij alleen al voor 1 individuele use case meerdere systemen betrokken zijn (denk aan 5 tot 10 systemen per use case) en waarbij de diverse systemen soms door verschillende leveranciers worden gebouwd.

Hoe kun je dan de principes van Agile zoals snel opeenvolgend iteraties opleveren, wijzigingen in scope flexibel doorvoeren, Individuals and interactions over processes and tools effectief invoeren, etc. Voor mijn gevoel worden de planning, architectuur, en afstemmings problematiek door de (on)vermijdelijke (?) overhead tot onoverkoombare hordes.

De klant vraagt er om, ik wil het, en ik breek mijn hoofd over hoe we het voor elkaar kunnen krijgen. Is Agile ook geschikt voor dit soort projecten?

Daniel Rijkhof said...

Beste Marcel,

Software development op single applications is uiteraard 'straight forward'.

Agile(Scrum) toepassen op projecten waar meerdere teams in/mee bezig zijn, is zeer goed mogelijk!

Voor elk project moet het scrum proces op maat worden gemaakt, om te voldoen aan de specifieke omstandigheden en benodigdheden.

Het staan of vallen van het project is zeer afhankelijk van hoe dit gedaan word.

In elk geval wil je alle sprints (scrum iteraties) op de zelfde datum laten beginnen en eindigen, zodat de synchronisatie van werkzaamheden makelijker word.

Voor grotere projecten gebruikten wij (Quintor) een 'scrum of scrums'. Deze meeting is een techniek om het Scrum proces in te kunnen zetten op grote project teams (meerdere sprint teams).

Op http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting kan je meer informatie vinden scrum of scrums.

In het geval dat je meer vragen hebt, zou je me ook kunnen mailen op d.rijkhof (at} quintor.nl