Posts Tagged ‘agile’

Continuous Architecture: organisatiestructuur volgt architectuur

In mijn vorige blog: de 10 best practices van continuous architecture, heb ik als één van de onderdelen genoemd dat de teamsamenstelling binnen een organisatie een afspiegeling dient te zijn van de architectuur. In deze blog zal ik dit verder toelichten en mijn zienswijze hierop geven.

Wat moet je doen als je als organisatie een op SOA principes gebaseerde architectuur hebt omarmt, maar jou ICT organisatie nog traditioneel is ingericht. Functionele afdelingen van ontwikkelaars, testers, infraspecialisten, soms nog per gebruikte technologie waarvan mensen als naar gelang behoefte worden ingezet in projecten. Projecten die allemaal bouwen aan hetzelfde op SOA gerichte IT-landschap, en daardoor ook meer en meer afhankelijkheden krijgen van elkaar. Lees Verder

10 best practices van Continuous Architecture

In mijn vorige blog heb ik gesproken over de noodzaak voor Continuous Architecture. Het vakgebied Architectuur dient zich aan te passen aan de agile omgeving waarin het zich bevindt. Architectuur moet het doel hebben om continu en just-in-time voorzien van architectuur aan teams, programma’s en de organisaties als geheel.

In deze blog bespreek ik 10 best practices om Continuous Architecture in de praktijk vorm te geven:

1. Architectenrol in teams (2-4 teams per architect)
Elk agile ontwikkelteam dient de rol van architect te kennen en deze ook in te vullen. Een architect (met kennis van business, informatie en infrastructuur) is voor deel van zijn tijd toegewezen aan team. De architect zal ook bij het team zijn enige werkplek hebben. Meestal is het geen fulltime functie en kan één architect meerdere teams bedienen (2-4). De architect is beschikbaar voor directe architectuur vragen vanuit de teams tijdens de dagelijkse standups, welke zo veel mogelijk worden bijgewoond door de architect. Lees Verder

Continuous Architecture, the next wave…

Meer en meer organisaties organiseren hun IT voortbrengingsproces op een Agile manier. De slechte ervaringen met de oude manier van werken, de vele IT projecten die zijn mislukt of gigantisch zijn uitgelopen, maar ook de belofte om continu waarde te leveren haalt vele organisaties over de streep. De eerste resultaten hierbij zijn ook goed. Er wordt veel sneller werkende software gerealiseerd en organisaties merken dat om deze snel in hun landschap te laten landen er ook veel meer aandacht moet zijn voor automatisch testen en continuous deployment. Continu werken aan werkende software op basis van de prioriteiten gesteld door de product owner zorgt er daarnaast voor dat projectmatig werken ook steeds meer op de achtergrond verdwijnt. Lees Verder

Valt de architect met DevOps weer buiten de boot?

De opkomst van Agile en Scrum creëerde voor veel architecten een kleine identiteits crisis: mag ik nog meedoen, hebben de Scrum teams mij nog nodig, wat is mijn rol in deze nieuwe wereld?

Op dit moment krijgt DevOps veel aandacht, en weer mag de architect zich afvragen: wat is mijn rol in deze nieuwe situatie?

Eerste uitdaging is om helder te krijgen wat DevOps nou precies is? Development en operations in 1 team? Development die ook verantwoordelijk is voor operations? Soort Agile/scrum maar dan gericht op samenwerking tussen Development en Operations, zoals Agile focust op een betere samenwerking tussen opdrachtgever en ontwikkelteams?

Er zijn volgens mij 2 zienswijzen op DevOps die haaks op elkaar staan:

  1. Geen samenwerking – DevOps is ontstaan uit cloud (IAAS en PAAS). Cloud biedt ontwikkelaars een soort self-service omgeving waardoor ze eigenlijk alles zelf kunnen en dus helemaal niet hoeven samen te werken met operations. Operations is zo eenvoudig geworden dat ontwikkelaars dit zelf kunnen. De echte operations zitten bij de cloud leverancier en hebben nauwlijks nog contact met de ontwikkelaars. Ontwikkelaars zijn zelf operations geworden voor de applicaties die ze opleveren. Mooi voorbeeld: Amazon – You build it, you run it
  2. Meer samenwerking – De afstand tussen ontwikkelaars en operations is te groot (gooi maar over de muur, operations kan het aantal releases niet aan, etc) dit is op te lossen door beter samen te werken. Operations en development in 1 team.

De interessantste link die ik zie met architectuur is dat DevOps initieel volgens mij is ontstaan door keiharde standaardisatie vanuit de cloud. Het was duidelijk welke middelen beschikbaar waren voor projecten, onderhandelen met operations was niet meer nodig, en dus konden ontwikkelaars het zelf regelen via een selfservice interface. (IAAS zoals amazon, maar PAAS als heroku trekt dit nog veel verder)

Ik zie vaak dat architecten zich bezig houden met de vraag: “welke middelen gaan we beschikbaar stellen?” terwijl ervaren ontwikkelaars prima de vraag “Hoe gaan we die middelen inzetten voor dit project” kunnen beantwoorden.

IAAS en PAAS middelen worden echter steeds complexer, en het ontwerpen van een goede oplossing vraagt om veel kennis en ervaring. Vraag me wel af of de huidige architecten deze rol nu goed kunnen invullen, gezien ook dit verhaal: CloudCheckr: Amazon Complexity Challenges Many Users.

Net zoals bij Scrum draait DevOps vooral om het sneller leveren van software. Minder schakels levert meer snelheid op. Snelheid is iets wat erg gewenst wordt door “de business” en wat nu vaak als problematisch wordt ervaren.

Vroeger was snelheid vaak synoniem met productief: ontwikkelaars hadden productieve tooling nodig (drag en drop, visueel) en dan zouden ze sneller kunnen ontwikkelen, en daardoor sneller opleveren.

De laatste jaren zie je dat mensen zich realiseren dat snelheid meer aspecten heeft:

  • beter samenwerken, minder over de muur (agile), minder schakels,
  • automatiseren van alle stappen (test, continuous deployment, continuous integration)
  • automatisering van alle stappen betekent ook dat operations meer bezig is met scripten (dev) zodat alles sneller en herhaalbaarder wordt.

Als een architect iemand is die vooral bezig is met keuze van middelen, dan zou een DevOps architect dus goed moeten begrijpen dat de keuze moet gaan naar tooling die automatisering enabled. Tools die inzet van continuous integration en continuous deployment mogelijk maken, een cloud platform wat mbv APIs geautomatiseerd ingericht kan worden.

Agile en Scrum versus waterfall

Een kort overzicht van de belangrijkste verschillen tussen Agile en Scrum ten opzichte van de waterval methodiek:

  • 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 gefaseerd – 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. Een kort overzicht van de belangrijkste verschillen tussen Agile en Scrum ten opzichte van de waterval methodiek:

  • 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.

Overeenkomsten tussen Cloud, Agile en Open Source

Het belangrijkste voordeel van zowel Cloud als Agile als Open Source is volgens mij hetzelfde: Snelheid en time-to-market.

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 een Project Leider

Een project leider is verantwoordelijk voor de succesvolle uitvoering van een project. Hierbij is succes meestal gedefinieerd als op tijd, binnen budget, en met alle van te voren afgesproken eigenschappen.

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.

Presentation: Introduction to Agile and Scrum

Just uploaded my first presentation to speakerdeck. It’s an introduction to scrum. I use it mainly as support for presentations, so it’s a bit lacking without me talking…

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).

http://speakerdeck.com/u/andrkoel/p/introduction-to-scrum

Orginal post: Introduction to Agile and scrum.

Werner Vogels on Amazon Cloud

The next web linked to a really interesting presentation by Amazon’s CTO: Amazon’s CTO: “Amazon is a technology company. We just happen to do retail”.

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.

Roundtable Product Management & Architectuur

Op woensdag 16 november organiseert IT-eye een roundtable rond het thema Product Management & Architectuur. De roundtable zal worden gehouden ten kantore van IT-eye aan de Waterveste 1-3 in Houten.

Wat gaan we bespreken?

Agile systeemontwikkeling is niet meer weg te denken uit de dagelijkse praktijk van IT afdelingen van grote en kleine organisaties. Technieken als Scrum en Open Agile worden steeds meer toegepast, maar nog met wisselend succes. IT-eye vindt dat Agile systeemontwikkeling binnen organisaties sterk kan verbeteren door de toepassing van Product Management & Architectuur.

Tijdens de agile roundtable deelt IT-eye haar visie met de aanwezigen en gaat in de op de vraag hoe je met agile echt successen boekt. Daarnaast is er natuurlijk voldoende ruimte om kennis en ervaringen te delen, te leren van collega’s, en kritische vragen te stellen. Na deze avond heb je een helder beeld van de toegevoegde waarde van Agile, en wijze waarop de juiste inrichting van Product Management & Architectuur je grip bieden op IT ontwikkelingen in je organisatie.

Het programma

Het programma voor de roundtable ziet er als volgt uit:

16:00-16:30 Ontvangst
16:30-17:15 Roundtable 1: Product Management is the key!
17:15-17:30 Pauze
17:30-18:15 Roundtable 2: Architectuur is cruciaal voor Agile
18:15-19:00 Diner
19:00-19:45 Roundtable 3: De IT-eye methode voor Architectuur binnen Agile: Agile Architecting
19:45-20:30 Borrel
Tijdstip Beschrijving

De avond is opgedeeld in 3 onderdelen:

  1. Roundtable 1: Agile draait niet om software development. Het is in eerste instantie een raamwerk voor product managers. Voor een succesvolle inzet van Agile is het essentieel dat dit wordt onderkend in de organisatie.
  2. Roundtable 2: ”Agile is leuk voor kleine teams, maar werkt niet voor grote organisaties”. Dit is een veelgehoorde zorg. Architectuur biedt hier de oplossing. Wij laten u zien waarom architectuur essentieel is voor bedrijfsbreed Agile ontwikkelen.
  3. Roundtable 3: Afsluitend kijken we naar het architectuur proces: hoe zorgt u ervoor dat de manier waarop u architectuur bedrijft zo goed mogelijk aansluit bij Agile product development? Traditionele manieren van architectuur bedrijven gaan vaak ten koste van de voordelen van Agile. Agile Architecting is de methode die IT-eye hanteert om Architectuur zo goed mogelijk aan te laten sluiten bij Agile.

Inschrijven

Nieuwsgierig? Meepraten? Meld je nu kosteloos aan via secretariaat@it-eye.nl

Contact

Wattbaan 51-1, 3439 ML Nieuwegein, Nederland
Telefoon: 030–602 82 80
Website: http://iteye.wpengine.com
Email: info@it-eye.nl