Zelfsturing, heelheid en een evolutief doel

Agile?

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

Scrum Day Europe 2017 (Amsterdam)

Scrum Day Europe in Amsterdam wordt georganiseerd door scrum.org en Prowareness. Gunther Verheyen en Ken Schwaber initieerden het event in 2012. Anno 2017 op Scrum Day Europe wordt scrum.org vertegenwoordigd door Dave West (product owner bij scrum.org). De conferentie gaat door in het Pakhuis “De Zwijger” aan de kade. Het publiek bestaat vnl. Uit Nederlandse scrum.org  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

Continue reading →

Scrum Without Innovation Culture is a Car Going Nowhere

Great article on why approaches like Scrum and Lean startup are about innovation, and change the culture of an organisation towards innovation. The author advocates that Lean/Agile coaching should be mostly change management. It should be about creating a culture of continuous innovation. I couldn’t agree more!

… if this explosion of Agile Coaches and Scrum Masters isn’t leading to a whole host of Scrum zombies, which will then lead to the conclusion in three years’ time that Scrum was a bit like drinking orange juice from jam jars: silly hipster shit. The emperor’s new clothes. Because nothing will actually have changed.

Read the whole article on Medium.

Image source: http://blog.agilistic.nl/content/images/2016/06/Zombie-Scrum—Johannes-en-Christiaan-1.jpg

Scrum Master

Scrum Master

“A good Scrum Master helps the team to solve their problems, helps them to reach the sprint goal.”

“A great Scrum Master helps the team to solve the most crucial problems, creates an environment for the emerge of new practices and emerging knowledge.”

Source: A Scrum Master’s Practical Toolbox

Image: http://paulheidema.com/wp-content/uploads/2014/04/Blog-graphic-scrum-master.png

Challenging Sprint Retrospectives

For the readers: A reference for organising retrospectives is the book “Agile Retrospectives – Making Good teams Great”, by Esther Derby & Diana Larsen. They describe the main steps of an agile retrospective.

The prime directive of retrospectives has been formulated by Norman Kerth in his book “Project Retrospectives: A Handbook for Team Reviews”.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

You can find online all kinds and sorts of formats (games) for retrospectives; I’ve found back a description of a ‘base’ agile retrospective, and I’d like to recommend this to anyone. It focuses on what went well, what could better, and next on identifying and committing to action points for improvement.

What are your thoughts about retrospective facilitation techniques?

Reference to post: “Challenging Sprint Retrospectives

Learned about this interesting book – very promising to read / list:

First chapter: “It’s all invented”.

Standard social and business practices are built on certain assumptions— shared understandings that have evolved from older beliefs and conditions.

And while circumstances may have changed since the start of these practices, their continued use tends to reconfirm the old beliefs.

For this reason our daily practices feel right and true to us, regardless of whether they have evolved to keep up with the pace of change.

In just such a way a business culture arises and perpetuates itself, perhaps long after its usefulness has passed.

(more…)

The Agile landscape – should we care?

Yes, “agile” is an umbrella term, the word was chosen by the signatories of the agile manifesto. Who-ever would be referring to the agile method, doesn’t understand what agile refers to.

The existence of many agile methods, frameworks and approaches (no, Scrum is not the only agile method) for single teams and multiple teams illustrates the continuous journey of exploring and uncovering new and better ways of developing products. And that’s a good thing, isn’t it? It would be worrying if the whole world would agree for a single method or way of working.

Illustrations as the one below show the diversity of methods in the whole “agile” landscape.

agile-landscape

Some thoughts…

Continue reading →

Agile Manifesto Values add-on for large enterprises

We are uncovering better ways of working in large enterprises by doing it and helping others do it.

We value:

Delighting Customers First over Shareholder Returns First

Focusing on Delighting Customers First leads to Shareholder Returns

Enterprise-Wide Agility over Agile for Software Development only

Optimise for flow, learning and feedback along the whole value stream

Empowered Product Teams over Command & Control Role based Work Passing

Long live teams with high Alignment, Autonomy and Safety aligned to value stream

Achieving Big through Small over Achieving Big through Big

Small teams, hypothesis-driven investment, optimise for flow, for better outcomes faster

 

That is. We used to value to things on the right, we now value the things on the left more.

 

Source: https://medium.com/@jonathansmart1/agile-manifesto-values-add-on-for-large-enterprises-f3fdc1abcd65#.wtautdxcw

 

Plan Do Check Act

Plan-Do-Check-Act

Een belangrijk element in een continue verbeteringsproces is een continue cyclus van plannen, uitvoeren, verifiëren en bijstellen. De uitdaging is om deze cyclus herhaaldelijk te blijven uitvoeren, zodat de zin voor kwaliteitsverbetering een continue gegeven wordt.

De indeling van deze stappen zijn de stappen zoals aanwezig in de wetenschappelijke methode: het formuleren van een hypothese, het uitvoeren van een experiment, en het evalueren van de resultaten (om de hypothese juist of fout te verklaren). Deze Plan – Do – Check – Act cyclus (PDCA) is gekend als de kwaliteitscirkel van Deming. PDCA vormt de basis voor continue verbetering en is een element van lean productie.

Scrum als ontwikkelingsraamwerk voor complexe producten heeft zijn origine in lean productie (lean thinking). Het artikel (The New New Product Development Game) spreekt over “incrementele verbeteringen”.

Hoe “Plan – Do – Check – Act” zichtbaar maken in een team?

Continue reading →