1) De Scrum rolverdeling is niet praktisch

De Product Owner moet volgens Scrum de bevoegdheid hebben alle beslissingen te nemen namens de opdrachtgever. In ICT projecten is dit veelal een manager die niet de tijd heeft om ook fulltime de Product Owner verantwoordelijkheden op zich te nemen. Tevens is de vraag in hoeverre een manager uit “de business” de vaardigheden heeft die horen bij de Product Owner rol (o.a. de scope nauwkeurig vastleggen, bouw volgorde bepalen).  Scrum onderkent dit probleem niet en biedt ook geen handvaten hoe deze rol kan worden opgesplitst.

In Scrum is er geen projectmanager maar is het team “zelfsturend”. De Scrummaster is uitsluitend een coach en facilitator. Mijn persoonlijke ervaring is dat een team met een ervaren leider veel effectiever is dan een groep zonder leider. Op dit gebied mist Scrum naar mijn mening de project- en teamleider rollen. Ik denk dat dit anti-management sentiment in Scrum veroorzaakt wordt door slecht projectmanagement. Zo worden HBO+ werknemers nog te vaak gemicromanaged en wordt er meer gestuurd op het halen van deadlines dan op een goed resultaat. Dit pleit voor ander management, niet minder management.

Naast de Product Owner en Scrummaster rol bestaat er ook nog het Teamlid rol. Scrum maakt hierin geen onderscheid in rollen, sterker nog: alle teamleden moeten elkaars werk kunnen doen en alle rollen zijn fulltime met het project bezig. Ook deze rol is niet praktisch; de beste vaardigheden zijn veelal aanwezig bij de specialisten in plaats van in generalisten.

2) Scrum onderkent onvoldoende het belang van duidelijke requirements en een goed ontwerp

Scrum noemt “gedetailleerde documentatie” minder waardevol. Een valkuil in Scrum is dat ontwerp niet verder komt dan post-it’s en tekeningen op een whiteboard (het houden van ontwerp sprints zoals bijvoorbeeld in RUP/OpenUP is immers ook tegen de leer in). Uit onderzoek blijkt juist dat slechte specificaties de voornaamste reden zijn van projectfalen. Tevens weten we dat de kosten van software voor meer dan de helft in onderhoud zitten, en niet gedocumenteerde systemen een veelvoud in onderhoud kosten.

Scrum bevat geen ontwerpfase omdat wordt aangenomen dat ontwerpen niet begrepen worden en in 1 big bang naar de klant gaan.Dit is vandaag de dag nog maar zelden het geval, aangezien moderne ontwerp technieken als use cases en scherm prototypes door de klant heel goed te begrijpen zijn. Tevens worden ook ontwerpen tegenwoordig in meerdere iteraties opgeleverd in plaats van in 1 big bang. Klanten zijn ook meer en meer bewust van goed opdrachtgeverschap en daar valt ook zorgvuldig reviewen van ontwerpen onder.

Scrum stelt voor om ontwerp over te slaan en vanaf de eerste iteratie werkende software aan de opdrachtgever te laten zien. Dit betekent wel een duurder proces, want als de klant de werkende software niet bevalt moet de code worden aangepast. Als de klant de fout ontdekt in het ontwerp hoeft alleen het ontwerp te worden aangepast, wat een stuk sneller en goedkoper is. Tevens is het veelvuldig ombouwen van een applicatie veelal niet goed voor de code kwaliteit.

De enige ontwerp artifacts in Scrum, waarover voor de bouw wordt overlegd, zijn de User stories (op post-it’s) in de Backlog. De Backlog is een lange platte lijst van gewenste functionaliteit zonder groepering of hiërarchie. Bij veel User stories is dit al snel niet meer praktisch. Over veel gebruikte ontwerp technieken als requirements, use cases en wireframes (en het samenspel daartussen) roept Scrum niets, terwijl lang niet alle wensen in User stories te vatten zijn. User stories hebben weinig structuur waardoor veelal wordt teruggevallen op datgene waarvan ze zijn afgeleid: UML Use cases.

3) Er zijn ontbrekende schakels in het proces model van Scrum

De aantrekkelijke Scrum proces plaatjes laten niet de hele werkelijkheid zien. Met name processen in de beginfase en eindfase van het project missen. Tevens worden veel processen nergens volledig uitgewerkt (wat is het doel van het proces, wie is betrokken/verantwoordelijk, wat is de output, wat zijn de afhankelijkheden).

Enkele voorbeelden van zaken die binnen Scrum bestaan maar waarvoor het creatie en beheersproces mist:

• De “Definition of done” (wanneer is oplevering compleet)
• De (“groomed)” productbacklog, inclusief de uitwerking van de user stories en het groomen
• Testresultaten
• Estimations (wanneer, en hoe vaak worden er inschattingen gemaakt of bijgewerkt, wat gebeurd er als het team de user stories van de product owner te vaag vind?)

Naast dat er processen missen voor benoemde Scrum artifacts, zijn er ook belangrijke artifacts, plus bijbehorende processen, die missen. De belangrijkste twee zijn naar ontwerp en projectmanagement artifacts en processen. In de vorige paragraaf is het ontbreken van ontwerprocessen reeds besproken. Door het geheel ontbreken van een ontwerp en analyse fase vraag ik me af de opdrachtgever tijdig en weloverwogen keuzes kan maken over de kosten en duur van een project.

Tevens missen processen voor vaststellen, rapporteren over, en bewaken van het projectbudget en planning. Gerelateerd daaraan zijn de missende processen voor het omgaan met wijzigingen gedurende het project. De product owner kan de backlog naar wens aanpassen maar er is geen terugkoppeling over de kosten/haalbaarheid/kwaliteitsimpact van wijzigingen.

Conclusie: Not to Scrum ?

Geen enkele partij die software bouwt ontkomt eraan om zijn eigen software ontwikkelingsmethode(s) te ontwerpen en continu te verbeteren. Daarbij is het gebruikelijk dat de beste ideeën uit meerdere methodes worden gecombineerd. Scrum bevat vernieuwende invalshoeken en kan daarmee bijdragen aan een zo’n methode. Daarentegen is Scrum naar mijn mening te licht en onpraktisch om als fundament of zelfstandige methode te dienen (ook niet de combinatie van Scrum plus XP). Van de andere kant vind ik dat iedere bedrijf toch zeker 90% van de sterkte punten uit Scrum zou moeten toepassen in (een van0 zijn  methode(s), zoals genoemd in de lijst uit mijn vorige blog.

Bronnen

• SCRUM Fails to get to grips with Human Psychology
• Is there a place for criticism of Scrum?
• Scrum presentatie van iSense Awareness

Scrum doet onder andere de volgende aanbevelingen:

Werk iteratief

• Splits een project op in deelprojecten (iteraties) van 2 tot 4 weken. Iedere iteratie levert werkende software op. Hierdoor worden problemen en uitloop snel inzichtelijk zodat hierop kan worden bijgestuurd.
• Klantdemo’s van de software aan einde van iedere iteratie zorgen voor een gemotiveerd team. De feedback van de klant en de kleine mijlpalen zorgen voor extra “motivatie” om de deadlines te halen.

Video’s

Scrum in 10 minutes video’s

Scrum in 10 minuten in het nederlands (ook de moeite waard na het zien van de vorige video):

Video met presentatie met een van de scrum makers (1 uur)

Presentaties

Scrum is een lichtgewicht methode.

Niet plannen maar gewoon beginnen.

Klant bepaalt hoe accuraat een schatting is.

Contact boven documentatie

Webinterface en naamsbekendheid

Topteam biedt ook een web interface via de gratis Web access Server. Deze is echter beperkt tot het inzien van het ontwerp. Voor het online reviewen van ontwerpen en inzien van de change / issues / task lijsten  is een extra server licentie vereist. Niet zozeer een technische beperking is de beperkte aandacht voor marketing en het ontbreken van een topteam community. De naamsbekendheid  van de tool is klein.  De website van de leverancier is verouderd en rommelig. Een eenduidige product/feature/prijslijst ontbreekt. Gemiste kans is ook dat er geen gratis versie is voor kleinere projecten.

Praktijk en conclusie

Redhotminute heeft Topteam ondertussen voor verschillende klanten ingezet. Daarbij is de initiële  investering in de tool al terugverdiend doordat use cases in de helft van de tijd waren op te stellen. Daarbij  is de kwaliteit, leesbaarheid en onderhoudbaarheid van de ontwerpen omhoog gegaan. Mijn mening is dan ook dat een soortgelijke tool onmisbaar is voor ontwerp teams die naast requirements ook werken met Use cases.De tool voelt solide, doordacht en volwassen aan.

De leverancier heeft de uitgebreide tool toch gebruikersvriendelijk weten te houden. Collega ontwerpers,  testers en developers  konden met minimale instructie zelf aan de slag met de tool.  Ontwerp documenten als de requirements analyse en het functionele ontwerp genereren we grotendeels vanuit topteam. Delen die niet uit topteam komen staan reeds in de projectspecifieke word template  en komen uit andere tools als Visual Paradigm(business object model) en Axure (schermen). Het eenmalig aanpassen van de ontwerp templates  aan de bedrijfsstandaarden heeft in het begin wel dagen gekost. Ook gebruiken we de mogelijkheid  om testcases te generen op basis van Use cases scenario’s.  Hiermee  wordt een aanzienlijke hoeveelheid dubbel werk voorkomen.

Ook andere bedrijven in Nederland hebben ondertussen de tool ontdenkt, zoals een bank, een grote luchthaven, een grote elektronica multinational en een ministerie. Redhotminute  heeft geen spijt van de keuze voor Topteam en verwacht de komende jaren  met deze tool verder te gaan.

Productinfo

• Producent en product: Topteam Analyst 5.12 Team Standard edition
• Prijs standard edition: (ex. BTW, ex optioneel onderhoudscontract (20%)) Prijzen zijn op aanvraag, wij betaalden 829 euro per named licentie. Collaboration webserver 20 users eenmalig  prijs is op aanvraag (readonly  webserver  is gratis)
• Nederlandse reseller: Synergio, deze biedt tevens een SaaS variant, prijs op aanvraag, licentie per maand per user (min 5 users).
• Systeemvereisten: Voor zowel client en server: Windows 2000 en hoger. Database: Oracle, SQL server of interne database.

Links

• Producent: www.technosolutions.com
• Reseller en SaaS: www.synergio.nl
• Feauture matrix:  www.tinyurl.com/ttmatrix
• UML modelleringmethode die Redhotminute binnen topteam toepast: www.tinyurl.com/pragmatischmodelleren
• Een directe concurrent: www.casecomplete.com

Hoe kunnen ontwerpen toegankelijker worden gemaakt?

Use case (scenario) modellering kan hier uitkomst bieden omdat alle interactie tussen het systeem en de gebruiker wordt uitgewerkt. Het ontwerp wordt ook toegankelijker en makkelijker te controleren  door  de visuele representaties van uses cases in bijvoorbeeld het context diagram en activity diagrams. De volledigheid van een ontwerp kan o.a. worden gecontroleerd door requirements te koppelen aan Use cases en Use cases aan (prototype) schermen. In de praktijk worden Use cases echter vaak niet uitgewerkt omdat dit in Word en de losse tools arbeidsintensief is. Tevens is het aanbrengen en onderhouden van relaties tussen requirements en Use cases eveneens arbeidsintensief, foutgevoelig en lastig te controleren. Dit is exact de behoefte waar Topteam op inspeelt.

Requirements modelleren in Topteam

Topteam is een client-server applicatie met een Windows interface. Na inloggen toont de applicatie de project tree met o.a. requirements, Use cases, schermen, woordenlijst, diagrammen (zie afbeelding 1). Tevens zijn er speciale doorsnedes o.a. voor het bewerken van requirements, Use cases, issues/RFC’s, Testcases en projecten.

Requirements kunnen worden geïmporteerd vanuit Word of Excel, waarbij ook kenmerken als type (b.v. non functioneel) en prioriteit mee worden genomen. Requirements kunnen ook direct in Topteam worden ingevoerd, waarbij de gebruiker de keuze heeft tussen een Word achtige interface (genummerde lijst met nivo’s) of een lijst/boom interface. Dit is waar de meeste requirements management tools stoppen. Topteam bevat echter ook een uitgebreide ondersteuning voor het verder vertalen van de requirements naar Use cases en daar vervolgens weer schermen aan te koppelen. Op basis van de Use case lijst kunnen één of meerdere Context en Use case diagrammen worden gegenereerd.

Wijzigingen in het Use case diagram, bijvoorbeeld het tekenen van een relatie tussen een Actor en een Use case, worden ook bijgewerkt in de Use cases en vice-versa. De requirements kunnen eenvoudig aan Use cases worden gekoppeld door eenvoudigweg een lijn tussen beiden te trekken in het “Tracebility diagram”. Hierdoor heb je als ontwerper bij het beschrijven van de Use Case de requirements direct bij de hand.

Krachtige functionaliteit rondom Use cases

Het bewerken van Use cases, en met name Use case scenario’s, is waar Topteam in excelleert.  Het uitwerken van de scenario’s gebeurt in een Word-achtige interface die razendsnel werkt en waarbij het systeem begrijpt wat wordt ingevoerd.  Zo worden Actoren, schermen, andere Use cases en begrippen automatisch herkend of kan de gebruiker deze kiezen uit een lijst. Op deze manier wordt ook de traceability links tussen Use cases en requirements, Use cases en schermen vastgelegd.

Kers op de taart is het Activity diagram, eventueel met swimlanes,  dat de tool geheel automatisch genereert op basis van de scenario’s. De gebruiker kan projecten, releases en iteraties definiëren en hier de requirements en Use cases aan koppelen. Hierbij bieden de vrijwel onbegrenste querymogelijkheden van de tool een helpende hand, doordat zowat elke doorsnede door de repository kan worden gemaakt, en alle gevonden items vervolgens in één keer kunnen worden bewerkt (b.v. koppelen aan een release).

Solide versiebeheer en Word ontwerpen genereren

Topteam houdt automatisch van vrijwel alles een versiehistorie bij, waarbij voor iedere wijziging een nieuwe versie wordt aangemaakt. Zo kan je altijd teruggevallen op een oudere versie. En kunnen verschillen tussen versies worden bekeken. Tevens kunnen projectbrede baselines worden aangemaakt.

Topteam kan ontwerpen in een Word document generen door een doorsnede te maken uit de repository.  Standaard worden er maar liefst 60 templates meegeleverd die geheel naar eigen hand aan te passen zijn. Hierbij kan ook gebruik worden gemaakt van de tracebility links, bijvoorbeeld om bij een Use case gerelateerde requirements en schermen te tonen.

Tevens biedt topteam de mogelijkheid het hele ontwerp te exporteren naar Microsoft TFS waardoor de projectmanager en developer direct kan plannen en ontwikkelen op basis van Use cases.

Volgende week deel 2 van de review, met daarin de beperkingen, praktijkervaring en conclusie!