Posts Tagged ‘scrum’

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.

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

Architecture – the key to scaling Agile

The Future of Agile. … agile methods are more popular than ever. But what’s next? How do we get agile past having a few Scrum teams within an organisation? These are some of the questions asked in the invition to Agile Open Holland.

How do you scale Agile?

Amazon seems to have the answer. Yesterday I linked to a presentation of Werner Vogels talking about the reason Amazon does cloud. In this presentation he mentions that Amazon has hundreds of small teams working on services. All these teams deliver customer value. They are end-customer focussed.

It looks like Amazon has figured out how to scale Agile. The key ingredient here is architecture. They’ve split up all their functionality into services that can be created, maintained, and managed pretty independently. You need a good architecture that will tell you how to divide your system into smaller parts that can be created by small independent teams.

Architecture is the key to scaling Agile.

Original post: Architecture – the key to scaling Agile.

Scrum – It all starts with the Product Owner

In my experience the Product Owner is the most underestimated rol in Scrum. I think it’s also the root cause of many problematic Scrum implementations.

Every Scrum implementation should start with the Product Owner. You should be very clear about the responsibility of the Product Owner:

  • The product owner is responsible for the success of the product.
  • The product owner is responsible for the long term vision of a product.
  • The product owner is responsible for the release planning.
  • The product owner is responsible for enabling a scrum team to implement the product.

This means that a product owner is much more than a user story writer. Most Product Owners i’ve met so far are requirements analysts with a new title. They are not empowered to sort the backlog, they are not empowered to learn from feedback and improve user stories.

If you are about to start with Scrum, start with the product owner. This will be hard enough, as many companies do not have a rol or person responsible for the succes of their products.

Original post: Scrum – It all starts with the Product Owner.

What is Agile?

In my previous post, Better products faster, a reaction to this discussion on linkedin, my main point was: how do you define success for Agile?

But before you can define success, you need to specify what Agile is. Even this seems unclear. One reply on the discussion calls it a marketing/branding term in the IT sector. Also common sense, pragmatism, and an adaptive approach to project management. For others doing agile means following the principles of the Agile manifesto.

I see Agile mostly as a reaction to the failures of waterfall: trying to predict long running, complex projects. Following a predefined plan, not being able to alter requirements or plans when new information or situations arise.

Waterfall is behaving like you have a crystal ball, Agile is the trail and error way of reaching your goals.

Calling it trail and error is probably not the best way to sell it. PDCA (plan, do, check, act) or empiricism are better names from a marketing point of view.

It all comes down to not pretending that you know the future. Instead you take small steps, determine the results of these steps, and you adjust your plan according to the feedback you collected.

Donald Reinertsen makes an interesting statement about trail and error in his book Managing the design factory: The try-it-fix-it approach is faster and higher quality (page 76).

This is agility: being able to adjust your plans based on new information.

Not just from the perspective of the developers, but even more so for Product Managers.

Original post: What is Agile?

Better Products Faster

There’s an interesting discussion on linkedin groups about successful use of Agile in large companies.

Many companies are mentioned. It could be that these companies have development teams that are using agile/scrum to deliver software in short iterations. It could be that Agile is an improvement for these developers. Maybe the developers are now more involved is estimating, design, unit testing, continuous integration and continuous deployment.

But is this what successful implementation of Agile looks like? How do you define success? Has Agile succeeded in a Big Company if the software developers have improved the way they work?

Sure, it’s a big improvement. But to see the real benefit of Agile for companies you have to see it from the perspective of a product manager.

Agile and Scrum are tools which enable product managers to be successful in managing the development of products. Using an agile approach the PM can focus on iteratively en empirically working towards products that fulfil the needs of customers.

Iterations enable feedback, feedback creates information, information enables better decisions and better products. Cross functional teams remove work handovers and queues. Less queues means increased speed.

Agile enables Product Managers to create better products faster.

To determine if Agile has succeeded in a company you need to determine if it has enabled a company to create better products faster. I think it’s save to say that both Yahoo and Nokia (both were mentioned in the linkedin discussion) haven’t shown any proof that they are creating better products faster. They are extremely slow in reacting to changing markets and competition.

Even if their teams are using Agile, both companies have failed to benefit from agile.

Original post: Better Products Faster.

Professional Scrum Product Owner training

On monday and tuesday i attended the Professional Scrum Product Owner training by Ken Schwaber. He has rewritten the training to be more focussed on the role, goals and needs of product owners and product managers, and less on supporting the Scrum team. The previous training was more focussed on what a product owner should do to make a scrum team succesful, but it should be the other way around. The scrum team is there to help the product owner achieve his goals.

I think it was a good decision to change the focus of the training. The training itself does a good job of explaining what a product owner should do, and how he can achieve his goals. Ken discussed things like agility and empiricism, value, prioritizing requirments, release planning, scrum.

Having used Scrum for the last 4 years, there weren’t any big surprises in the training, but that’s maybe also because Scrum itself isn’t difficult to understand. Applying it in a succesful way is a lot harder.

The biggest eye opener for me was the fact that the product owner’s main task is creating and communicating a vision for the product. This can be done on a very high level. A product owner doesn’t have to write the user stories himself, nor does he have to have a ‘Business team’ to assist him in writing the user stories. If more detailed requirements are needed than what the product owner provides, you can add people to the Scrum team that can research and communicate the requirements. The team can write their own user stories. The best way to scale a product owner is by letting the Scrum team do more work.

There also isn’t a big difference between a product owner and a product manager. In fact, the best summary for a product owner is an empirical product manager.

The key here is empirical. I find this to be the most difficult part of Scrum to convince people of. “Is it really that hard to plan what you are going to do? You’re a professional, you should be able to plan your work and come up with a working design or architecture before you start implementing the solution. You’ve integrated many systems, why is it so hard for you to tell me when you’ll have this next one done?” Just the other day a coworker told me that business strategy is something that is hard to forecast and predict. Software architecture on the other hand is mostly predictable, so there’s no need for an empirical approach.

A while ago I received a link to a video showing how IDEO redesigned a shoppingcart. This video was supposed to be a good example of how a scrum team should collaborate with a product owner. I was a bit puzzled by the fact that the team didn’t really get good requirements. Just a vision that better shoppingcarts were needed. The team did their own research on what was wrong with these carts and how they could improve them. Then they built a prototype to test their ideas. Here’s the video, it’s an interesting watch:

Original post: Professional Scrum Product Owner training.

Contact

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