Publicaties Scrum/Agile


Prowareness biedt verschillende publicaties aan. Hierbij kunt u denken aan whitepapers op het gebied van Outsourcing, .NET, software development, Agile en Scrum. Ook vindt u hier diverse door Prowareness gepubliceerde artikelen.


Implementing the Product Backlog

One of the most important artifacts in Scrum is the Product Backlog. The Product Backlog is owned by the Product Owner and should be the single source for any changes that you make to your product. The Scrum Guide tells us WHAT a Scrum Team should do with the Product Backlog to guarantee that we are continuously focusing on building the highest value features each Sprint. What the Scrum Guide doesn’t tell us is HOW to implement this Backlog and how it is used on a day to day basis. This is actually a good thing, since we don’t want to be too prescriptive towards our community, do we? This means we are creating the boundaries for a successful Scrum implementation without telling people how they should do their work (Individuals and Interactions over Processes and Tools).


This whitepaper contains a number of best practices on HOW your Product Backlog can be implemented. This paper is for those who are struggling with Product Backlog implementation or are searching for new ideas to improve their current implementation.




Rini van Solingen schrijft artikel in Kwaliteit in Bedrijf


In Kwaliteit in Bedrijf schrijft Rini van Solingen, CTO bij Prowareness, over zijn nieuwste boek Scrum voor Managers. ‘Scrum is geen kunstje. Het is een revolutionair andere manier van werken en die pak je niet 1-2-3 op. Werken met Scrum is een leerproces dat je stap voor stap helpt steeds beter te worden in het kortcyclisch leveren van waarde. De rol van de manager is daarin cruciaal. De veranderingen die voortkomen uit het werken met Scrum geven energie, juist voor de manager. Want primair de focus leggen op verbetering, wie vindt dat nu niet leuk?’, aldus Rini.


In zijn artikel schrijft Rini ook over de populariteit van Scrum. ‘Het lijkt wel of iedereen tegenwoordig aan het ‘Scrummen’ is. De belangrijkste reden voor de populariteit van Scrum is dat het een fundamentele oplossing biedt voor het telkens weer uitlopen van projecten en het ernstig overschrijden van budgetten. Scrum lost dit probleem namelijk op aan de bron: via korte cycli direct sturen op een werkend product met de maximale waarde. En dat werkt!’.

Het volledige artikel van Rini van Solingen is hier te downloaden. Scrum voor Managers is verkrijgbaar in de Scrum webshop van Prowareness.



Managing Defects in an Agile environment

Teams often struggle with answering the following question: “How to manage our Defects in an Agile environment?”. They start using Scrum as a framework for developing their software and while implementing, they experience trouble on how to deal with the Defects they find/cause along the way. Scrum is a framework that does not explicitly tell you how to handle Defects. The strait forward answer is to treat your Defects as Product Backlog Items that should be added to the Product Backlog. When the priority is set high enough by the Product Owner, they will be picked up by the Development Team in the next Sprint. The application of this is a little bit more difficult and hence should be explained in more detail.






Lean voor Software Ontwikkelbedrijven

Enkele praktische tips

Overal waar mensen werken gaan dingen mis. Veel mensen hebben zoveel taken tegelijkertijd dat het hun ook niet echt te verwijten valt. Er is gewoon veel te doen. Het is wenselijk dat iedereen zich op ťťn ding kan richten, want dat lijkt efficiŽnter. Maar hoe realiseer je dat in een kleine dan wel grote organisatie? Is dat voor het hele bedrijf efficiŽnter? Door enkele concrete punten uit Lean op te pakken, loopt de hele organisatie veel efficiŽnter en effectiever. Hoe u dit kunt doen leest u in deze whitepaper.








From vision to value

How to translate vision into a product, fast?

In een bedrijf zijn vaak meerdere medewerkers bezig met het vertalen van visie naar een waardevol product. In de tussentijd, lijkt het, alsof een ander onderdeel van het bedrijf bezig is met het maken van een product met weinig waarde. Hoe krijg je in een dergelijk bedrijf alle neuzen dezelfde kant op? En hoe betrek je dan de ‘lastige’ klanten bij jouw product, die telkens jouw beeld van visie in de war schoppen? Allemaal vragen die je vast en zeker ook binnen jouw bedrijf kan stellen.

Het gebruik van methodieken en frameworks in de afgelopen jaren, is binnen de IT sterk toegenomen. Scrum wordt veel toegepast bij product ontwikkelclubs. Er worden veel verschillende ontwikkel frameworks gebruikt om grip te houden op de complexe materie en producten.






Agile business intelligence, kan dat wel?

Vrijwel elk softwareteam is bezig met agile ontwikkelen of is dat aan het overwegen. Agile biedt een fundamentele oplossing voor uitlopende projecten en budgetoverschrijdingen. Kun je agile ook voor business intelligence gebruiken? Business intelligence is toch iets heel anders dan softwareontwikkeling?

Softwareontwikkeling wordt (of werd) hoofdzakelijk gedaan conform een soort van waterval. Deze bestaat uit ťťn enkele cyclus waarin analyse, ontwerp, realisatie, test en implementatie elkaar opvolgen. Deze fases worden sequentieel doorlopen. In de analyse- en ontwerpfase wordt de benodigde functionaliteit bepaald en gedocumenteerd. Vervolgens wordt de software gebouwd, getest en in gebruik genomen. Een dergelijke enkelcyclische aanpak is gebaseerd op drie uitgangspunten...

Lees hier het volledige artikel.


Kaarten onder werktijd



Planning poker leidt tot nauwkeurige schattingen IT-projecten.


Om IT-projecten beter in te schatten maken veel agileteams gebruik van ‘Planning poker’. De praktijk laat zien dat schattingen met deze methode sneller tot stand komen, beter kloppen en leiden tot een hogere voorspelbaarheid van projecten. Michael Franken en Rini van Solingen bespreken de waarde van deze methode en geven tips voor het gebruik ervan.

Veel agileteams schatten het werk in met behulp van ‘Planning poker’. Dit is een slim hulpmiddel dat ervoor zorgt dat een team betere schattingen maakt.

‘Beter’ in de zin van nauwkeuriger, breed gedragen, realistischer. Maar bovenal beter doordat een leercurve is geÔntegreerd die zorgt dat er geleerd wordt van de vorige schatting bij het maken van de volgende...

Lees hier het volledige artikel.


Lean en Scrum: een Siamese tweeling?




Lean maakt niet concreet wat er moet gebeuren, Scrum wel


Veel organisaties zijn druk bezig om agile (in het bijzonder Scrum) te implementeren. Toch zijn er maar weinig organisaties die hun hele bedrijfsvoering agile inrichten. Door veel directies worden wel vaak organisatiebrede verbeterprogramma’s opgestart, vaak met behulp van de ‘Lean’-aanpak. De IT-manager is daarom niet te benijden: net bezig om op een agile-manier, iteratief, software te ontwikkelen, dan komt Lean daar ook nog eens bij. Wat is het verschil? Kunnen de twee aanpakken elkaar aanvullen? Scrum is een raamwerk voor softwareontwikkeling dat via korte iteraties (sprints) van enkele weken steeds weer werkende software oplevert die telkens de hoogste toegevoegde waarde heeft. Scrum is een eenvoudig raamwerk bestaande uit drie rollen (productowner, Scrummaster en teamleden), vier meetings (sprintplanning, daily stand-up, sprintreview en sprintretrospective), en vier artefacten (werkend product, productbacklog, sprintbacklog en definition-of-done). Lean-softwareontwikkeling bestaat uit zeven principes waarmee een organisatie haar proces en producten kan optimaliseren. Lean bestaat vooral uit principes en maakt niet concreet wat er precies wanneer moet gebeuren. Scrum daarentegen doet dat wel. Scrum is veel methodischer dan Lean: het legt een raamwerk neer hoe je als organisatie op een agile-manier software ontwikkelt.

Lees hier het volledige artikel...



Lean VS Agile

Agile is vaak een IT feestje. Er zijn maar weinig organisaties die actief bezig zijn hun hele bedrijfsvoering op een Agile manier in te richten. LEAN, daarentegen, komt wťl bedrijfsbreed voor en wordt als gehele verbeterfilosofie gepositioneerd. In deze whitepaper bespreken Henk Jan Huizer en Rini van Solingen hoe LEAN en Agile (en in het bijzonder Scrum) bij elkaar passen en welke consequenties dit heeft voor de praktijk. Hun belangrijkste conclusie is dat, los van de aanpak, een verbetering gericht moet zijn op de hele keten. De doorlooptijd van vraag tot antwoord, van probleem tot oplossing, van concept to Cash moet zo kort mogelijk zijn. Pas aan het einde van de keten lever je namelijk waarde. Om de beste resultaten te halen is het daarom essentieel om naar de hele keten te kijken. Prima om met Scrum bij IT te beginnen, maar vergeet het voortraject en het opleverproces niet. Immers, hoe sneller waarde en resultaat, hoe LEAN-er de organisatie wordt.







Agile en nieuwe werken uitstekend span


Het ‘nieuwe werken’ en ‘agile’ zijn twee trends waar je als organisatie bijna niet omheen kunt. Op het eerste gezicht lijken zij onverenigbaar: bij Agile staat het team centraal, bij het nieuwe werken het individu. Maar zijn zij ook onverenigbaar? Dick Stegeman en Rini van Solingen bespreken de overeenkomsten en verschillen.

Lees hier het artikel in de Automatiseringsgids…


Scrum en functiepunten: vrienden of vijanden?

Wie goed kijkt, ziet dat FPA en Scrum elkaar uitstekend aanvullen



Veel organisaties gebruiken functiepunten om meer grip te krijgen op hun softwareprojecten. Tegelijkertijd werken zij vaak met Agile methoden, doorgaans Scrum. De grote vraag is in hoeverre functiepunten zijn te combineren met Agile. Gooit Scrum roet in het eten? Hebben functiepunten nog waarde? Jolijn Onvlee en Rini van Solingen onderzoeken de mogelijkheden.

Agile (met Scrum als meest gebruikte aanpak) wordt door een sterk groeiend aantal organisaties omarmd als de oplossing voor het mislukken van grote IT-projecten. Door al direct te starten met het opleveren van de software krijgt een opdrachtgever elke twee weken direct inzicht in de voortgang en toegevoegde waarde. Hierdoor hoeven gebruikers niet langer te wachten op de functionaliteit die voor hen de hoogste businesswaarde heeft.

Lees hier het volledige artikel.



FedEx Days

A FedEx Day is a 24-hour event in which employees deliver innovation to the company they work for. It is called FedEx Day, because you have to deliver overnight, like the parcel delivery company. A FedEx Day is a fixed time box in which people are not disturbed for regular work. Within this time box, employees have total autonomy over the project they are enthusiastic about. They decide for themselves what they will be working on, who they are going to work with, and how they are going to do it. Only one rule applies: People who sign up show the results to the company at the end of the FedEx Day. In short, a FedEx Dayis about boosting motivationand creativity overnight by getting out of people’s way.








Whitepaper Agile Architectuur

Hoe gaan Agility en Architectuur samen en wat is de impact op de architect?

Wanneer organisaties zich oriŽnteren op het gebruik van Agile werkwijzen ontstaat al snel de vraag op welke manier ze met architectuur om moeten gaan. Agile heeft tenslotte de neiging om niet al te ver vooruit te plannen en beslissingen uit te stellen tot een later tijdstip waarop meer kennis beschikbaar is. In traditionele omgang met architectuur nemen we echter belangrijke beslissingen juist vooraf. Het is dan ook logisch dat de combinatie van Agile en architectuur in eerste instantie wat ongemakkelijk aanvoelt. Dat is het centrale thema van deze whitepaper. Agile werken heeft namelijk verstrekkende gevolgen voor het omgaan met architectuur.

Klik hier om de preview van de whitepaper online te lezen.




Architectuur en Agile: ongelukkig huwelijk?


Agile-methoden en architectuur lijken op het eerste gezicht niet samen te gaan. Het slechte huwelijk berust echter op misvattingen, zeggen Kees Jan Bender en Rini van Solingen. Een architectuur is niet per definitie in beton gegoten. Aan de architect worden wel bijzondere eisen gesteld: hij moet ‘dienend in het team staan’ en niet directief optreden.


Het gebruik van Agile-methoden (met Scrum als meest populaire) groeit sterk. Agile-aanpakken kenmerken zich door het in korte cycli (van enkele weken) opleveren van werkende en geteste software, waarbij het meest waardevolle als eerste wordt gedaan. Het werk wordt daarbij uitgevoerd door kleine zelfsturende en multidisciplinaire teams. Hoewel veel organisaties Agile serieus overwegen of er al ervaring mee hebben, blijkt dat er in de praktijk nog veel misverstanden en vooroordelen over Agile-methoden bestaan (zie Automatisering Gids 28 januari 2011: ‘Veel vooroordelen over Scrum’). Eťn van die misverstanden is dat Agile en architectuur niet samengaan. Door de flexibele en wendbare inslag van Agile-aanpakken zou het niet mogelijk zijn om goed onder architectuur te werken. Dit is echter onjuist. In het kader bespreken we de zeven meest voorkomende misverstanden over het schijnbare conflict tussen Agile en architectuur. De hoofdoorzaak van deze misverstanden is dat Agile-methoden zich sterk afkeren van ‘Big Design Up-front’. Agile-methoden gaan namelijk uit van voortschrijdend inzicht. Ze baseren zich op de ervaring dat gedurende het ontwikkeltraject geleerd wordt en er zo steeds meer helderheid ontstaat over het op te lossen probleem. Het is daarom onmogelijk om vooraf een volledig ontwerp te maken dat daarna ‘alleen nog maar gebouwd moet worden’. Om die reden gaat Agile anders met architectuur om: Agile laat de architectuur ‘ontstaan’ tijdens het project...

Klik hier om het volledige artikel in PDF te downloaden.

Bekijk hier de videoblog van Rini van Solingen over dit artikel.


Veel vooroordelen over Scrum


Scrum is een populaire methode voor software development, maar de toepassing ervan laat te wensen over. Om van deze aanpak een succes te maken, moeten er fundamentele veranderingen worden doorgevoerd, zeggen de auteurs van dit artikel. Veel organisaties liften mee op de Scrumhype, zij profiteren er nauwelijks van.

Scrum is hard op weg de populairste aanpak ter wereld te worden voor software- en systeemontwikkeling. Veel organisaties gaan met Scrum aan de slag om sneller betere producten te ontwikkelen. Dit lijkt gemakkelijk omdat deze aanpak zich beperkt tot slechts drie rollen, vier meetings en drie werkproducten. Ondanks deze eenvoud blijkt in de praktijk dat het voor velen toch niet zo gemakkelijk is om Scrum goed toe te passen. Daardoor realiseert men niet de beloofde kwaliteits- en productiviteitsverbeteringen. De oorzaak hiervan is veelal gelegen in een incompleet beeld van Scrum. Er bestaan veel misvattingen rond Scrum..



De kracht van Scrum

In dit bijzondere managementboek, mede geschreven door Rini van Solingen, Chief Technology Officer bij Prowareness, wordt het verhaal verteld van Mart Verhulst, CTO bij een softwarebedrijf. Mart Verhulst worstelt met een hopeloos vertraagd softwareproject voor een Amerikaanse klant. Met behulp van Pekka, een Finse Scrum Coach, gooit hij het roer om, waarbij hij een aantal van de veel voorkomende problemen in zijn organisatie structureel oplost.



Kan Scrum fixed price?

Middels de projectmanagementmethode Scrum proberen bedrijven hun IT-systemen snel en efficiŽnt te bouwen. De methode werkt door te ontwikkelen met korte iteraties waarna tussenversies van het product worden opgeleverd. Maar hoe staat het met de kosten? Is de methode te combineren met fixed-pricecontracten?



Klik hier voor onze publicaties over Agile Teams.