• Kleine deel opleveringen – Een agile project probeert niet het geheel in een keer op te leveren, maar juist regelmatig kleine stukjes op te leveren. Dit heeft een aantal voordelen. Gebruikers kunnen zo snel mogelijk aan de slag met wat er gerealiseerd is. Je hebt beter in de gaten wat de status is van een project, omdat delen echt afgerond moeten worden voordat ze opgeleverd kunnen worden. Software wordt eerder in de praktijk gebruikt en je weet dus beter of hetgeen je bedacht en gerealiseerd hebt ook echt is wat de gebruikers nodig hebben.
• Feedback lus – Agile gaat ervan uit dat veel ontwerp beslissingen aannames zijn. Deze aannames dienen getoetst te worden tegen de realiteit. Het is dus nodig zo snel mogelijk feedback te krijgen over deze beslissingen. En de beste feedback is feedback uit de praktijk. Wat vinden de gebruikers van je ontwerp beslissingen? Deze feedback krijg je door zo snel mogelijk ontwerpen uit te werken in werkende software en in de praktijk te laten gebruiken.
• Incrementeel ipv gefasseerd – Een waterval project kent verschillende fasen: requirements, ontwerp, bouw, test, implementatie. Een agile project is opgedeeld in meerdere deel-opleveringen met features. Tijdens iedere iteratie worden de fasen voor de verschillende features doorlopen, maar niet als geheel. Als je eerst alles ontwerpt, zoals dat bij waterval gebeurt, is de kans groot dat je tijd stopt in zaken die gedurende het project achterhaald zijn. Misschien doordat wensen veranderen, of omdat aannames die je gemaakt hebt in het ontwerp niet kloppen. Door niet te ver vooruit te werken beperk je het risico dat je onnodig werk doet.
• Prioriteren – prioriteren is een belangrijk onderdeel van Agile werken. Welke features zijn het belangrijkst en welke minder. De taak van de Agile project leider is om de wensen van de gebruikers te begrijpen om zo de juiste volgorde vast te kunnen stellen. Hij moet ervoor zorgen dat iedere iteratie datgene oplevert wat voor de gebruikers en de organisatie op dat moment het belangrijkst is.
• Crossfunctional teams – binnen agile projecten werken mensen met verschillende rollen nauw samen. Dit vergroot productiviteit en kwaliteit van communicatie. Het doorschuiven van documentatie van 1 rol naar een volgende, bijvoorbeeld requirements naar ontwerpen, zorgt vaak voor vertraging. Daarnaast gaat er veel informatie verloren. Beter is het om continue samen te werken in 1 team. Een agile team is het meest effectief als alle rollen zijn vertegenwoordigd: analisten, ontwerpers, bouwers, testers en gebruikers.

Agile draait dus vooral om beperken van risico’s, en versnellen van time-to-market, focus op ROI, en focus op kwaliteit door versnellen van de feedback lus.

Hij geeft een overzicht van software die ze gekozen hebben:

• Salesforce voor frontoffice,
• NetSuite voor backoffice: ERP en Finance,
• Gmail voor email, als alternatief voor Exchange,
• Google sites voor collaboration, als alternatief voor Microsoft SharePoint,
• Websphere Iron om het geheel te integreren.

Dit heeft natuurlijk grote voordelen:

• Kosten – veel SAAS oplossingen zijn goedkoper dan traditionele ‘on premise’ software. Vaak wordt er een ander business model gehanteerd, dat uit gaat van minder overhead kosten. Minder direct sales, minder on site ondersteuning. Geen onderhoud aan oude versies. SAAS leveranciers kunnen hun software goedkoper realiseren, en dus goedkoper aanbieden.
• Snelheid – er is veel minder tijd nodig om een SAAS oplossing uit te rollen, dan software lokaal te installeren, en te supporten. Geen tijd nodig voor keuze en installatie van hardware, geen tijd nodig voor installatie software. Geen tijd nodig voor trainen van eigen support mensen. Slechts configuratie.

Ondanks eventuele nadelen, die ook in de reacties op het artikel worden genoemd, is het duidelijk dat Cloud grote voordelen biedt. Minder kosten en minder tijd houdt in dat je meer tijd overhoudt voor andere zaken. Betekent wel dat je je afhankelijkheid van leverancier goed moet regelen, oa door altijd een kopie van je data te hebben.

Cloud biedt je de mogelijkheid om zonder langdurige commitment, slechts af te nemen wat je nu nodig hebt. Lange termijn investeringen zijn overbodig. Dit betekent dat de investerings beslissingen die je neemt over veel minder geld gaan. Dit betekent meestal korte besluitvormingstrajecten, en minder bemoeienis van allerlei mensen in de organisatie.

Agile biedt dezelfde korte termijn commitment. Je financiele commitment heeft een scope van een iteratie. Als een iteratie niet oplevert wat je ervan verwacht had, kun je als management (product owner) besluiten om het project te stoppen of om de functionaliteit aan te passen. Het financiele risico wat je loopt als bedrijf is niet veel groter dan de investering van 1 of maximaal een paar iteraties. Tegelijkertijd heb je ook veel sneller werkende software waarmee je gebruikers aan de slag kunnen.

Open Source is veelal gratis. Je kunt de software testen en indien het geschikt is kun je het snel inzetten. Een langdurig koop traject, inclusief prijsonderhandelingen is vaak overbodig. Minder mensen zijn betrokken bij de besluitvorming rondom de aanschaf. Samenwerking met de afdeling inkoop is vaak niet eens nodig. Dit biedt bedrijven weer de mogelijkheid om sneller te handelen.

Door Cloud, Agile en Open Source te combineren kunnen bedrijven veel sneller handelen.

Een Scrum Product Owner is ook verantwoordelijk voor de succesvolle uitvoering van een project. Hij stuurt een team aan, bepaalt de benodigde eigenschappen van het eindproduct, bepaalt de volgorde waarin wensen gerealiseerd worden, en hij bepaalt wanneer en hoeveel wensen er opgeleverd worden.

Het verschil tussen een product owner en project manager is de manier waarop hij het project managed.

Uitgangspunt van scrum is dat er bij ieder project veel zaken onbekend of onvoorspelbaar zijn. Wensen kunnen onbekend zijn, productiviteit van het team is onzeker, technische uitdagingen kunnen onbekend zijn. Door deze onzekerheid is het onmogelijk om van te voren een plan te maken wat een nauwkeurige voorspelling doet over tijd, budget en opgeleverde eigenschappen.

Een product owner managed een project door zich te verdiepen in de wensen van de gebruikers. Wat hebben de gebruikers nodig? Hij zorgt ervoor dat de belangrijkste aspecten het eerst gerealiseerd worden. Als niet precies bekend is wat gebruikers nodig hebben, of hoe lang het duurt op dit te realiseren is het zaak om te prioriteren.

“Heeft een scrum project een project leider nodig?”

Ja, een scrum project heeft een project leider. De product owner is de project leider.

Originele post: A Product Owner is a Project Manager.

“IT-eye opereert al langere tijd op het vlak van IT & Business architectuur. Omdat we op dit terrein een onafhankelijke positie innemen werd het noodzakelijk ons als zelfstandige organisatie te profileren”, aldus Algemeen directeur Paul Imholz. “Door geen banden te hebben met een andere organisatie of met technologiepartners is deze onafhankelijkheid geborgd. Daarnaast vergroten we onze herkenbaarheid door zelfstandig te opereren”.

Het nieuwe management is al langere tijd werkzaam voor de organisatie. De doelstelling voor de komende jaren is verder te groeien op het gebied van IT & Business architectuur door werving en de realisatie van samenwerkingsverbanden.

“We merken dat onze focus op architectuur een positieve invloed heeft op onze resultaten”, aldus Jan de Harder, Managing partner en commercieel verantwoordelijk voor de resultaten van IT-eye. “Klanten en potentiële medewerkers herkennen en erkennen ons als dé leverancier op het gebied van IT & Business architectuur. Ons product- en dienstenportfolio is het afgelopen jaar sterk gegroeid, zonder daarbij onze focus te verliezen. We bieden onze klanten een compleet pakket aan producten, diensten en tools. Het werken met dit portfolio en met seniore collega’s heeft daarnaast een aanzuigende werking op nieuwe medewerkers”.

IT-eye werkt voor diverse opdrachtgevers binnen sectoren als de Overheid, Semi-overheid, Financiële dienstverlening en Industrie. De dienstverlening is niet branche gebonden.

“Onze focus ligt op een verdere groei in kwaliteit”, aldus Jules de Ruijter, Managing partner en verantwoordelijk voor de ontwikkeling van de propositie en de samenstelling van het architectuur team van IT-eye. “In de achterliggende jaren hebben we ingezet op kwaliteit én senioriteit. Seniore architecten hebben in de regel al een hele carriere achter de rug, hebben met hun voeten in de modder gestaan en hebben in tal van organisaties (advies) trajecten begeleid. Al deze bagage komt uiteindelijk samen in de adviestrajecten bij onze klanten”.

Voor vragen aan één van de managing partners kunt u contact opnemen via het telefoonnummer 030 602 82 80 of stuurt u een email naar info@it-eye.nl.

Gerwin zal hier de laatste bevindingen van zijn methode op het gebied van performance (method-gapp) presenteren.

We wensen Gerwin veel succes!

Als thema voor dit evenement had IT-eye gekozen voor “tijd voor nieuwe ideeen”. Tal van bezoekers hebben hun idee gedeeld met één van de aanwezige architecten en  ingeleverd op de IT-eye stand. Alle inzendingen dingen mee naar één van de twee Ipads. De eerste Ipad is inmiddels verloot en gaat naar Michiel de Vente van Menzis.

Gedurende twee dagen bezochten tal van gasten de IT-eye stand. Ook de presentaties van IT-eye werden goed bezocht. Op 24 november presenteerde Andrej Koelewijn voor een volle zaal zijn visie op de rol van de Product Owner. Op diezelfde dag presenteerde Jules de Ruijter de klantencase van het CAK.

IT-eye heeft richting de organisatie van het LAC de intentie uitgesproken volgende jaar wederom als sponsor deel te nemen.

Er zijn hiervoor een aantal redenen te bedenken:

• Door principes, uitgangspunten en consequenties te beschrijven wordt een kader geboden waarmee het strategisch, tactisch en operationeel management de organisatie kan besturen en te richten
• Complexe vraagstukken worden geanalyseerd en vereenvoudigd. Wij brengen relaties in onderdelen aan en creëren hiermee een overzicht en generieke componenten
• Wij zijn bruggenbouwers tussen een techniekgedreven afdeling (IT) en de interne/externe klant
• De titel Architect is wettelijk beschermd.

Door het opstellen van principes, uitgangspunten en consequenties wordt er een kader gemaakt waarmee het management tot wel overwogen beslissingen kan komen. Dit kader wordt logischerwijs ook met het management doorgesproken, vastgesteld en desgewenst aangepast. Er wordt hiermee een overduidelijke adviesrol vervuld.

Leon de Caluwé  heeft, gezamenlijk met Elsbeth Reitsma, een onderzoek gepleegd naar de competenties van adviseurs. Hierin zijn een aantal basiscompetenties naar voren gekomen. Deze zijn:

• Veerkracht tonen: flexibel zijn
• Analyseren: analytisch, conceptueel denken, lerende oriëntatie en creativiteit
• Beschouwen: oordeelsvorming, omgevingsbewustzijn en visie ontwikkelen
• Faciliteren: luisteren en sensitiviteit
• Beïnvloeden: communiceren, optreden en overtuigingskracht
• Vertrouwen wekken: integriteit, betrouwbaarheid, loyaliteit en gunstige sfeer creëren.

Deze competenties zijn van toepassing op onszelf (Business -, IT -, Solution Architecten).

Dit maakt de stelling van architect naar adviseur sterker. In ons takenpakket vervullen wij zeer veel adviestaken. Wij luisteren nadrukkelijk naar de vraagstukken bij onze interne/externe klant. Deze vraagstukken richten zich veelal op hoe automatisering kan ondersteunen in de bedrijfsvoering van de organisatie. Hierin geven wij aan onze klant een advies, gestoeld vanuit het kader aan principes en uitgangspunten.

De bescherming van de titel van architect is wettelijk bepaald. Wet op de architectentitel voorziet hierin. Deze is sinds 1987 actief en op 25 maart 2010 is deze wet wel aangepast waardoor er middels de toevoeging van Business en/of IT wel door informatici gebruik gemaakt kan worden van de titel van Business Architect, IT Architect en Solution Architect. We zullen echter wel in al onze gesprekken expliciet deze toevoeging moeten gebruiken. Indien wij onzelf alleen architect benoemen dan is dat in strijd met de wet en kan daar een boete tegenover staan.

Als Business Architect beschikken wij over dezelfde basiscompetenties die een adviseur heeft. Wij ondersteunen het management om vanuit architectuur perspectief de organisatie te richten en te besturen waarbij automatisering zo optimaal en toekomstvast als mogelijk wordt ingezet. Daarnaast worden we niet geconfronteerd met boetes die wettelijk opgelegd kunnen worden omdat ik door onoplettendheid verkeerd gebruik heb gemaakt van de titel architect.

Deze argumentatie zorgt ervoor dat de voorkeur gegeven wordt aan een titel van adviseur, desgewenst IT adviseur. Dit is ook voor anderen makkelijk, eenvoudig en duidelijk.

I first discuss the goals of Scrum, before explaining the Scrum framework itself. I think the main object to understand is that you’re trying to manage uncertainty, instead of managing something that is completely known.

Managing uncertainty means that you can’t predict everything upfront, which means that you need to add flexibility in one place (features) to create stability in another (cost, time).

Orginal post: Introduction to Agile and scrum.

Lots of interesting information here:

• Scrum & Agile – small teams, fast innovation, all teams are customer focussed. How to scale.
• Architecture – what’s important when architecting large scale applications. Ideas behind doing SOA
• Cloud – impact of cloud on enterprise software development
• Business – lots of companies are transforming into IT companies, even if they don’t see this yet. This causes problems because they should put the best possible people on their most important assets: software
• Operations – No separate operations department. You build it, you run it.

Werner Vogels: Amazon and the Lean Cloud from HackFwd on Vimeo.

Original post: Werner Vogels on Amazon Cloud.