Category Archives: Agile

Agile

Presenting at Codemotion next week on web scale patterns

Peter Paul van de Beek CodemotionNext week I’ll be presenting in Amsterdam at Codemotion on web scale patterns in bol.com back office services. Codemotion is the biggest tech conference in Italy and one of the most important in Europe, with a network of more than 30k developers.

The title of my presentation is: “Applying “web scale” patterns in the bol.com back office”. In the session, we show you how we use “web scale” patterns to achieve scalability and flexibility in our back office software. We will guide you through how we apply patterns like CQRS, event sourcing, polyglot persistence and micro services to solve puzzles in our back office services. Interesting is that in our experience we don’t need these just to solve a technical problem. It helps us to solve some of our business problems!

See you on May 16 and 17 in Amsterdam. There is a short interview with me on Codemotion world.

Presentatie Agile schalen op basis van best practices

Net als de afgelopen jaren heb ik afgelopen vrijdag een presentatie over Agile Architectuur gegeven. Kern van de presentatie dit jaar is dat bij het schalen van Agile vooral de problemen/uitdagingen die je onderweg tegenkomt aangepakt moeten worden en niet klakkeloos een framework gaat implementeren. Aan de hand van voorbeelden leg ik uit hoe we dit binnen bol.com aanpakken.


Book – Holacracy

HolacracyIk kwam een mooie samenvatting van het boek Holacracy van Brian J. Robertson tegen. Eerder schreef ik een review over Getting Teams Done. Waarin holacracy (en de variant Spark) beschreven wordt als een methode voor teamproductiviteit, net als GTD dat is voor individuele productiviteit. Mijn ervaringen met de holacracy variant Spark beschreef ik in deze post.

De case die vaak gegeven wordt als holacracy adoptie beschreven wordt is Zappos, maar er zijn veel meer cases beschreven.

Presentatie op LAC congres – Agile schalen op basis van best practices

lac-agile-schalen-op-basis-van-best-practicesOp donderdag 17 en vrijdag 18 november is de 18e editie Landelijk Architectuur Congres. Net als vorig jaar ga ik in de track Agile Architecting een presentatie geven over architectuur en architecten in een Agile omgeving. De titel van de presentatie dit jaar is: Agile schalen op basis van best practices.

Bij bol.com hebben we jarenlange ervaring met het werken met agile en scrum. Het aantal IT teams dat hiermee werkt is de laatste 2 jaar enorm sterk gegroeid. Daarnaast doen we diverse experimenten met holacracy. Voor het opschalen zijn we steeds op zoek gegaan naar best practices. Je zal dan ook veel elementen uit SAFe terug zien, maar nooit SAFe.

Agile schalen op basis van best practicesIn de meer dan 100 scrum sprints die we er bij bol.com inmiddels op hebben zitten hebben we een berg ervaring opgedaan met agile architectuur en het schalen van agile practices. Architectuur kan een belangrijke bijdrage leveren aan een snellere time-to-maket. In de presentatie zullen voorbeelden gebruikt worden uit bijvoorbeeld de realisatie van sneller en vaker leveren, de winkel langer open en Logistiek via bol.com.

Organizational Debt

Organizational DebtEveryone knows what debt is. If you are in or around the software development community you probably also know the term technical dept. For others:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Or as Ward Cunningham describes it:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation.”

But there is a third kind of debt: Organizational Debt. Here we pay interest on bad decisions of decisions that we put off. This, of course, has a strong impact on organisations.

Some definitions of Organizational Debt

In organizational debt is like technical debt but worse Steve Blank gives this definition:

Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.

However, I think that organisational debt isn’t a startup thing. It is worse in other organisations since there is a large accumulation of bad decisions and decisions not taken. Besides that larger and/or older organisations tend to have more rules to work around.

That is why I like the shorter description offered by Scoot Belsky in Avoiding Organizational Debt:

Organisational debt is the accumulation of changes that leaders should have made but didn’t.

Another interesting description is given by Aaron Dignan in How to eliminate organizational debt

The interest companies pay when their structure and policies stay fixed and/or accumulate as the world changes.

This one really goes from the VUCA point. The ever changing world in which organizations have to adapt or are to be extinct.

Scrum guide is updated

Scrum Guide Scrum Values Just last week the latest update of the Scrum Guide was released. In this latest version of the Scrum Guide the five values of scrum play a more important role than in previous versions. In my 4 year old Scrum Guide Mind Map these values aren’t around.

These values amplify the power of Scrum by providing a compass for decision making. They help teams adopt Scrum and deliver amazing software for their customers. They also prove fundamental to create a great place to work.

Scrum values

The Scrum values are:

  • Courage – Being transparent, but willing to change even if that means accepting that you are wrong, or that your opinion is not the direction that the team is going.
  • Focus – focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important.
  • Commitment – commitment is about dedication and applies to the actions, the effort, not the final result.
  • Openness – Highlighting when you have challenges and problems that are stopping you from success. The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations.
  • Respect – Helping people to learn the things that you are good at and not judging the things that others aren’t good at.

There is an interesting post on these values by Gunther Verheyen.

Boek – De Bijenherder

De BijenherderDe Bijenherder is een management novel. Het boek is dus geschreven in de stijl van The Goal, The Phoenix Project, De Kracht van Scrum en bijvoorbeeld Getting Teams Done. Waarbij de laatste twee ook het aandachtsgebied delen met De Bijenherder.

Leiding geven aan zelfsturende teams

De zoektocht in het boek is die naar hoe leiding te geven aan zelfsturende teams. Door de toenemende omslag naar zelfsturende teams wordt ook deze vraag steeds vaker gesteld. En terecht want daarnaast blijkt dat een van de fricties bij het werken met zelfsturende teams is dat deze op een traditionele manier gemanaged worden. En dat blijkt niet goed te werken.

Het blijkt in de praktijk helemaal niet eenvoudig om zelfsturende teams aan te sturen. Wat kan en mag er nog gestuurd worden? Het is heel anders dan de aansturing van een team door een traditionele manager. Deze omslag wordt bijvoorbeeld ook in reinventing organizations goed beschreven.

Waar de meeste aanhangers van zelfsturende teams een sterke voorkeur hebben om te doen en uit te proberen, gaat De Bijenherder nauwelijks verder dan het denkproces dat de hoofdpersoon doorloopt om te komen tot een aanpak. Deze is weliswaar gebaseerd op de praktijkervaring van zijn opa, maar dat blijft iets anders dan zelf ervaren. Iets wat de hoofdpersonen in The Goal, The Phoenix Project en Getting Teams Done wel ondergaan.

De presentatie van Mark van den Burg

De hoofdpersoon maakt van de lessen die hij leert en die zijn opa hem leert een presentatie. Deze presentatie ziet er ongeveer zo uit:

Het boek en de presentatie daarin gaan een slag dieper dan hierboven weergegeven. Dat biedt voldoende aanknopingspunten om een (flinke) stap te maken in het leiden van zelfsturende teams. Naast het boek en de aangereikte handvatten daarin, moet je als leidinggevende natuurlijk zelf aan de slag, zelf doen en ervaren. De ervaring en feedback kun je dan weer ijken aan de aandachtspunten die in het boek worden meegegeven.

En?

De Bijenherder is een aanrader. Het leest makkelijk en de basis van het aansturen van zelfsturende teams wordt zeker goed duidelijk. Er worden praktische tips aangereikt.
Daarna is het doen. Zorgen voor feedback en toetsen aan de handreikingen die de hoofdpersoon voor je heeft opgesteld.

Experiences with Holacracy

There is a growing number of books on holacracy. One of the first on this subject without even coining the term was Eckart’s Notes. Also the ones on Semco (like Semco style and Maverick!) are gaining popularity. These all describe case studies, where Reinventing Organisations shows development stages in organization. These in turn are based on literature and case studies like the one that is described in Eckart’s Notes.

Since we are experimenting with holacracy at Bol.com I recently read Getting Teams Done. It gives a great introductions and offers a practical approach.

Holacracy cases

Recently there were some case studies and testimonials of the use of holacracy published at Medium.
Path to holacracy

The Dutch design company Concept7 has experimented with a number of ‘management styles’ over the years. Their objective has always been clear: to foster freedom and empowerment in their employees. The entire staff has been working with holacracy for a few years now. Lauren shares her story.

The founder of Voys, Mark Vetter, has always believed in self-organisation. He claims holacracy has brought us accountability, entrepreneurship, and faster evolution. Check Mark’s story on getting things done in a company. The Voys way is published in a book on the way they are organised.

The founders of the Dutch ‘user experience’ company Valsplat believe it is utmost important to bring your whole self to work, or even express or develop your talents. Nils claims holacracy has provided me with tools that help me focus. He states:

Holacracy helps us to become the best possible version of ourselves

Holacracy – Spark; Wat ik leerde van Getting Teams Done

Holacracy - Getting Teams Done - SparkHolacracy (en de variant Spark) is een methode voor teamproductiviteit, net als GTD dat is voor individuele productiviteit. De onderliggende principes van Holacracy en GTD komen sterk overeen. Aan GTD ontleent Holcracy de discipline en helderheid van het denkwerk en de gewoontes en vaardigheden die daarbij horen. In Holacracy wordt het denkwerk gedaan en zichtbaar in de overleggen van het team.

Holacracy leent ook het een en ander van Agile. Een van de punten die Agile maakt, is dat je in complexe omgevingen niet al het denkwerk vooraf moet doen. Geen Big Design Upfront wordt dat genoemd. Je begint met kleine stappen en stuurt bij op basis van de ervaringen die je opdoet. Holcracy gebruikt dit vooral voor de kaders en afspraken waarmee en binnen het team functioneert. Het team begint met werkafspraken en stuurt bij waar daar behoefte aan is.

Het boek dat ik recent over Holacracy las is Getting Teams Done. Meerdere leerpunten uit dit boek zijn ook toepasbaar buiten Holacracy omgevingen. Die worden hieronder weergegeven.

Holacracy en spanningen

Binnen Holacracy zijn spanning de brandstof om het team dichter bij haar doel te krijgen. Een spanning is binnen Holacracy hetzelfde als wat Peter Senge in The Fifth Discipline “Creatieve Spanning” noemt: Het verschil tussen waar we nu zijn en waar we moeten zijn. Als een dergelijke spanning ontbreekt is een voorstel of een andere interventie niet noodzakelijk en brengt het team niet dichter bij het doel.

Van iedereen in het team wordt verwacht dat men:

  1. Spanningen registreert;
  2. Deze spanningen verheldert, kijkt wat je ermee moet en waar deze thuis hoort;
  3. Een compleet en actueel overzicht heeft van acties en projecten (die deze spanningen oplossen);
  4. Regelmatig dit overzicht bijwerkt;
  5. Prioriteert en kiest op basis van dit overzicht hoe tijd en energie wordt ingezet.

De helderheid die bijvoorbeeld ook GTD kent, komt door het expliciet maken van de stappen die vaak impliciet genomen worden. Nu het expliciet is, worden de keuzen bewuster gemaakt. Binnen GTD is dit het verzamelen.

Spanningen verhelderen

Om de spanning en het overzicht zoals hiervoor beschreven goed in kaart te brengen, maak je gebruik van de volgende vragen:

  1. Hoort het bij mijn rol? – Pak het op.
  2. Hoort het bij een andere rol? – Draag het over.
  3. Hoort het binnen dit team (deze cirkel)? – Laat rollen (verantwoordelijkheden) aanpassen zodat het overgedragen kan worden.
  4. Hoort het binnen onze organisatie? – Draag het over het het verantwoordelijke team.
  5. Vind ik het persoonlijk belangrijk? – Pak het op persoonlijke titel op, maar laat de organisatie er buiten.
  6. Laat het los.

Hiervoor worden 3 niveaus van werk onderscheiden:

  1. Rollen en verantwoordelijkheden.
  2. Projecten (Lijst van mogelijke toekomstige acties gedefinieerd als gewenste uitkomsten).
  3. Eerst volgende acties.

Compleet en actueel overzicht

Om een compleet en actueel overzicht te hebben is het handig om lijstje(s) bij te houden. Deze zijn vergelijkbaar met die van GTD en kent de volgende categorieën:

  • Wachten op lijst – waar je op iets of iemand wacht;
  • Later / misschien – waar je nu geen actie op neemt, maar misschien in de toekomst;
  • Agendapunten voor teamoverleg – spanningen over operationele zaken
  • Agendapunten voor roloverleg – spanningen over verwachtingen, rollen (verantwoordelijkheden) en procedures.

Boek – Getting Teams Done – Spark

Getting Teams Done - SparkHet boek Getting Teams Done is een leuk introductie in Holacracy. Dit boek introduceert de methode waarmee leidinggevenden, teamleiders managers en zelfsturende professionals de teamproductiviteit naar een hoger niveau kunnen tillen. Holacracy wordt bijvoorbeeld ook gebruikt als organisatievorm bij Zappos (lees ook Delivering Happiness).

Getting Teams Done is geschreven in de stijl van Het Doel / The Goal en The Phoenix Project. De romanvorm wordt daarbij in dit geval afgewisseld met een non-fictie deel waarin wordt uitgelegd hoe Holacracy werkt en waar het een oplossing biedt. Daarnaast wordt in dat deel steeds het proces en de ondersteunende technieken uitgelegd.

Het boek Getting Teams Done is een aanrader voor iedereen die geinteresseerd is in Holacracy en zeker voor diegene die werkt voor een organisatie waar Holacracy of een variant als Spark ingevoerd wordt. Het invoeren van Holacracy of Spark vraag een zeer sterke discipline. Daarbij is het handig om hulp van buiten te hebben die buiten de inhoudelijke en andere discussies staat. Op die manier kan er sneller mee aan de slag gegaan worden en kunnen de resultaten eerder worden bereikt.