Vergaderen

Vergaderen… het is standaard in een organisatie, en in de business wereld. Iedereen vergadert toch? En als je iemand iets wilt vragen, of je hebt iets nodig van een collega, dan plan je toch een vergadering?

meetingitis

An excessive propensity to hold unnecessary meetings.

Hoe vergroot je dan de effectiviteit en productiviteit van vergaderingen? Heb je telkens nood aan een vergadering? Hier bewuster over zijn, kan je al een grote stap vooruit helpen en de situatie verbeteren!

De effectiviteit en productiviteit van een vergadering verhoog je door

  • een goede voorbereiding
  • de vergadering faciliteren
  • een goede follow-up

Voorbereiding van de vergadering

4 P’s van een vergadering

Vooraleer een zaal te boeken en mensen uit te nodigen, denk na of de vergadering nodig is!

Een alternatief is op mensen toe stappen voor een conversatie wanneer die in de buurt zijn en die je kan/mag storen (eerst vragen natuurlijk)! Denk voor het plannen van een vergadering aan de 4 P’s (4 P’s als geheugensteuntje) – dit is voor een vergadering die je wilt organiseren.

  • Persons/Participants: wie zal er de vergadering organiseren/faciliteren/leiden en wie zijn de personen die actief kunnen bijdragen en die je vervolgens zal uitnodigen?
  • Purpose: wat is het doel van de vergadering? Zijn de beweegredenen of motivatie duidelijk die het bijeenbrengen van personen in een vergadering verantwoorden?
  • Process: welke facilitatie processen zal je toepassen voor de vergadering, in functie van het doel? Er bestaan verschillende facilitatie technieken, die je kan gebruiken in eender welke vergadering. Het is interessant om meer interactie en dynamiek te brengen in een vergadering, buiten de standaard presentaties (1 persoon bepaalt het verloop) of brainstorming (iedereen bepaalt het verloop).
  • Product: Wat is het “product”, de output van de vergadering? Wat willen we bereiken? Dit hangt uiteraard vast met het doel van de vergadering en bepaalt ook wat de output (“deliverable”) zal zijn.

Agenda van een vergadering

De agenda van een vergadering opmaken is deel van de voorbereiding. Maak een agenda die duidelijk en uitnodigend is!

Maak duidelijk:

  • Wie wat zal faciliteren
  • Wie notities zal nemen tijdens de vergadering (hoeft niet steeds de organisator te zijn!)
  • Wie een follow-up zal doen (kan per agendapunt)

Voor elk agendapunt kan je beschrijven:

  • De motivatie (noodzaak) om te bespreken
  • De verwachtte uitkomst
  • Wie verantwoordelijk is
  • Eventuele voorbereiding
  • Tijd verwacht te spenderen
  • Het proces

Bij “proces” is het nuttig om een onderscheid te maken tussen “bespreking” en “beslissing“. Wanneer het niet duidelijk is in een vergadering wat de verwachtte output is (en daarmee bijhorend proces om daar te raken), is dit vaak een oorzaak van frustratie:

  • Deelnemers die denken dat er een beslissing nodig is, raken geërgerd omdat de andere deelnemers enkel verwachten te “bespreken”.
  • Deelnemers die denken dat het enkel een bespreking betreft, raken geërgerd omdat de andere deelnemers op een beslissing aansturen.

Tip: indien je merkt dat de deelnemers niet op voorhand de agenda bekijken (m.a.w. blindelings de vergaderuitnodiging accepteren) kan je werken met een agenda die uitnodigt d.m.v. het stellen van vragen in de agenda. De vragen zijn een trigger om na denken over de verwachting van de vergadering en eventuele voorbereiding.

Een vergadering faciliteren

De facilitator is de “gardener” en “guard” van de vergadering; een facilitator hoef niet noodzakelijk inhoudelijk bezig te zijn. Een facilitator zorgt ervoor dat:

  • elke persoon gelijkwaardig kan deelnemen
  • zorgt voor ruimte en tijd voor elke agendapunt en houdt de timing per agendapunt in het oog
  • faciliteert het bijhorend proces per agendapunt (is het een bespreking/verduidelijking? hebben we een beslissing nodig? wat is het actiepunt? wie doet wat wanneer?)
  • faciliteert een evaluatie van de vergadering op het einde (en zorgt ervoor dat dit kan gebeuren, door hier tijd voor te voorzien, of paar minuten voor officiële einde van het vergadertijdsslot een evaluatie te faciliteren)

Facilitatie technieken

Ronde

In een vergadering, ga rond in een cirkel zodat elke deelnemer de kans krijgt op zijn/haar beurt te spreken.
Het faciliteren in een cirkel zorgt ervoor dat elke deelnemers als gelijkwaardig beschouwd wordt, en ondersteunt effectieve dialoog.

Als facilitator, kan je kiezen om elke ronde met een andere persoon te beginnen, om variatie te brengen in wie er als eerste en wie er als laatste spreekt.

Check-in

In een check-in rondje krijgt iedereen de kans om kort te benoemen wat er leeft, om zo vollediger aanwezig te kunnen zijn. Dit helpt ook om gedachten te ordenen en met meer focus aan een vergadering te beginnen!

Check-in betekent dat je (heel) kort met de groep deelt wat er momenteel gebeurt met jezelf, hoe je aanwezig bent, daarbij jouw gedachten, gevoelens, afleidingen en noden kenbaar maakt.

Als facilitator, verplicht nooit iemand! Een deelnemer kan een check-in overslaan. Dit kan bij start van de vergadering gebeuren, of bij een 1 on 1 voorafgaandelijk.

Evaluatie

Zorg voor een korte evaluatie op het einde van elke vergadering. Het doel is om feedback te verzamelen hoe de vergadering verlopen is en punten voor verbetering te delen.

Korte evaluatie

  • fist-of-five”, elke deelnemer geeft gelijktijdig aan wat je vond van de vergadering (van 1: heel slecht, tot 1: heel goed) meer/minder
  • starten/stoppen/houden
  • positief/kritisch/suggestie voor verbeteringen

Langere evaluatie (voor een workshop, sessie, …)

Retrospectief formats om te evalueren:

  • Effectiviteit en format
  • Facilitatie en voorbereiding
  • Emotionele toon
  • Appreciaties en prestaties (Ik vond goed…)
  • Wilde ideeën en radicale suggesties (Wat indien…)

Facilitatie technieken

Bron voor facilitatie technieken (kleine en grote groepen)

Facilitatie technieken maken vergaderingen interactief en dynamisch, voorbeelden van technieken:

Kanban

Voor recurrente vergadering is een backlog en een kanban aangewezen, enerzijds om de lijst van items continue te prioriteren (backlog) en

anderzijds om een visueel overzicht te behouden (kanban).

Governance backlog

Gebruik naast de product backlog (werk te doen voor ontwikkeling van het product) ook een aparte backlog voor beslissingen (“governance”). Governance is het voortdurend beslissen over wat er nodig is om doelen te bereiken en binnen welke grenzen dat werk hoort plaats te vinden. Te bespreken, te beslissen items kan je op een governance backlog plaatsen.

Op organisatie niveau is het ook handig om organisatie brede items zichtbaar te houden op een (goverance) backlog.

Sociocracy 3.0

Sociocratie en Sociocratie 3.0 – een introductie (deel 2)

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

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: http://www.deschool.nl/wp-content/uploads/2010/10/brochure-sociocratie.png

Gerard Endenburg

Sociocratie – een inleiding

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.

Boek:

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.

Done!

Note: this post is based on the 2017 version of the Scrum Guide and has not been updated since.

The most crucial sprint objective 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 is 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 determined by the development team.

Yet the goal is to improve and raise the bar to deliver valuable working software at the end of each sprint.

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

The Scrum Guide describes:

“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, many Scrum teams (or teams saying to practice Scrum) cannot deliver a done product increment at the end of each sprint. Some teams do not care and finish the work at the next sprint. In software development, this means a piece of working software (end-to-end) ready to be used by a customer (end-user).

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

That’s why the Scrum Guide describes:

“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, – Scrum creators- have updated the Scrum guide over time. It’s interesting to read how there were more details about what done means and what to do with “undone” work in previous versions of the Scrum guide. In general, some artifacts and pieces have been left out to make the description of Scrum as a framework simpler, more straightforward to understand, and lighter.

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 get the picture that “done” includes all the work necessary for 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. The only goal is to create a done product increment at the end of each sprint. In Scrum, this is considered a bad practice. “Undone” work piles up and increases risks and delays.

The word “undone” is no longer mentioned in the Scrum Guide’s current version.

A perfect definition of done

Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) explicitly mentions “undone” work – in larger organizations. There are often whole teams (e.g., an “operations” team, a “services” team) or whole departments (“operations” department) 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 definition of “done” implies that each product increment is

  • valuable
  • immediately releasable to the end-user

And that should be the goal of done.”

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

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

without sound technical practices, it’s pretty impossible to accomplish 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.

According to the rules stipulated in the Scrum guide, all variants on Scrum that do not achieve the actual state of “done” product increments are not considered Scrum teams.

What does “done” mean in software development?

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

The result should include software that has the following:

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

This 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 ill-defined and labeled variables or data;
  • I don’t need the person(s) who wrote the code to explain it to me;
  • Therecompletea 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 continue 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!

Agile Transformation is a strategy, not a goal.

I came across an article, “Transforming from Projects to Products.”

Excerpts of the article:

The general understanding and perception of “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 ar.e 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.”

Each company or organization should be concerned with becoming more agile (as defined in the dictionary). This is a matter of sound principles and ‘common sense’ (for example, eliminating waste and becoming more effective in what you do – indeed, in software development/product delivery, there are many ways to achieve this).

What is the goal if an agile transformation is not an end goal?

Organizations shouldn’t embark on a mission to become agile without understanding what it takes in terms of cultural and organizational changes – and, most importantly, figuring 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 organization. Any initiative for improvement should be looked at globally – at an organizational (systems) level – to avoid local optimizations.

  • What are the significant 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?”
It can make a huge difference in behavior.

A common understanding of why we want to change as an organization

“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: https://quickscrum.com/Images/article_detail/Whyagiletransformationisdifficult-1.png

Playing Lean facilitator tips

Note: This is an older post with game experience based on the first version of Playing Lean. Meanwhile, I have been working with Playing Lean 2.

Playing Lean is a business simulation in a board game format to learn about lean startup principles and practices.

The following facilitator tips are based on those experiences. Some of the tips are more advanced (meaning these take time to prepare). You might not agree with all recommendations, but hey, it’s up to you to try 😉 (as an experiment)

Continue reading →

Work Expo – Management 3.0

How do you visualize a purpose? How do we share a vision? How to tell your story? Often, organizations have a vision and a mission statement (for their organization, product, or team), but words don’t convey the message. What you should do is show, don’t tell!

Sharing a vision
Sharing a vision

Create an exposition of your work (in your team, your department, or even individually). When you can create an excellent exposition about your work, you have likely found and visualized your purpose (Management 3.0 Work Expo).

Continue reading →

Celebration grid – Management 3.0

“Insanity is doing something over and over again and expecting a different result.”

Insanity is doing something over and over again and expecting a different result. If you objectively evaluate what you’re doing repeatedly and are not satisfied with the output, why would you keep repeating it? Humans are creatures of habit and routine. If you’d like to change your routine, you should focus on small and incremental changes. How does this work in groups of people? At home…, at work? We want to improve our behavior and practices, but the daily routine often prevents us.

Continue reading →

Personal maps – Management 3.0

Are you all professional at work? No chit-chat, no small talk, not sharing personal stuff? Well, you’re not the only one. In most projects and environments I’ve worked, there’s not much sharing of personal things, and I hear the most “coffee talk” about work-related topics. Then again, I asked about my colleague’s weekend and if anything special happened.

Frankly, do you know your colleagues, your teammates?

Continue reading →

Happiness door – Management 3.0

Imagine you’re having a meeting, a workshop, a retrospective, a training, … do you know how your attendees are feeling? How do they evaluate their experience?

The goal is to collect people’s feedback on a quantitative level (what’s your rating, your score?) as a qualitative level (how do you feel, what do you like, what could be improved? etc.).

Usually, this is done via “feedback forms,” which works well at the end of a more extended session or training. But applying this for any gathering is very interesting!

You can easily integrate ways to collect feedback in any meeting.

Management 3.0 proposes the feedback or “happiness” door.

Continue reading →