Tag Archives: work smart

Book – Holacracy

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

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

Organizational Debt

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

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

Or as Ward Cunningham describes it:

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

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

Some definitions of Organizational Debt

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

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

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

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

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

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

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

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

Scrum guide is updated

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

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

Scrum values

The Scrum values are:

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

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

Boek – De Bijenherder

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

Leiding geven aan zelfsturende teams

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

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

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

De presentatie van Mark van den Burg

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

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

En?

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

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.

Contentcuratie met expertlijsten

expertlijst boekenMet ruim 9 miljoen producten in de winkel valt er natuurlijk van alles te ontdekken in een winkel als bol.com. Om je te inspireren en wegwijs te maken in dit enorme aantal, worden er steeds meer experts en productkenners uitgenodigd om expertlijsten te maken.

Naast productspecialisten in dienst van bol.com krijgen verkopers, leveranciers en affiliate partners de mogelijkheid om selecties te maken en zo bezoekers van bol.com te inspireren met hun unieke assortimentscuratie. Uiteindelijk kan iedere gebruiker van bol.com straks zelf een selectie maken van artikelen; vanuit een bepaald thema, een hobby, een actualiteit, specifieke vakkennis of vanuit persoonlijke favorieten. Als lijstmaker kan je zelf een selectie samenstellen uit het omvangrijke assortiment.

Op dit moment loopt de pilot. Ik kreeg de kans om een aantal expertlijsten aan te maken. Je kan ze hier vinden:

Heb je opmerkingen of vragen over de expertlijsten, laat een gerust comment achter.

Book – The Phoenix Project

Book The Phoenix ProjectThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is written the by Gene Kim in the tradition of The Goal (1984, by Dr. Eliyahu M. Goldratt). The Goal is a management novel explaining the Theory of Constraints. This book, The Phoenix Project shows how the theory in The Goal works in an IT environment.

The Goal – Theory of Constraints

In simple terms the Theory of Constraints is about:

A chain is as strong as its weakest link.

In this theory the first step is to identify the constraint. Step 2 is to exploit the constraint. In other words, make sure that the constraint is not allowed to waste any time. Only by increasing flow through the constraint can overall throughput be increased. This to the extend that improving something anywhere not at the constraint is an illusion.

Because of the need for flow, work in process (WIP) is the silent killer. Therefore, one of the most critical mechanisms in the management of any plant is job and materials release. Without it, you can’t control WIP.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

The Phoenix Project describes the problems that almost every IT organization faces, and then shows the practices (based on the Theory of Constraint, Lean and more) of how to solve the problems. The main character Bill, is thought how to deal with these problems using the Socratic Method. Each dialogue a question is posed to which in turn causes Bill to think and to talk to his colleagues to come up with a solution to their problem.

Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. Leading to the application of the Theory of Constraints in terms like:

The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that’s what’s between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.

Work in process in IT perspective

Until code is in production, no value is actually being generated. It’s merely WIP stuck in the system. By reducing the batch size, you enable a faster feature flow. In part this is done by ensuring the proper environments are always available when they are needed. Another part is automating the build and deployment process. Here we recognize that infrastructure can be treated as code, just like the application that Development ships. This can enabled to create a one-step deploy procedure.

Besides the parts mentioned before this requires removing a unneeded (since no value is created) hand off between Development and Operations. For this to work the two have to be integrated, not separated.

Like in a manufacturing plant, in IT, it is crucial to manage the release of work to the shop floor / development and to track the work in process. There are a lot of visual aids available to support this, like Kanban or scrum boards. All have their origin in lean or agile ways of working.

No need to say that in the novel this all works out pretty well 😉 In real life we see that these principles work, however more iterations are needed to really improve things. These iterations at first look like failures because of the acceleration of entropy. They are needed in the learning process of people and organization. Reduce the feedback cycle and learn fast!

On the relation between business and IT

There are some interesting statements in the book, that are heard more often in the industry.

IT is not just a department. IT is a competency that we need to gain as an entire company.
We expect everyone we hire to have some mastery of IT. Understanding what technology can and can’t do has become a core competency that every part of this business must have. If any of my business managers are leading a team or a project without that skill, they will fail.

And:

In ten years, I’m certain every COO worth their salt will have come from IT. Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.

Personally i think they hold at least some value. Please share your ideas in the comments.

Spotify engineering culture part I & II

I’ve been reading quite some article on engineering culture and ways of working. The videos on Spotify Labs are among the best sources I’ve watched or read in the last year on the subjects of agile and culture. Recently the second part of their series on Spotify’s engineering culture was released.

Spotify engineering culture part I


Important take aways for me were:

  • Agile over scrum
  • Principles over practices
  • Servant over master

Spotify engineering culture part II

Very cool that one of my favorite quotes by Mario Andretti was used in the video:

If everything seems under control, you’re not going fast enough.

To cope with this aspect you need a fail friendly environment and a limited blast radius. For the first focus on fail recovery instead of an fail avoidance. For the latter focus on a decoupled architecture.

A healthy culture heals broken processes! Growing organizations have growing pains. Culture can either magnify or heal them.

Update: Henrik Kniberg on Scaling agile at Sporify

The hour talk that Henrik Kniberg gave on Scaling agile @ Spotify is also available on vimeo:

.

Reading list of 2014 so far

In this blog post I’ll share a list of books I read during the first months of 2014. There is more business focus compared to previous years…

The everything store

The everything storeThe everything store is one of the books I liked reading most of my reading list this year. It tells the story of amazon.com so far; The vision and ways of working of the company and it’s founder Jeff Bezos.

The book gives a good insight into the ways amazon.com operates. There is a interesting review on that on The New York Review of Books. You should also read the reviews on amazon.com in which some of the staff reacts on the book. Find my separate post on the book – the everything store.

Mobile first

Mobile FirstMobile First is written by the former Yahoo! design architect, Luke Wroblewski. It is a to the point guide, with good examples. Though examples in this field quickly seem outdated they show the point very well.

The book offers both insightful design patterns and common-sense principles. In the end it all boils down to the adagium: keep it simple.

Automate this, How algorithms came to rule our world

Automate ThisMore and more parts of our lives are ruled by algorithms. There application isn’t only in the financial world or in automated systems inside companies, they are also in medical applications ranging from wait list prioritisation to assisting in diagnoses. The book is full of anecdotes, especially on high frequency trading. It also shows side affects liken how the war for talent has affected development and innovation of other innovations.
There is little room for the downside of algorithms creeping into our daily lives.

Hidden Persuation

Hidden PersuationGreat introduction into the ways in which we are influenced and how we can influence others. It details the psychology behind the techniques of influence described. The book offers very illustrative visual references. It is well created with a fine look-and-feel and an eye for detail.

Hidden persuasion is interesting for professionals in marketing, advertising and communications, but also if you’re just slightly interested in these fields. You will look in another way at (visual) communication in everyday life.