Tag Archives: Agile

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.

Presenting on pragmatic microservices GOTO Night Thursday, May 12, 2016

goto nights pragmatic microservicesOn Thursday, May 12, 2016 I will be presenting on pragmatic microservices at the GOTO Night organised at bol.com. The presentation will be the support act for Randy Shoup. Check some of his previous presentations on SlideShare.

Pragmatic microservices

We have been around in e-commerce for years. However compared to other companies we’re young. Some would say we are in the scale up phase. In a number of ways we are experiencing a rapid growth. What does our IT need to stay innovative and scale to enable all this? What are the tradeoffs that are made for innovation in IT?

This year we won the Best Web Shop award because of our “efforts to get the difficult to achieve basics right that make the difference for customers”. IT has a large role in achieving this, at the scale of a web shop like bol.com. Did (micro)service make the difference to achieve this?

At bol.com we have a pragmatic, business value driven approach to (micro)services. In this presentation we share insights and the tradeoffs we made so IT enables to scale and innovate.

Presentation Pragmatic (Micro)Services

Here is the presentation I used:

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.

Presentatie op LAC congres – De architect tussen 35 scrum teams in de 90e sprint…

Op woensdag 25 en donderdag 26 november is de 17e 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: De architect tussen 35 scrum teams in de 90e sprint…

De realisatie van software gebeurt steeds vaker agile. Dit vraagt ook iets van de architect en de architectuur. Software wordt steeds sneller en frequenter naar productie gebracht. Wat betekent dit voor de architect? De hoeveelheid data die verwerkt moet worden door de IT systemen blijft groeien. En nu? Bij bol.com zijn we op weg naar de 100e sprint met inmiddels zo’n 35 scrum teams. Aan de hand van voorbeelden laten we zien hoe we hier bij bol.com mee omgaan en hoe de architect en de architectuur steeds meer volwassen worden.

Bij bol.com hebben we inmiddels heel wat ervaring opgedaan met scrum, Agile architectuur en het schalen van scrum en Agile. In de presentatie zal ik ervaringen delen uit de realisatie van een nieuwe voorraadservice, Logistiek via bol.com, Vandaag Ophalen en de lopende realisatie van ons nieuwe fulfillment center.

Business Intelligence en Big Data bij bol.com

Naast mijn presentatie over Agile architectuur, verzorgt mijn collega Wieneke Keller een presentatie over Business Intelligence en Big Data bij bol.com in de track data science voor architecten:

bol.com groeit stevig door. In onze (micro) service architectuur proberen we deze groei te faciliteren. Belangrijk is dat we inzicht houden in de kwaliteit van onze processen. Bij bol.com doen we dit door big data technologieën in te zetten binnen het BI domein. Zo kunnen we de groeiende hoeveelheden data en databronnen eenvoudig toegankelijk en beheersbaar houden. In deze presentatie wordt toegelicht hoe we dit doen. Ook zullen andere toepassingen van big data bij bol.com worden besproken.

VUCA – Volatility, uncertainty, complexity and ambiguity

Recognising that change is the only constant, shows us the path to VUCA. VUCA is the acronym for volatility, uncertainty, complexity and ambiguity. VUCA stems from military vocabulary and has been emerging in ideas on strategic leadership. The 4 elements of VUCA offer a context in which organisations view their current and future state. On a strategic level who isn’t interested in preparing for a volatile, uncertain, complex and ambiguous future?

There is an easy overview of VUCA on HBR.

Volatility

Volatility basically means that things tend to vary often and widely. The word comes from the Latin word volare, which means “to fly”. In a world were things seem to change faster and faster, stability can’t be attained. During the financial crises and economic turmoil of the last years people kept asking: “When will things be stable again?”. Could be that unstable and turbulence are here to stay.

Uncertainty

In past decades we build our lives on certainties and security. There were things that we could always count on. Nowadays, the uncertainties and the level of uncertainty keeps growing. Think of the economy, technology, whether companies will survive, how markets will evolve. In all these fields things are happening that very few of us have imagined only a decade ago.

What happens in our world and business gets harder and harder to predict. Known cause and effect relations need reevaluation and seem to have turned more complex and with a larger number of factors. We have to dig deeper to solve these unknown cause and effect relations.

Complexity

To properly understand the world we live in and perform our business we have to move beyond lineair models. Although models are getting better, they are based on an overwhelming number of interconnected parts and variables. This to such an extend that even though computers running these model have become better and faster, results and predictions haven’t. Think of the search for better medicines: the money invested is growing incredibly faster than the results we’re getting. Check eroom’s law (Moore’s law reversed) “the cost of developing a new drug doubles every nine years”.

Ambiguity

Ambiguity basically means that you can interpret a thing or situation in more than one way. The explanation and/or interpretation depends on context. This demands us to look at the whole picture to understand what lays in front of us. There is an unclear cause and effect. We can’t come up with a straight answer. There is a strong need for interpretation in context.

Theory of constraints

The Goal - Theory of ConstraintsThink it was back in 1993 I first read The Goal by Eliyahu Moshe Goldratt. The book was one of the first and most notable in the genre of business novels. The book – The Goal – introduces the theory of constraints (TOC) process for improving organisations. The book is set in a manufacturing company. However the book provides the context for a more generic approach to continuous improvement.

Theory of constraints

The theory of constraints is a paradigm that states that the output of a process is limited by a very small number of constraints. In a process there is always at least one constraint. TOC offers a process to determine the bottleneck/constraint and than restructure either the constraint or the work around it so the constraint can deliver it’s maximum output. Since the bottleneck’s output determines the output of the business process, other optimisation are local suboptimal interventions that do not generate any real business value.

The theory of constraints boils down to:

A chain is as strong as its weakest link.

More verbose: An organisation (especially a process or a business) is only as strong or powerful as its weakest activity or person. A group of associates is only as strong as its laziest member.

Constraint

A constraint is anything that prevents the system from achieving its goal. In TOC, the constraint is used as a focusing mechanism for management of the system. The concept of the constraint is analogue to the one in mathematical optimisation. In optimisation, the constraint is written into the mathematical expressions to limit the scope of the solution (X can be no greater than 5).

Types of (internal) constraints:

  • Equipment: The way equipment is currently used, is the limit to the ability of the system to produce more saleable goods/services.
  • People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.
  • Policy: A written or unwritten policy prevents the system from creating more output.

Throughput

In general the throughput is seen as the movement of inputs and outputs through a production process. Bottomline it can described as the rate at which a system generates its products or services per unit of time.

In the theory of constraints throughput is the rate at which a system achieves its goal. Mostly this is a monetary revenue and not the items or volume created to be sold or kept as inventory.

Continuous improvement

Goldratt - on-going improvementAs said before the theory of constraints offers an approach for continuous improvement. Optimising the utilisation of the constraint is an important part of the process. Of course this could lead to the discovery that another resource became the constraint. So we continu the optimisation.

As Goldratt states in The Race:

In the midst of a competitive race we should not look for an improvement, we should look to implement a process of on-going improvement.

Beyond manufacturing

IT Operations

The Phoenix Project borrows both content and genre from The Goal. It is a business novel that explains how the theory of constraints can be applied to IT operations. The Phoenix Project describes the problems that almost every IT organisation faces, and then shows the practices (based on the Theory of Constraint, Lean and more) of how to solve these problems.