Audiobooks (my list)

book reviews

The List of Audiobooks (most via Audible) in my library (and I have listened to) (when I find the time, I’ll update this list).

Background: I’ve discovered I enjoy much more listening to audiobooks, instead of reading (not that I enjoy reading, but with a family of 3 kids I cannot free up sufficient time for reading). Listening to spoken text works for me very well, I can digest the content and re-listen to parts of books as I like. Audible offers different subscription rates.

The List

Co-Active Coaching, 3rd Edition
Changing Business, Transforming Lives
By: Henry Kimsey-House, Karen Kimsey-House, Phillip Sandahi, Laura Whitworth

The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever
Autor: Michael Bungay Stanier

The 7 Habits of Highly Effective People
Powerful Lessons in Personal Change
By: Stephen R. Covey

How to Talk to Anyone: 92 Little Tricks for Big Success in Relationships
Autor: Leil Lowndes

The Age of Agile
How Smart Companies Are Transforming the Way Work Gets Done
By: Stephen Denning

The Toyota Way to Lean Leadership: Achieving and Sustaining Excellence Through Leadership Development
Autor: Jeffrey Liker, Gary L. Convis

By: Jeff Sutherland, JJ Sutherland
Narrated by: JJ Sutherland

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
Autor: Gene Kim, Patrick Debois, John Willis, Jez Humble

Daniel H. Pink’s ‘Drive: The Surprising Truth About What Motivates Us’ (Summary)

Theory of Everything
An Integral Vision for Business, Politics, Science and Spirituality
By: Ken Wilber

Spiral Dynamics Integral
By: Don Beck

The Art of Possibility
Transforming Professional and Personal Life
By: Rosamund Stone Zander, Benjamin Zander

Theory U
Leading from the Future as It Emerges
By: C. Otto Scharmer

Powerful: Building a Culture of Freedom and Responsibility
By: Patty McCord
About Netflix culture:

Thinking, Fast and Slow
Autor: Daniel Kahneman

Reinventing Organisations
By: Frederic Laloux (audiobook available via reinventing organisations’ website, not available on Audible)

(Source Featured image)

Modern Agile


Why Modern Agile?

Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile. These modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.

World famous organizations like Google, Amazon, AirBnB, Etsy and others are living proof of the power of these four principles. However, you don’t need to be a name brand company to leverage modern agile wisdom.

What is Modern Agile?

“Modern Agile is a community for people interested in uncovering better ways of getting awesome results. It leverages wisdom from many industries, is principle driven and framework free.”

— Joshua Kerievsky, CEO, Industrial Logic.

Modern agile is the result of courage, feedback, simplicity, communication, and respect for people.

4 guiding principles

Modern Agile has 4 guiding principles:

Make Users Awesome

Make Safety a Prerequisite

Experiment & Learn Rapidly

Deliver Value Continuously


These principles unfold (expand) in many practices! These are not only applicable to software development.

Who is Joshua Kerievsky?

Joshua is the founder and CEO of Industrial Logic, a pioneering Extreme Programming/Lean consultancy that radically improves the software development capabilities of organizations around the globe.

In the mid-1990s, Joshua was among a small community of “lightweight methods” practitioners experimenting with better ways of developing software. Since then, he’s helped thousands of people across hundreds of organizations learn better ways of making software, carefully reviewing and revising methods with the greatest impact and return on investment. Today, he leads an effort to modernize Agile by removing outdated practices and leveraging the best of what the software community and other industries have learned about achieving awesome results. Modern agile practitioners work to Make People Awesome, Make Safety A Prerequisite, Experiment & Learn Rapidly and Deliver Value Continuously.

Joshua is an international speaker and author of the best-selling, Jolt Cola-award-winning book, Refactoring to Patterns, numerous Agile eLearning courses, and popular articles like Anzeneering, Sufficient Design and Stop Using Story Points.

He’s active on Twitter, Snapchat and the emerging community.

Learn more about ‘Modern Agile’

–> videos by Joshua Kerievsky on YouTube

–> keynote talks by Joshua Kerievsky

–> Podcast with Joshua Kerievsky:

Sociocratie en Sociocratie 3.0 – een introductie (deel 2)

Sociocracy 3.0

Wat is Sociocratie 3.0?

Sociocratie 3.0 (afgekort “S3”) is een gids voor effectieve samenwerking op maat van kleine en grote organisaties. Sociocratie 3.0 is ontwikkeld door James Priest en Bernard Bockelbrink.

Sociocratie 3.0 combineert patronen voor samenwerking uit de klassieke sociocratie, samen met het gedachtengoed uit de agile manier van werken en het lean denken. Sociocratie 3.0 bevat manieren voor consent besluitvorming en andere patronen voor effectieve samenwerking. De principes van sociocratie 3.0 zijn samengesteld uit deze van klassieke sociocratie en het agile/lean denken en doen.

Lees meer in deel 1 over sociocratie en de oorsprong.

Wat, weeral een framework?

Sociocratie 3.0 wordt niet meer benoemd als een framework, maar als een “praktische gids” hoe je samenwerking kan verbeteren in een organisatie. Er is dan ook geen verplichting om alle elementen toe te passen – men start met een patroon uit sociocratie waar men een opportuniteit ziet voor verbeteringen. Op een continue manier experimenteren, zien wat er werkt en niet werkt, op basis van feedback blijven aanpassen, is inherent aan een lean aanpak en ook S3.

Sociocratie 3.0 bestaat uit een verzameling van patronen en dit ingedeeld voor verscheidene doeleinden, momenteel de volgende (vertaald uit het Engels):

  • Co-creatie en evolutie
  • Instaat stellen van co-creatie
  • Organisatiestructuur
  • Peer (directe collega’s) ontwikkeling
  • Meeting praktijken
  • Gerichte interacties
  • Bouwen van organisaties
  • Organiseren van werk
  • Maken van overeenkomsten
  • Starten met Sociocratie 3.0

Wat is het verschil met Scrum, en andere frameworks?

Scrum is een framework, en bevat minimale spelregels voor een effectieve samenwerking om een complex product of service te ontwikkelen. Complex in die zin dat het niet nuttig is om op voorhand te analyseren en te plannen wat we gaan bouwen, en omdat er veel variabelen zijn. Scrum kent zijn oorsprong in software ontwikkeling, maar hedendaags is het toepassingsgebied heel uitgebreid (in de laatste update van de officiële Scrum guide, is er een paragraaf toegevoegd met voorbeelden van de verschillende toepassingsgebieden van Scrum). Scrum bevat een combinatie van verschillende elementen (3 rollen, 5 events, 3 artefacten) die een productieve samenwerking mogelijk maken. Scrum is een framework dat toegepast wordt op niveau van een team.

De onderliggende principes van Scrum hebben als objectief om empirische procescontrole mogelijk te maken. Empirisme betekent dat kennis voortkomt van feiten, en dat beslissingen genomen worden op basis van resultaten en bevindingen over wat we weten (en niet op basis van voorspellingen, veronderstellingen, wensen, etc). De principes van Sociocratie 3.0 zijn in overeenkomst met deze van Scrum.

Onderliggende principes

Sociocratie 3.0 kent volgende onderliggende principes:
Consent: het beginsel van sociocratische besluitvorming, waarbij besluiten genomen worden op basis van het feit dat er geen wegend beargumenteerd bezwaar is om het besluit niet te nemen.
Gelijkwaardigheid: een voorwaarde voor consent. Het betekent dat degene die gevolgen ondervinden van een beslissing, ook betrokken zijn bij het nemen van die beslissing.
Transparantie: alle informatie is vrij beschikbaar voor iedereen, tenzij er specifieke redenen zijn voor confidentialiteit. Informatie beschikbaar maken voor medewerkers van een organisatie mbt alle activiteiten van een organisatie (zonder te verzanden in details) is tevens een uitdaging. Het visualiseren van informatie is een mogelijkheid om meer transparantie te bekomen.
Continue verbetering: betekent op iteratieve en incrementele wijze omgaan met verandering, en verbetering bekomen op basis van empirische resultaten.
Empirisme: het toepassen van de ‘wetenschappelijke methode’, tevens voor verandering. De wetenschappelijke methode toepassen betekent het systematisch onderzoeken van veronderstellingen, op een objectieve manier, en op basis van die resultaten beslissen wat een volgende stap is.
Effectiviteit: je tijd besteden aan datgene dat je effectief dichterbij je doel brengt.
Verantwoording (accountability): persoonlijk verantwoordelijkheid nemen voor het verloop van de organisatie, het opvolgen van besluiten en wat je gezegd had ook effectief doen. Tevens het (re)ageren wanneer je detecteert dat er iets nodig is in de organisatie.

Het toepassen van de patronen in Sociocratie 3.0 versterken de onderliggende principes en omgekeerd.

Sociocratie, holacratie, …?

Sociocratie 3.0, Holacratie, … zijn manieren om zelf-organisatie te spreiden over een ganse organisatie en niet enkel op het niveau van een team. Een besturingsmethodiek voor organisaties. Deze methodiek brengt ook structuur in organisaties, maar niet op de klassieke hiërarchische ‘command & control’ manier die vele organisaties kenmerken.

Een essentieel verschil tussen holacratie en sociocratie 3.0 is dat holacratie een “volledig” besturingsmodel betreft, waarbij een organisatie holacratie in zijn geheel implementeert. Bij sociocratie 3.0 is het de bedoeling om verandering te brengen door bepaalde processen uit te proberen en toe te passen – zonder de verplichting of om per definitie de volledige werking van de organisatie te veranderen van de ene op de andere dag.

Tevens, kenmerkend voor Holacratie is het gebruik van een ‘constitutie’ (wetgeving). Deze staat centraal in holacratie. Bij holacratie tekent het management deze constitutie waarbij zij afstand doet van haar bevoegdheden. De bevoegdheden worden vervolgens verlegd naar het systeem. Bij Sociocratie 3.0 bestaat dergelijke ‘constitutie’ niet.

De besluitvorming met consent bij holacratie is ook iets anders dan bij sociocratie. Bij holacratie: wat een geldig bezwaar is, dat is vastgelegd in de regels (in de Holacratie constitutie: “Criteria for Valid Objections”). Bij sociocratie zijn hier geen regels voor: elk bezwaar (rationeel, emotioneel, …) is geldig. Het maken van een bezwaar betekent trouwens dat dit eerst gedeeld wordt met de groep, en samen met degene die het bezwaar maakt, bekijkt de groep of het effectief een geldend bezwaar betreft.

Wat kan je bereiken met sociocratie?

Sociocratie: We hebben gemerkt dat er meer gedragenheid is bij het uitvoeren van besluiten. Besluitvorming gaat niet noodzakelijk sneller, maar is zeker met meer effectiviteit.

Structuur is nodig in een organisatie. De structuur die we brengen is eerder holistisch en gedreven door doelstellingen ipv een hiërarchie gebaseerd op macht. De organisatie wordt zelfsturend. Sociocratie gaat alleen over de besturing van de organisatie, niet over de inhoud.

Het doel van de flexibiliteit is dat een organisatie sneller en zinvoller kan omgaan met veranderingen en nieuwigheden. Werknemers zijn geëngageerd, gemotiveerd en kunnen maximaal gebruik maken van hun verschillende talenten en expertises, zonder in een functie of ‘keurslijf’ vast te roesten.

Het achterliggende lean gedachtegoed betekent dat we niet streven naar de perfecte oplossing, maar naar een continue verbetering (in Sociocratie 3.0 verwoord als “Goed genoeg voor nu, veilig genoeg om te proberen.”) is overal aanwezig.

Waar vind ik meer info over sociocratie?

Het Sociocratisch Centrum in Nederland (internationaal “The Sociocracy Group”) is het officiële centrum waar de klassieke sociocratie. Alle info over Sociocracy 3.0 kan je vinden op de website Sociocracy 3.0 (S3). S3 is open, vrij beschikbaar, en in constante evolutie.

Sociocratie – een introductie (deel 1)


Wat is sociocratie?

Sociocratie is een bestuursvorm, dat betekent dat je er organisaties en zelfs gemeenschappen mee kan besturen. Als je ‘sociocratie’ hoort, denk je natuurlijk aan ‘democratie’. De etymologie van de woorden leert ons: ’sociocratie’ stamt van socius=medemens en kratein=regeren, en betekent zoveel als “de medemens regeert”. ‘Democratie’ betekent ‘het volk regeert’, in de praktijk door middel van een volksvertegenwoordiging.

Vanwaar komt sociocratie?

Sociocratie kent zijn oorsprong in Nederland! De bakermat van sociocratie bevindt zich in de lage landen. Gerard Endenburg ontwikkelde “De Sociocratische Kringorganisatiemethode” in zijn elektrotechnische bedrijf “Endenburg Elektrotechniek”. Verder terug in de geschiedenis was er Kees Boeke, een Nederlands opvoedkundige en pacifist. Endenburg leerde bij Boeke over hoe gelijkwaardigheid in de besluitvorming onder meer een hoge betrokkenheid en sterke mede-verantwoordelijkheid voortbracht.

(Referentieboek van Endenburg: “Sociocratie : het organiseren van de besluitvorming : een waarborg voor ieders gelijkwaardigheid”)

Wat kan sociocratie voor een organisatie betekenen?

Sociocratie is gebaseerd op een aantal principes, waaronder consent en gelijkwaardigheid. Deze tonen hun meerwaarde in besluitvorming waardoor er meer discussie en betrokkenheid is. De voordelen die men rapporteert is dat de kwaliteit van besluiten verhoogt, en de inspraak van medewerkers verbetert – waardoor er een grotere gedragenheid in besluiten is.

Sociocratie heeft een specifiek patroon voor de structuur van een organisatie, waarbij de groepen binnen de organisatie met elkaar verbonden zijn door een dubbele kring. Endenburg haalde zijn inspiratie uit cybernetica en men spreekt over “onderling dubbel gekoppelde kringen” in een organisatie, waarbinnen het consentbeginsel van toepassing is. Het beginsel van consent en de dubbele koppeling borgen dat deze op elkaar zijn afgestemd. De besluitvormingsstructuur omvat alle deelnemers in een organisatie. Op deze manier wordt gelijkwaardigheid van elk lid in de organisatie mogelijk.

Consent, wat is dat?

Consent betekent geen overwegend beargumenteerd bezwaar. Consent besluitvorming betekent dat het besluit aanvaard is bij het ontbreken van een beargumenteerd bezwaar.  Dit principe wordt “het consentbeginsel” genoemd. Wanneer iemand consent geeft dan is hij bereid en in staat om een besluit uit te voeren en daarvoor verantwoordelijkheid neemt.

Consent is anders dan consensus. Er is sprake van consensus wanneer iedereen in de groep overeenstemming heeft bereikt. Bij consensus wordt er net zo lang gesproken over de geschilpunten totdat er een formule is gevonden die voor elke deelnemer aanvaardbaar is. Welke besluiten met consent genomen worden kan men afspreken in een organisatie, alle andere wijzen van besluitvorming blijven mogelijk – je kan dit met consent afspreken.

Hoe start ik met sociocratie?

Sociocratische (consent) besluitvorming kan je starten in gelijk welke groep waar je wilt… zowel op het werk als thuis. Door de eenvoudige vraag te stellen : “Heb je enig bezwaar?” – doe je aan consent besluitvorming. Consent besluitvorming is ook eenvoudig te starten binnen je groep van directe collega’s, familie of vrienden, waarbij de drempel laag is om iets nieuw te proberen. Verder kan je consent besluitvorming toepassen in meetings, binnen hetzelfde niveau in de organisatie, en daarna een andere hiërarchie gaan betrekken. Meetings in sociocratie worden ook steeds in cirkels gedaan, zodat iedereen een kans heeft om te spreken – op deze manier maken we gelijkwaardigheid mogelijk.

De kracht van sociocratische besluitvorming betreft de wijze van ‘opschalen’ waarbij verschillende cirkels (of kringen) met elkaar verbonden worden door een dubbele link (koppeling). In een besluitvorming in hogere kringen is een afgevaardigde van een lagere kring aanwezig die deelneemt aan de besluitvorming op een gelijkwaardige manier. Omgekeerd is er ook een vertegenwoordiger aanwezig van een hogere kring in besluitvorming in lagere kringen.

Wie gebruikt sociocratie?

Aangezien (klassieke) sociocratie zijn oorsprong in Nederland kent, zien we dat sociocratie daar toegepast wordt in scholen, woongemeenschappen, bedrijven, en andere organisaties. In Nederland is de Sociocratische Kringorganisatiemethode een alternatief voor een Organisatie Raad  (wat we in België kennen als de ‘Raad van Bestuur’).

In deel 2 leren we meer over Sociocratie 3.0.

Bron afbeelding:

Sociocratic decision making

continuous improvement

Sociocratic decision making


Quite often the challenges with making decisions are the following:

  • It’s difficult to get all parties involved aligned towards a decision.
  • Once a decision has taken, some degree of uncertainty remains if people actually support the decision.

Welcome to sociocratic decision making

Sociocratic decisions differ from autocratic (no to low support, but fast decision making), democratic (with majority vote) (at least 51% vote support), and consensus (broad support, but time-consuming process).

Sociocratic decisions are made with consent. Consent means there is no reason not to object. In other words, there are no compelling reasons not to agree to proceed and to try out whatever is being proposed. Any concerns raised can be taken into account. Objections must be taken into account and are to be resolved.

Prerequisites for consent decision making

  • participants involved are consciously thinking about moving forward with a proposal for next best action (“it’s good enough for now, and safe enough to try”),
  •  all participants consider each other equivalent.

Pattern for sociocratic decision making

  1. Introduce the matter to decide upon (in sociocracy 3.0 this called a “driver”: what’s happening right now that motivates us to present this matter?)
  2. Round of consent agreeing to the matter
  3. Present the proposal for next best action
  4. Round of clarifying questions
  5. Round of brief response – in order to get a first short indication of level of agreement
  6. Indicate consent (agree with consent, object, agree with concerns)
  7. Resolve objections (one by one) by improving the proposal (on the spot, or prepare for next meeting)
  8. In case of no objections (left): consider decision agreed upon: celebrate!
  9. Consider any concerns (optionally)

Note: the phrase “it’s good enough for now, and safe enough to try” is taken from sociocracy 3.0.

The next action of a decision agreed is to honor to check upon the outcome of the decision, and if necessary act upon improving it, in a next iteration.

Sociocratie – een inleiding

Gerard Endenburg

Wat is sociocratie?

Sociocratie is een organisatie bestuursvorm die uitgaat van gelijkwaardigheid van individuen. De naam komt van de Latijnse en Griekse woorden socius=medemens en kratein=regeren, en betekent zoveel als de medemens regeert.

Sociocratie doet aan ‘democratie’ denken, wat we kennen van onze democratische samenleving, en democratisch verkozen politieke partijen. In een democratie met stemming via meerderheid worden beslissingen en keuzes gemaakt op basis van een meerderheidsstem.

Sociocratie is een dynamische organisatie- en besluitvormingsmethode die gelijkwaardigheid versterkt door verschillen (ongelijkheid) net ruimte te geven.

Wat is de historiek van sociocratie?

Sociocratie is niet nieuw. Reeds in de 19e en 20e eeuw werd sociocratie toegepast als bestuursvorm. Wat wel interessant is voor ons dat voornamelijk in Nederland, de grondleggers actief waren: Kees Boeke en daarna Gerard Endenburg. Endenburg paste sociocratie toe in zijn bedrijf “Endenburg Elektrotechniek”. Het fijne is als je meer wilt leren over het ontstaan en de ontwikkeling van sociocratie je het originele boek in het Nederlands kan zoeken. Gerard Endenburg is op leeftijd maar nog steeds actief in de Sociocratisch Centrum Nederland bij de verspreiding van de Sociocratische Kringorganisatie methode.


Endenburg, dr ing. G.: Sociocratie, het organiseren van de besluitvorming, Eburon, Delft, 2002 ( 250 pag.).

Vanwaar de interesse?

We weten allen dat beslissingen nemen in organisaties met uitgebreide structuren vaak gebukt gaat onder:

  • Een gebrek aan transparantie over het waarom en hoe van beslissingen
  • Een zekere traagheid in het nemen van beslissingen

In het huidige decennia zijn we heel erg op zoek naar alternatieve organisatie-structuren sturingsmethoden. Traditioneel gestructureerde organisaties zijn vandaag nog steeds het toneel van management methodes uit een vorige eeuw (vb. Taylorisme) en een aanpak om werknemers te controleren (Theory X) gebaseerd op het toepassen van een stick & carrot (extrinsiek beloonde motivatie).

Boeken zoals ‘Reinventing Organisations’ (Frederik Laloux, een Belg) hebben het nadenken over alternatieve organisatievormen en beleidsvoering opnieuw op de kaart gebracht. Naarmate je meer leest over dit, leer je dat de voorbeelden van dergelijke organisaties niet nieuw zijn, ook niet de onderliggende modellen van sociale, evolutionaire en organisationele psychologie – zoals Spiral Dynamics (Don Beck) en Integraal theorie (Theory of Everything) (Ken Wilber).

Hoe kan sociocratie ons helpen?

Wel, eerst en vooral kan je redeneren: laat ons organisaties simpeler maken qua structuur (lees: vlakker, minder management lagen), zodat beslissingen op een efficiëntere manier genomen kunnen worden. Op zich is dat een goed voorstel, maar dat garandeert uiteraard niet dat genomen beslissingen gedragen zullen zijn en/of dat beslissingsprocessen sneller zullen verlopen.

Met sociocratie kan men een besluitvorming structuur toevoegen aan een (bestaande) (hiërarchische) lijnstructuur van een organisatie. De beleidsbepalende structuur is gebaseerd op gelijkwaardigheid in de besluitvorming en een gezamenlijke verantwoordelijkheid van alle organisatiedeelnemers voor het bepalen en realiseren van de organisatiedoelstellingen.

Sinds 2015 is sociocratie tevens verbonden met agile / lean gedachtegoed en agile wijze van samenwerking, door het werk van James Priest en Bernhard Bockelbrink, gepubliceerd als “Sociocracy 3.0”. De Sociocratische Kringorganisatie methode is een ‘lege’ methode wat betreft technieken voor productontwikkeling en samenwerking. Organisaties en teams met een voorkeur voor agile en lean manier van werken vinden aansluitingen bij de principes en methodes van sociocratie.

The Role of the Scrum Master


I’ve stumble upon this list, and I like it – as it clarifies again a bit the role of the Scrum Master.


  • Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario — just practices that have worked before in other organizations.
  • Successful practices of other organizations cannot simply be copied to your own. Every practice requires a particular context to work.
  • You need to determine for yourself what works for your organization — which is a process, not a destination.
  • The role of a scrum master is primarily one of leadership and coaching. It is not a management role.
  • A scrum master should recognize that different stages of a scrum team’s development require different approaches: some, teaching; some, coaching; and some, mentoring.
  • A scrum master should be familiar with the Shu-Ha-Ri concept of learning new techniques.
  • A scrum master’s principal objective should be to remove themselves from daily operations by enabling the scrum team to be self-organizing and self-managing.
  • Being a scrum master does not entail, and should never entail, enforcing processes.
  • Scrum is not designed for bean counters, although some metrics are helpful in understanding the health of a scrum team. Generally, insisting that the team achieve specific KPI (for example, commitments vs. velocity) does not help.
  • Scrum doesn’t elaborate on the process that enables a product owner to add valuable, usable, and feasible user stories to the product backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX methodologies may help, but in any case, a good scrum master will want the scrum team to be a part of this process (whether participating in user interviews or running experiments).
  • A scrum team’s communication with stakeholders should not be run through a gatekeeper (e.g., solely through the product owner) because this hurts transparency and negatively affects the team’s performance. Sprint reviews, conversely, are a good way to stay in close contact with stakeholders and to present the value delivered by the team during each previous sprint.



The most important objective of a sprint in Scrum is to deliver a DONE product increment – a piece of working software delivering value for the end-user. That is the goal today, and always has been the goal.

In a context, in which multiple Scrum teams work on the same product, it’s the goal – and only goal –  to deliver each (and every) sprint an integrated product increment – so no UNDONE work left at the end of the sprint.

How do you define DONE?

Scrum does not define what “done” means for a product – that’s to be defined by the development team.

Yet the goal is to get better and raise the bar, in order to be able to deliver a piece of valuable working software at the end of each sprint.

With support of the Scrum Master, the development team improves their practices at a steady pace to be able to reach that goal.

The Scrum Guide says:

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.”

Unfortunately, we observe that many Scrum teams (or teams saying to practice Scrum) are not able to deliver a done product increment at the end of each sprint. In the world of software development, this means a piece of working software (end to end) ready to be used by a customer (end-user). Some teams simply do not care and finish the work till done at a next sprint.

The output at the of the sprint has been called a potentially shippable product increment. Some teams interpreted this as “the product increment is ready to be shipped, but actually there’s still some work to do to actually release it to the customer“. That’s obviously not the point.

That’s why the Scrum Guide says:

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.”

A lesson from Scrum history

Jeff Sutherland and Ken Schwaber, – the creators of Scrum have been updated the Scrum guide over time. It’s interesting to read how in previous versions of the Scrum guide there was more detail about what done actually means, and what to do with “undone” work. The reason in general that some artefact and details have been left out, is to make the description of Scrum as a framework more simple, clear to understand and lightweight.

From Scrum Guide, version 2009:

A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization.

You clearly get the picture, that “done” includes all the work necessary to be able to have a piece of releasable, valuable software at the end of the sprint.

It continues:

“Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.”

Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.

Take care, the current Scrum Guide does not specify a “release sprint” as a practice. This is similar to the “hardening” sprint defined in – for example – the Scaled Agile Framework. In Scrum, this is considered a bad practice. As stated the goal – and only goal is to create a done product increment at the end of each sprint. “Undone” work piles up and increases risks and delays.

The word “undone” is not mentioned anymore in the current version of the Scrum Guide.

A perfect definition of done

Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) do explicitly mention “undone” work – in larger organisations there are often whole teams (e.g. an “operations” team, a “services” team) or whole departments (“operations” departement) or people (“release manager”) existing which are to be considered part of “undone” work if this cannot be done as part of the sprint (and it often cannot be done within a sprint).

A perfect definition of “done” implies that each product increment is

  • valuable
  • immediately releasable to the end-user

And that should be the goal of perfection.

To be able to achieve this as a team, effort is necessary to invest in:

  • software craftsmanship
  • automated testing
  • continuous integration
  • deployment automation

without sound technical practices it’s fairly impossible to achieve this on any scale (small or large).

Do not make a mistake, this is quite a challenge for many teams who (try to) practice Scrum.

All variants on Scrum who do not achieve the actual state of “done” product increments, according to the rules stipulated in the Scrum guide, are not to be considered Scrum teams.

What does done means in software development?

I quote this from – Ken Schwaber – and any software development team should adhere to these (working in Scrum or not)

The end result should include software that has:

  • Presence of valuable functionality for customers to use;
  • Absence of low value functionality that must be maintained and sustained regardless;
  • Quality code base to predictably maintain and sustain;
  • Quality code base to enhance without undue effort or risk;
  • Ability to catch defects early and no later than at release;
  • Predictability of schedules; and,
  • A Lack of surprises.

Which raises the question, what is quality software?

It has these characteristics:

  • I can readily understand the software and where & how things happen;
  • When I change or add to part of the software, there are no unintended or poorly designed dependencies;
  • I can read the code without looking for tricks or poorly defined and labeled variables or data;
  • I don’t need the person(s) that wrote the code to explain it to me;
  • There are a full set of (automated) tests to check that the function works as expected;
  • When I change something and add to the tests, I can check that the entire change and product continues to work;
  • How things work and hang together is transparent;
  • Standard, well-known design principles have been adhered to.

Source: Quality, Done Increment

Keep on improving!

Scrum – It is what it is.


And I don’t intend to say that with a negative perspective.

Quite often people wonder why Scrum – a framework for complex product development – has the rules as described in the Scrum Guide. The authors of Scrum (Ken Schwaber and Jeff Sutherland) say that the framework contains the roles, events, artifacts, and the rules that bind them together necessary to operate. Adding, changing or removing something will not make it Scrum anymore and a Scrum team will not work optimally.

Quote by Ken Schwaber:

“Scrum is a general-purpose framework applicable in complex situations, where more is unknown about the parameters than is known. The rules of empiricism and self-organizing make it work within short iterations that control the risk and increase chances of finding answers and creating value. The few roles, artifacts and events are fixed so the Scrum team can focus on unraveling complexity.”

What’s your opinion?

Read the original blog posts here.

Agile Transformation is a strategy, not a goal.


I came across an interesting article on InfoQ, it’s titled “Transforming from Projects to Products“. If you want deeper understanding on topics, InfoQ offers descent and great articles. So I’d like you (someone in any position who plans or is part of an “agile transformation” to read this).

Excerpts of the article:

The general understanding and perception of “Agile” or “agile”

” ‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.”

In fact, each company or organisations should be concerned to become more agile (as defined in the dictionary), this is a matter of sound principles and ‘common sense‘ (for example: eliminate waste and become more effective in what you do – certainly in software development / product delivery there are many ways to achieve this).

If an agile transformation is not an end-goal, what is the goal?

Organisations shouldn’t embark on a mission to become agile, without understanding what it takes in terms of cultural and organisational changes – and most importantly: figure out what they want to achieve – why do you need a change?

Questions to be asked:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process?

As you notice these questions which concern the whole organisation. Any initiative for improvement should be looked at globally – at an organisational (systems) level – in order to avoid local optimisations.

  • What are the major areas of improvement?
  • Transform from projects to products, including:
    • Stop managing, and start leading
    • Shift from “output” (deliverables), to focus on “outcomes”
  • Embrace the idea there is (and will be) uncertainty, instead of fighting it.

“Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.”

  • Reward people based on contribution to a common goal, instead of individual performance

Changing from:
“What will I do today?” to “What can I do to help the team towards our goal today?”
can make a huge difference to behaviour.

Common understanding why we want to change as an organisation

“Your business should be saying:

  • Where do we need to improve?
  • and how will we measure success?

Agile transformation may be a means of reaching that goal.

“If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow.  By empowering teams to make decisions for themselves you can create an environment of continuous improvement.”

Read the full article at InfoQ.

and recall:

Image source:

Agile/lean podcasts!

agile / lean

Listening to podcasts

Podcasts are a great way to learn and to listen in to conversations with people you’ve might have heard of, but you don’t really know who they are. Podcasts are a tremendous source to learn about new topics – virtually anything!

I’ve been listening to podcasts for a while, mainly topics relevant to my professional occupation – but there are many many podcasts out there! I listen to podcast when commuting to work, on public transport or you can connect your mobile phone using bluetooth to your car audio system. At home in the evening, I can enjoy listening to a podcast (or an audiobook) – it’s a different experience than reading a book or blog – and I find it more relaxing.

Recommended podcasts on the topic of agile & lean thinking

Scrum Master Toolbox Podcast

Host: Vasco Duarte

Format: short episodes (10-15 minutes), from time to time a special longer episode

Content: Interviewing Scrum Masters world-wide

Why I like it: Vasco is a a great interviewer, the podcast has a clear structure, and Vasco is knowledge able on the topic – in other words, he can place questions and answers, he can put items discussed in a larger context. You hear real-world experiences of Scrum Masters. One remark: I do sometimes skip certain episodes if the interviewee doesn’t speak English good enough 🙂

The podcast has a fixed format: each week a Scrum Master is interviewed. Each day of the week, the Scrum Master interviewed is asked a question.

And some Belgian have been interviewed too! (Gunther Verheyen, Yves Hanoulle)

List of the episodes

Agile for Humans

Host: Ryan Ripley

Format: mostly panel discussions, sometimes interviews with a specific interview during a conference. Episode length around 1 hour average.

Why I like it: these podcasts are recordings of informal chats and panel discussions, with people like Tim Ottinger, Zach Bonaker, Amitai Schleier. By listening you can follow their thoughts process, hear pro’s and con’s and challenge their thinking with your own thinking.

List of the episodes

Agile Uprising

Host(s)Ryan Lockard, Andy Cleff and others.

Format: panel discussions, interviews

Why I like it:

  • The Agile Uprising are interviewing some of the prominent principal agile & lean thinkers. This is a great chance to hear some of the thought leaders, talking about the past, present and future of agile and lean. Interviews with: Mary and Tom Poppendeick, Martin Fowler, Jurgen Appelo, Jeff Gothelf, David Anderson, Joshua Kerievsky, Jason Little, Ken Schwaber, Ron Jeffries, Jeff Sutherland, Andy Hunt, Mike Beedle, Bob Martin (Uncle Bob), Alistair Cockburn, and many others!
  • The Agile Uprising had a project in which they interviewed most of the agile manifesto signatories. You can hear them speak about how the agile manifesto for software development came about, how the term ‘agile‘ was chosen, and how actually that meeting at Snowbird, Utah, in 2001 went.

Listen to the Manifesto Author Review. (currently 14 out of 17 of the original signatories have been interviewed)

I can highly recommend the episodes of the manifesto author interviews – the set of questions are largely the same for all interviewees:

  • What were your activities and professional occupations with regard to the “lightweight” software development processes prior to 2001?
  • How did you get invited to the event at Snowbird?
  • How did the event went? The day prior, the 1st day and 2nd day – you can insight how the word “agile” came about
  • What are your thought on how the agile movement grew, since 2001?

Agile Uprising List of episodes

Joy at Work, how to lead

  1. When given the opportunity to use our ability to reason, make decisions, and take responsibility for our actions, we experience joy at work.
  2. The purpose of business is not to maximize profits for shareholders but to steward our resources to serve the world in an economically sustainable way.
  3. Attempt to create the most fun workplace in the history of the world.
  4. Eliminate management, organization charts, job descriptions, and hourly wages.
  5. Fairness means treating everybody differently.
  6. Principles and values must guide all decisions.
  7. Put other stakeholders (shareholders, customers, suppliers, etc) equal to or above yourself.
  8. Everyone must get advice before making a decision. If you don’t seek advice, “you’re fired.”
  9. A “good” decision should make all the stakeholders unhappy because no individual or group got all they wanted.
  10. Lead with passion, humility, and love.

Zelfsturing, heelheid en een evolutief doel



Overgenomen van: Hadrian’s Agile Wall

#Agile, #Holacracy, #Sociocracy, #Teal en #Cyan Organisaties

Wanneer we het Agile Manifesto lezen herkennen we, weliswaar op een andere schaal (product teams in plaats van organisaties), veel van de principes die in het boek “Reinventing Organisaties” ook voorkomen:

  • Zelfsturing: “Individuals and interactions over processes and tools” en we hoeven niet uit te leggen dat zelfsturende, liefst multi-functionele teams één van de fundamenten is van agile werken.
  • Heelheid past ook volledig in het statement “Individuals and interactions over processes and tools“. Het is juist de bedoeling van in een open sfeer en een omgeving van vertrouwen te werken tussen de business, de product owner en het team analisten, ontwikkelaars, designers, testers en support team. Agile stimuleert iedereen om bij de minste twijfel over iets of indien er verbetering mogelijk is, dit ook te melden. Deze vertrouwvolle omgeving brengt ons ook dichter bij ons innerlijke zelf, zonder dat we een rol moeten spelen. Zoals wanneer de junior ontwikkelaar geen opmerking durft geven aan de ervaren technische architect of de onervaren tester die een fout gevonden heeft in de analyse en dit niet durft te melden aan de senior analist. Agile werkt enkel in een sfeer van transparantie, openheid, respect en vertrouwen. Zonder dat kan je niet naar deze nieuwe vorm van samenwerking groeien. Niet alle voorwaarden moet van in het begin ingevuld zijn, maar de intentie om er te willen geraken is onontbeerlijk.
  • Evolutief doel komt perfect overeen met “Responding to change over following a plan“. Geen up-front analyses meer en dan in silo’s dit ontwikkelen, testen en uitrollen. Geen vastgespijkerd plan maar experimenteren, feedback verzamelen en waar nodig aanpassen.

Het is ook veel gemakkelijker om stap per stap dit nieuwe denken toe te passen binnen teams, maar indien het top management zich hierin niet kan vinden blijft het zeer moeilijk om dit ingang te laten vinden in je organisatie.

Scrum Day Europe 2017 (Amsterdam)

Scrum Day Europe 2017

Scrum Day Europe in Amsterdam wordt georganiseerd door en Prowareness. Gunther Verheyen en Ken Schwaber initieerden het event in 2012. Anno 2017 op Scrum Day Europe wordt vertegenwoordigd door Dave West (product owner bij De conferentie gaat door in het Pakhuis “De Zwijger” aan de kade. Het publiek bestaat vnl. Uit Nederlandse  community leden, ik zelf een van de weinige (of enige) Belgische aanwezigen. Er was vooral een leuke sfeer, gezellige bedoening. Ik ontmoette er heel wat vrienden (PSTs) uit Nederland, zowel Ron Eringa, Barry Overeem, Christiaan Verwijs, Dajo Breddels, maar ook Johannes Schartau en Sergey Kotlov.

De conferentie bestaat zowel uit talks (sprekers op het podium) als meer interactieve workshops. Ikzelf mocht een talk geven over “create products with impact” – dat was opnieuw een leerrijke ervaring. (Alhoewel eerlijk gezegd ik ook graag interactieve “training from the back of the room” workshops geef).

Een impressie van de sessies

Read More