Author Archives: Sjors Meekels

Leading Image

Trends in Business, IT & OT – Barry Derksen

De veranderingen in de technologische sectoren volgen elkaar steeds sneller op. Wil je overzicht houden op de laatste stand van zaken en de belangrijkste ontwikkelingen voor de komende jaren? In de nieuwste uitgave van Trends in Business, IT & OT zet Barry Derksen de IT-trends voor 2017-2018 en hun invloed op de maatschappij op een rij. Het boek is voor alle niveaus in een organisatie interessant, maar heeft de grootste toegevoegde waarde voor managers en bestuurders.

In deze 20ste druk van Trends in Business, IT & OT neemt Barry Derksen de lezer mee in de continue stroom van technologische trends en ontwikkelingen. Niet alleen de techniek wordt beschouwd maar ook management en bedrijfsmatige trends. Na het lezen van deze editie is iedereen op de hoogte van de relevante trends voor nu en het volgende jaar. Hiermee kan de organisatie worden bewapend tegen het disruptieve effect van alle nieuwe mogelijkheden.

Het boek is opgebouwd in drie overzichtelijk gekleurde delen (roze, blauw en geel) die op hun beurt zijn opgedeeld in hoofdstukken.

Deel I: Richten
In sneltreinvaart worden in het eerste hoofdstuk, in het Engels, de belangrijkste internationale trends besproken in de gastbijdrage van Prof Dr. Jerry Luftman. Hierna wordt de scope vernauwd tot Nederland met de voornaamste managementzorgen, gebaseerd op onderzoek van onder andere de auteur. Tevens wordt de ondertitel van het boek – Disruptief SMAACT het best – nader toegelicht. De huidige fase waarin we ons begeven kenmerkt zich door disruptie in de markt van nieuwe bedrijven zoals Airbnb en Uber. Dit alles is mogelijk gemaakt door de snelle ontwikkelingen in techniek. De kwinkslag ‘SMAACT’ verwijst naar Social, Mobile, Analytics, Agile, Cloud & IoT en benoemt de belangrijkste technologische drivers achter de disruptie. Voortbordurend op SMAACT grijpt de auteur terug op ondernemingsregels uit 1999 gericht op opkomende nieuwe economieën. Deze regels sluiten nog verrassend goed aan bij de huidige fase en worden door de auteur toegepast en waar nodig aangepast. Ten slotte wordt beknopt het 4R-en model toegelicht. Dit laatste is nuttig, nu dit model in Hoofdstuk 3 veelvuldig wordt gebruikt bij het plotten van trends.

Deel II: Inrichten
In deze blauwe katernen zijn drie van de vijf hoofdstukken geschreven door gastschrijvers. De rode draad in dit deel is de werkwijze voor bestuurders – bv CIO’s – in het begrijpen van en sturen op trends. Aan de hand van de zogenoemde IT-scan krijgen zij een middel om de voor hun organisatie belangrijke trends te onderscheiden en planmatig in te zetten. Daarnaast is er aandacht voor de beginnende CIO-er, gevolgd door de nummer één prioriteit voor IT-managers in Nederland: Business & IT Alignment en de leerpunten uit een groot aantal (internationale) projecten. Het tweede deel sluit af met een beschrijving van de rol van de Chief Information Security Officer (CISO) en een beknopte uiteenzetting hoe deze rol in de praktijk gebracht wordt.

Deel III: Verrichten (Yellow Pages)
Het grootste deel van het boek, grofweg 100 pagina’s, is besteed aan de uitwerking van de 30 meest relevante trends. Dit derde deel vormt voor de voornamelijk inhoudelijk geïnteresseerden het hoogtepunt van het boek. De auteur verdeelt de trends in drie categorieën:
Business Trends, IT Management trends en Technologie trends. The usual suspects zijn allen aanwezig zoals Bitcoin, IoT, 3d Printing Agile, Security en Machine Learning. Maar ook voor – wellicht minder prominente – is in deze editie plaats: Internet of Me, Volumetic Displays of Connected Home.

Conclusie

Voor degene die snel inzicht willen krijgen in een aantal specifieke technologische ontwikkelingen inclusief verwachtingen, raad ik aan direct te bladeren in de Yellow Pages. De hier besproken interessante onderwerpen zijn prima te begrijpen als je alleen kort het 4R-en model hebt bekeken.

Met het lezen van dit boek krijgt de lezer een goed overzicht van de trends en uitdagingen die IT in Nederland op dit moment bezighouden, of bezig zouden moeten houden. Het is de kunst de relevante onderwerpen eruit te halen en je niet te laten overbluffen door de veelheid aan lijstjes en modellen in met name de hoofdstukken 1 en 2. Verwacht niet dat alle trends tot in detail worden toegelicht, daarvoor leent een overzichtswerk zich niet. De grootste uitdaging is ook zeker niet het lezen van het boek maar het maken van de vertaalslag naar de eigen organisatie en haar veranderende omgeving.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op www.bitti.nl.

Filled Under: book review Posted on: 25 July 2017

Leading Image

Interview with De Baak – Sjors Meekels

Being a manager-freak does not necessarily change while working Agile.

Daily planking to ensure short and concise sessions
I am now in an environment where we need to work with several teams simultaneously. In order to let people interact in another way, among others, I organize boot camps. Working out together; that is an excellent way to get to know each other better. It is team transient and it creates short lines. If you also know people from a different setting, it will make a difference than just passing the office. In addition, I have also seen organizations where they do the daily stand-up in the planking pose. Be sure that it helps keep things short and concise.

Working Agile won’t solve all problems, it does make them very visible though
I have been enthusiastic about working with agile teams and organizations for years. Being part of the IT side of an organization, you know how difficult it is to build things well and, on the other hand, to build the right things. The faster the uncertainties and problems that clutter the process are made clear, the better it is for everyone.
Sometimes you see new management that thinks ‘that’s a great method that will solve a lot of things for us’, they are wrong. Agile does not solve organizational problems. It will help, but the problems themselves are not resolved. The problems are systematically and quickly made visible.

Trust is an important bottleneck in transitions
An important bottleneck in an Agile transition is to keep everything controlled. One of the values of Agile is to make teams responsible and in control. Make them self-organizing to solve problems and do everything needed to become successful. This requires trust from managers and the room to fail. Sometimes this proves to be hard, it is not how we are used to run companies or departments. For all distinct roles we had people, procedures and guidelines. To overcome this, is a major challenge for a lot of organizations.

Don’t envy a Product Owner’s position
The Product Owner is the one who determines what is being build and in which order. He also ensures that stakeholders are involved continuously. It is a crucial role. The Product Owner must act in a field with many different interests, multiple stakeholders and many different priorities.
Classic is the contradiction between developing new customer demands versus upgrades or maintenance of systems. New opportunities then collide with the continuity of the systems.
So, you’ll have to be an excellent Product Owner with a good vision of what is best for the company. ‘Quick wins’ and stability of the system should be considered. That is an unfortunate position! A product owner must act as a small entrepreneur and be daring. In my opinion, this is the most critical role in an Agile environment. The Product Owner is the one controlling flame or fame.

Cross team knowledge sharing: Lunch pitches
Also within an Agile context knowledge sharing will not happen on its own. If a team has gained brilliant insights, as an organization you’ll want other teams to learn from it. At one organization, we actively went shopping at the teams. If you have something you would like to share, please let us know, we will schedule it. We made sure that were no blockers: at lunch time! There are always a few first movers who will stand up: I have something to share. ”

Does Agile impact the way we communicate?
Communication per se? I do not see that would be very different if you work agile. If you were a freak in the old organization, you could be very well be one the agile organization.

About this interview

This interview was originally in Dutch and held for De Baak, in case you’re interested: interview. De Baak is one of Hollands leading firms when it comes to education on topics as management and leadership. More information about De Baak can be found here: www.debaak.nl. Any faults in the translation can only be my mistake…

Filled Under: agile Posted on: 17 June 2017

Leading Image

Lean Basis – Rudy Gort

In zijn boek ‘Lean Basis‘ maakt Rudy Gort de belofte uit de titel waar en beschrijft hij de basis en kernpunten van Lean. Hij richt zich op een brede doelgroep van zowel leidinggevenden als medewerkers met een interesse in Lean.

Na zijn boek “Lean vertaald naar projecten” is Rudy Gort terug met zijn nieuwste boek “Lean Basis”. In dit tweede boek richt hij zich op de basis en kernpunten van Lean. Hiermee is het boek geschikt voor iedereen die zich snel een beeld wil vormen en eerste indruk op wil doen. Laat je echter niet op het verkeerde been zetten door de titel; het volledige spectrum van Lean komt aan de orde.
Het boek heeft een overzichtelijke indeling met een duidelijk kop, romp en staart. In hoofdstuk 1 wordt Lean geïntroduceerd en worden een aantal kernbegrippen bondig toegelicht. Hoofdstuk 2 vormt het zwaartepunt van het boek en in 6 paragrafen neemt Gort zijn lezers mee in alle facetten van het Lean-huis. Vervolgens sluit de auteur in het laatste derde hoofdstuk af met enkele slotconclusies en bevindingen.

Hoofdstuk 1
Om de lezer de juiste handvatten te geven, begint het eerste hoofdstuk de oorsprong van Lean en zijn ontstaan bij Toyota. De waarde en kracht van deze methode hebben geleid tot interesse bij het brede publiek, maar ook tot verwarring over termen en inzichten die vaak slechts gedeeltelijk waar zijn. In de rest van het hoofdstuk legt hij relatie met begrippen als Agile, Six Sigma, Ketenintegratie en gerelateerde methodes als Total Quality Management.

Hoofdstuk 2
Het Lean-huis staat centraal in het tweede hoofdstuk. Aan de hand van Nederlandse en internationale voorbeelden beschrijft Gort de vijf elementen van het metaforische huis:
§1. De ondergrond: purpose
§2. Het dak: waarde
§3. Het fundament: waardestroom
§4. De pijlers: kwaliteit en tijdigheid
§5. De kern: gedrag

De beschrijving van het huis start met de ondergrond waar het geheel op rust. Dit is de purpose. Gort stelt dat dit aangeeft wat de reden van het bestaan is van organisaties. De volgende paragraaf staat in het teken van de waardecreatie voor klanten. Deze waardecreatie vormt het dak binnen de metafoor. De doelstelling binnen Lean om de waardecreatie als belangrijkste taak te zien is voor veel bedrijven een enorme uitdaging. Niet alleen omdat bedrijven gewend zijn te maken en leveren wat ze altijd al deden, maar ook omdat klanten mondiger en veeleisender zijn geworden.
Waar het in de praktijk vaak misgaat is de waardestroom, het fundament van het huis. De stroom van activiteiten die zorgt voor de creatie van de waarde, zoals deze door klanten wordt ervaren en beleefd. Een stabiele flow zorgt voor een constante stroom van werkzaamheden en hieruit voortkomende resultaten. De auteur legt beknopt uit hoe de wachtrijtheorie concrete wetten en inzichten geeft in (in? Of ms voor?) de onderbouwing van het principe. Met name de gehanteerde voorbeelden zullen de lezer daadwerkelijk overtuigen van de kracht die in het fundament schuilt. In de deze paragraaf komen ook de bekende leantools aan bod, zoals visueel management, feedbackmechanisme, en gelijkmatigheid. Tussen het dak en de ondergrond bevinden zich de pijlers kwaliteit en tijdigheid. Zonder deze twee zal het dak nooit kunnen bestaan. De pijlers bevatten onderwerpen als just-in- time (JIT), value stream mapping en kanban.
Uiteindelijk komen alle onderdelen van het huis terug in de meest invloedrijke: het gedrag van de organisatie en haar mensen. Zonder aandacht en respect voor dit onderdeel zal het huis nooit zijn maximale potentie bereiken. Continue verbeteren, aandacht voor mensen en teams vormen belangrijke bouwblokken. Herkenbare managementknelpunten komen voorbij zoals de hoeveelheid tijd die managers hebben voor verbetering ten opzichte ad-hoc werkzaamheden – voor bijvoorbeeld brandjes blussen. De beschrijving van het Lean-huis maakt duidelijk dat de onderdelen onlosmakelijk met elkaar verbonden zijn en een holistisch geheel vormen.

Hoofdstuk 3
In het laatste hoofdstuk komen de grootste voordelen en te behalen resultaten van een Lean implementatie terug. Het zelflerend vermogen, ondersteund door kort cyclisch werken, en innovatie kracht stellen organisaties in staat de concurrentie daadwerkelijk voor te blijven.

Conclusie

De heldere uitleg van de auteur maakt duidelijk hoe organisaties kunnen profiteren van Lean. Niet alleen door het toepassen van de meest bekende onderdelen, maar juist door het echt te doorgronden. Leren, leren en blijven leren in plaats van een eenmalige implementatie van Lean.

Wat het boek tevens interessant maakt, is de hoeveelheid extra informatie die de lezer naast sec Lean ontvangt. Bekende methoden en managementtechnieken worden door het hele boek gekoppeld en bekeken vanuit een Lean perspectief. Dankzij deze verwijzingen en de gecreëerde informatiedichtheid is het boek – naast naslagwerk – een goed startpunt voor verdere verdieping.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op www.leanvertaald.nl.

Filled Under: book review Posted on: 7 May 2017

Leading Image

Product Owners! What is dominant on your Backlog: Urgent or Important matters?

Product Owners have a great responsibility in prioritizing the work on the Backlogs. Their role can hardly be underestimated. How about some support from the past? Decades ago Eisenhower made a quote on important and urgent matters. His idea has transferred into a matrix used to prioritize personal actions. Can Eisenhower’s priority matrix help Product Owners in prioritizing backlog items? I think so. In this post I will combine Eisenhower’s ideas with those of Agile product backlog management, and a little wild life.

Eisenhower’s matrix
In short, Eisenhower’s matrix focuses on four distinctive quadrants created by the two viewpoints – urgency and importance. The goal is to determine someone’s priorities [1][2].

Urgent matters: require immediate attention. If possible you should act on these matters now. Important matters: these relate to long term objectives and need constant focus. When combined this leads to the following overview and actions:

Eisenhower Matrix

Now let’s transpose these quadrants to backlog management in an Agile environment. All work on the Backlog can be qualified according to Eisenhower’s quadrants. But what is the optimum setup for your Sprint Backlog? Is there any? Based on the model, I will discuss a set of situations which are all taken from projects and teams I have worked with over the years. In these situations, teams are working on Product Backlog Items that primarily originate from one of the quadrants. To make teams easily recognizable, they all have a different nickname which sticks out.

 

1. Orange Firefighters, brave and busy
Agile firefighting dog

If your teams are busy working on the urgent important issues or new work of this category is entered each running sprint, it seems like your teams are firefighting. This is only a good thing when a) there is an actual fire and b) – more importantly – they can extinguish the fire. If this pattern is more the rule than the exception, changes are something is not OK. This could relate to your production environment, either the applications, the infra, people handling it, or all. Try to look for the root causes and fix those, via the regular process of course. Instead of focusing on optimizing the fire-hoses and firemen. Although your teams are working on the top priority work items, there are risks and down sights. For example, every Product Backlog item which is refined or taken in the sprint and pushed out by the orange firefighters, has been a waste of time. Moreover, the company’s short term future may get hurt if this situation occurs for too long a time.

PROS: working on top priority items, CONS: waste in preparation time, pressure within teams, ATTENTION: should not persist for long, focus on fixing root causes!

 

2. Blue Coyotes, opportunistic
Agile Coyote

Sometimes teams are working on urgent but not important issues sprint after sprint. These teams are the so-called coyotes. This scenario also raises an interesting question. Are those issues really urgent? If you and your team tend to say no, there should be a dialogue. Re-discuss these issues with your stakeholders and try to balance them out with your company’s important stories. In practice it is more convenient to work on topics that are urgent to our stakeholders now. However, don’t go for convenient, but invest in discussions and long-term goals.

Okay, so are you done when the answer is yes? Well, sorry, no. If this situation is continues for a long period of time, it could be a sign that you are understaffed. Not working on the important issues, could be a serious threat to business continuity on the long term. Perhaps you can consider to appoint a temporary team that can eliminate the ‘pile’ of urgent stuff, which is in the way of working on the important stories. However, one thing should be in place before you scale up: a clear vision on what is actually important. This may sound like a no-brainer, but more than a few Product Owners are struggling in identifying what is really contributing to the company’s future.

PROS: satisfying to stakeholders, CONS: not working on the long run, ATTENTION: are backlog items really that urgent or is there too much stuff in the way?

 

3. Green Tortoises, steady but a bit boring
Agile Tortoise

The third scenario reflects the mindset of the tortoise. Namely, where the majority of the work directly relates to important backlog items. Good for you, you keep the company or department in business. However, you might be missing out on immediate revenues from low hanging fruit. Why not optimize your SEO rank now and then, or eliminate that bug 80% of your users are complaining about? These small improvements won’t harm the long-term objective and they do give you a change to help users, increase the short-term cash-flow and satisfy a few stakeholders along the way. Like their nickname, these projects or teams can be a bit boring and move slowly towards a certain ‘old age’ or goal. In their journey, they could lose the connection with the rest of the organization when results are not made visible in the meantime. Besides that, if these projects entail migration without new functionalities, also the teams can get bored. They may benefit from the diversion of small improvement stories.

PROS: working on the mission of the company, CONS: in long running projects stakeholders can get detached, ATTENTION: room for quick wins along the way?

 

4. Well… Black Dodo’s
Agile Dodo

If you have teams working on the black stuff, something is off. Perhaps you are way overstaffed, or backlog management is in utterly disorder. Avoid this situation at all costs. When nothing changes soon these teams will become extinct…

PROS: none, CONS: waste of time and energy for all, ATTENTION: immediate action required!

Balancing act, rhythm and focus

Do you feel like you are getting mixed signals now? You are right. This is the arena where great Product Owners can stand out of the mediocre crowd. If they are able to balance the Product Backlog with the stakeholders and find a rhythm together with their team(s) to ensure enough focus, you have a winning combination. Relevant questions to be answered are: Who is your most important stakeholder? And how are competing stakeholders managed? What is most important for the customer and the future of the company?

A predicable heartbeat helps the team and PO in delivering on regular intervals. Yet, it also promotes alignment in the rest of the organization. The characteristics play an profound role in the optimum heartbeat. For example, if you are part of a true DevOps team, you know ad-hoc work (important and urgent issues) will emerge and that is part of your sprint routine. In another case you might have a more component oriented team, building stuff for other teams.

If you only have one development team available, the balancing act of shifting priorities becomes more precarious. The team can feel comfortable working on multiple topics in one sprint and it is not forbidden to do so, as long as there is enough clarity and stories are really Done at sprint’s end. However, most teams benefit from focus during the sprint, so when possible, craft your Sprint goal on one or two categories only. You could for example spend one sprint on urgent matters and the next two or three on the important trajectory. In general, true orange stories are always executed asap. When multiple teams are involved you can have more flexibility and for example rotate duties between teams every few sprints.

Last thoughts

So, Eisenhower can help in identifying certain wanted or unwanted patterns in your current Product Backlog. What it cannot do is provide the ‘correct’ distribution. That task is still meant for the Product Owners and their teams. I am curious, what kind of wildlife represent your teams currently and how is your Backlog setup in terms of Eisenhower’s quadrants?

References

[1] Eisenhower: http://www.eisenhower.me/eisenhower-matrix
[2] Eisenhower: http://www.businessinsider.com/dwight-eisenhower…..
[3] Coyote: https://nl.wikipedia.org/wiki/Coyote
[4] Tortoise: https://en.wikipedia.org/wiki/Tortoise
[5] Dodo: https://en.wikipedia.org/wiki/Dodo

Filled Under: agile,scrum Posted on: 14 April 2017

Leading Image

Large-Scale Scrum – More with LeSS

Nadat Scrum de software development wereld had veroverd, duurde het niet lang voordat schaalbaarheid een volgend belangrijk thema werd. Inmiddels zijn er meerdere schalings modellen in gebruik waarvan LeSS een bekende is. In hun derde boek, “Large-Scale Scrum – More with LeSS”, nemen LeSS grondleggers Craig Larman en Bas Vodde de lezer mee in de daadwerkelijke toepassing van LeSS in grote organisaties. Het boek richt zich op iedereen actief in een omgeving waar meerdere Scrum teams moeten samenwerken aan één product.

De Canadees Craig Larman en onze landgenoot Bas Vodde zijn inmiddels bekende namen in de Agile scaling community. Met de introductie van LeSS enkele jaren geleden hebben zij hun ervaringen bij Nokia en ander grote organisaties omgezet in een volwassen scaling Framework. Zij hebben drie boeken geschreven over LeSS waarvan dit de laatste is. Het is niet nodig “Scaling Lean and Agile Development” (2009) of “Practices for Scaling Lean and Agile Development” (2010) vooraf gelezen te hebben. Enige vereiste is basiskennis en ervaring met de toepassing van Scrum. Opvallend genoeg is “Large-Scale Scrum – More with LeSSs” naar mijn mening de meest toegankelijke van de serie en een goed startpunt voor een kennismaking met LeSS.

Enkele belangrijke uitganspunten die Vodde en Larman hanteren bij het uiteenzetten van LeSS zijn System Thinking en het statement LeSS is still Scrum. Het tweede uitgangspunt keert continu terug in het boek. Mocht je een LeSS cursus of seminar gevolgd hebben dan is het enthousiasme van Vodde hierover je waarschijnlijk al bekend. LeSS bouwt voort op Scrum en voegt alleen zaken toe die nodig zijn om te schalen. Aanpassen van het model door zaken te laten vallen is niet nodig (tailoring down) volgens de auteurs.

De structuur van het boek volgt nauw de artefacten, rollen en rituelen van Scrum. Hoofdstukken beginnen met een beknopte uiteenzetting van het theoretisch kader uit Scrum en vervolgen met de impact van de toepassing binnen LeSS. Binnen LeSS is een onderscheid in omvang gemaakt op basis van het aantal betrokken teams. Voor 2-8 teams wordt de term LeSS gebruikt en voor constellaties met meer teams geldt LeSS Huge. Dit is nuttig aangezien de impact van het schalen met 6 teams om een andere aanpak vraagt dan met bijvoorbeeld 25 teams.

In de eerste twee hoofdstukken worden de principes en het framework uitgelegd. Mede aan de hand van voorbeelden (Stories) worden theorie en praktijk verbonden. In alle daaropvolgende hoofdstukken wordt een LeSS organisatie aan de hand van richtlijnen (Guides) in detail toegelicht.

Hoofdstukindeling:
1. More with LeSS
2. LeSS
3. Adoption
4. Organize by Customer Value
5. Management
6. Scrum Masters
7. Product
8. Product Owner
9. Product Backlog
10. Definition of Done
11. Product Backlog Refinement
12. Sprint Planning
13. Coordination & Integration
14. Review & Retrospective
15. What’s Next

Hoofdstuk 8 en 10 geven voor mij de kern aan van een succesvolle scaling strategie: namelijk het iedere sprint kunnen uitbrengen (Shippen) van nieuwe software. Belangrijk hiervoor is de drijvende kracht van de Product Owner samen met een zuivere hantering van de Definition of Done. Naarmate het aantal betrokken teams toeneemt, wordt dit in de praktijk een grotere uitdaging. Dit geldt zeker als de software ‘potentieel’ of zelfs daadwerkelijk gereleased wordt.

Enkele zeer herkenbare verbeterpunten in de samenwerking tussen teams komen aan bod in hoofdstuk 13. Het meest elementaire punt in samenwerking tussen teams is de directe communicatie. Zorg dat de teams met elkaar praten, is een belangrijk devies. Gekscherend hebben de auteurs hiervoor een Guide opgesteld genaamd “Just Talk”. Uit ervaring kan ik stellen dat het stimuleren van teamleden om andere teams fysiek op te zoeken – in plaats van te e-mailen, te messagen of domweg te negeren – niet onderschat mag worden.
Less Principles

Conclusie

Of LeSS de methode is om Scrum te schalen laat ik aan de mening van de lezer over. Met het lezen van dit boek worden in ieder geval duidelijke richtlijnen en handvatten gegeven om concreet met dit model aan de slag te gaan. Zelfs als LeSS niet gehanteerd gaat worden als officieel schalings model, dan zijn de Principles, Rules, Guides meer dan de moeite waard om te kennen en te toe te passen. Ook voor de ervaren Product Owner of Scrum Master is het een praktisch boek om nieuwe inzichten op te doen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op less.works.

Filled Under: book review Posted on: 9 March 2017

Leading Image

Managing for Happiness – Jurgen Appelo

Kom jij als manager, coach of consultant tot de conclusie dat de geijkte management technieken en methoden steeds minder aanslaan? Stoten jij en je teams zich aan dezelfde steen als 10 jaar geleden?

Een vergelijkbaar inzicht had Jurgen Appelo voordat hij in zijn eerste boek uit 2010 Management 3.0 introduceerde. In zijn recente vervolg Managing for Happiness beschrijft hij een set van practices en principes waarmee managers organisaties verder kunnen helpen binnen het gedachtegoed van Management 3.0. Hij inspireert op een speelse manier het anders kijken naar verantwoordelijkheden, rollen en de benadering van management in moderne organisaties.

Het boek van Jurgen Appelo, Managing for Happiness, is een aanrader voor iedereen die aan de slag gaat met teams, afdelingen of zelfs hele organisaties. Het doel van het boek is om anders te werk te gaan dan bij traditionele managementbenaderingen. Hoewel zijn roots liggen in software ontwikkeling, is Jurgen tegenwoordig blogger, een veel gevraagd spreker en trainer. Zijn boek is geschikt voor alle organisaties waarin zogenoemde creative workers, een verbastering op kenniswerkers, werken en is niet enkel gericht op IT-organisaties of -afdelingen.

De stijl van het boek is in lijn met zijn eerdere boeken. De vele voorbeelden uit zijn directe omgeving en imposante klantenkring zorgen voor een levendig geheel. Met humor, zelfspot en een scherp oog kijkt hij naar zijn eigen managementstijl en die van anderen. Het boek is makkelijk leesbaar en vrolijk vormgegeven met quotes, foto’s en tips voor een snelle start. De opzet van het boek leent zich prima voor selective reading. Naast de kop en de staart zijn in aparte hoofdstukken 12 concrete practices beschreven die goed los van elkaar te bestuderen zijn. Zo ben ik zelf, na een eerste blik, gestart bij hoofdstuk 10 en daarna zigzaggend door de onderwerpen gegaan.

Hoofdstukindeling:
1. Kudo box and kudo cards
2. Personal maps
3. Delegation boards and delegation poker
4. Value stories and culture books
5. Exploration days and internal crowdfunding
6. Business guilds and corporate huddles
7. Feedback wraps and unlimited vacation
8. Metrics ecosystem and scoreboard index
9. Merit money
10. Moving motivators
11. Happiness door
12. Yay! Question and celebration grids

Mijn persoonlijke favorieten zijn de practices Delegation boards (hfd. 3) en Merit money (hfd. 9). In de eerst genoemde legt de auteur uit waarom het belangrijk is om helderheid te verschaffen over de verantwoordlijkheden en vrijheden van teams en individuen ten opzichte van bijvoorbeeld management. Hij introduceert een praktisch hulpmiddel, Delegation poker met als resultaat een zogenoemd Delegation board. Teams spelen met of zonder managers het Delegation poker en schatten het niveau van beslisvrijheid op belangrijke thema’s (key decision areas). Hierbij wordt een schaal gehanteerd van 7 niveaus waarop deze beslisvrijheid wordt geplot. De discussies over verschillen in inzicht en interpretatie leveren veel op voor de deelnemers, met name duidelijkheid in verwachtingen. Het resultaat van deze sessies wordt samengevat op een Delegation board, dit overzicht wordt opgehangen zodat voor iedereen letterlijk te zien is welke afspraken er zijn gemaakt. Een dergelijke aanpak ondersteunt en stimuleert het zelf organiserend vermogen van teams en individuen (creative workers).

Delegation Poker

In de tweede, Merit money, bespreekt de auteur een interessant alternatief voor het uitdelen van jaarlijkse bonussen op basis van beoordelingen door managers. Hij stelt een model voor waarbij medewerkers elkaar constant virtuele waarderingen kunnen geven (coins, credits of hugs). Deze waarderingen komen van peers, zij hebben immers het beste zicht op de prestaties van collega’s. Op gestelde tijden – ook de timing hiervan is belangrijk – krijgen medewerkers een bonus uitgekeerd op basis van de verzamelde virtuele waarderingen.

Zelf ben ik zeer benieuwd hoe de twee hiervoor beschreven practices in de praktijk zullen uitpakken. Dit betekent niet dat de overige 10 practices minder waardevol of interessant zijn. In tegendeel, de toepasbaarheid is alleen sterk afhankelijk van de ervaring en context waarin de lezer zich begeeft. Voor alle practices geldt dat zij een zinvolle invulling geven aan lastige onderdelen in organisatie management.

Heb je zelf al met een aantal practices in de praktijk geëxperimenteerd? Geen zorgen, de extra suggesties en alternatieven aan het eind van ieder hoofdstuk geven nieuwe handvatten en ideeën voor uitbreidingen. Eén kritische noot over het boek betreft de vormgeving. Hoewel kleurrijk en afwisselend is het ook druk en dit kan de lezer in het begin afleiden.

Conclusie

Wat maakt dit boek een aanrader? Als een auteur in staat is de lezer te mobiliseren en hij redenen geeft om het eigen functioneren en dat van collega’s te heroverwegen dan is hij een eind op weg. Inspireert een boek mensen om de volgende dag nieuwe stijlen of methoden in praktijk te brengen, dan heb je iets speciaals geschreven. Dat laatste is bij Managing for Happiness zeker het geval. Van veel practices zijn online materialen beschikbaar, dus je kunt na het lezen direct aan de slag.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op jurgenappelo.com.

Filled Under: book review Posted on: 29 January 2017

Leading Image

Move before you’re ready

De laatste jaren zijn er binnen talloze organisaties verandertrajecten ingezet. Gedreven door personele reorganisaties, marktuitdagingen of compleet nieuwe bedrijfsmodellen. Maar hoe zit het nu met het verandertraject zelf?

Moet dat niet bij de tijd blijven en meegaan met de nieuwste ontwikkelingen? Jazeker. Simon van der Veer en Linde Peters delen in het door hen geschreven Move before you’re ready hun ervaringen met verandertrajecten en steken het verandertraject in een modern jasje. Voor iedere professional bezig met organisatieveranderingen geeft het boek nuttige tips en handvatten om de verandering zo soepel mogelijk te laten verlopen.

In de inleiding van Move before you’re ready beloven auteurs Simon van der Veer en Linde Peters dat zij veranderaars praktische handvatten geven om het veranderen te veranderen! En dat is exact wat zij doen in dit beknopte boekwerk. Het boek richt zich op consultants, teamleiders en managers en in feite op iedereen die graag een verandering in zijn of haar organisatie wil doorvoeren.

In 5 min of meer onafhankelijke hoofdstukken nemen de auteurs de lezer mee langs belangrijke thema’s binnen verandertrajecten. Plukjes theorie, geleend uit Scrum, Lean en Lean Start-up, worden gebruikt om de praktische tips en voorbeelden te ondersteunen en van context te voorzien.
Tussen de hoofdstukken door zijn korte intermezzo’s opgenomen, geschreven door bekende namen zoals Hans Vermaak (veranderkunde) en Arend Ardon (bedrijfskunde). Het geheel is voorzien van tekeningen van sneltekenaar Willem Minderhoud, wat het boek een speels karakter geeft.

Hfd. 1. Waarom wendbaar zijn onafwendbaar is
In dit eerste inhoudelijke hoofdstuk leggen de auteurs uit waarom het snel kunnen veranderen voor organisaties van bijzaak noodzaak is geworden. Hierbij wordt geput uit populaire methodes of frameworks als Lean en Scrum. Belangrijk blijft daadwerkelijk aan de slag te gaan en het gebruik van methodes niet tot doel te promoten.

Hfd. 2. Weet waar je ja tegen zegt
Durf je het aan om te beginnen zonder een volledig uitgewerkt plan? Op deze vraag en meer geeft hoofdstuk 2 antwoord. Via enkele prikkelende vragen aan de lezer – de veranderaar – wordt nagegaan of duidelijk is waar men aan begint. Sta je echt open voor zelfreflectie? Durf je te starten zonder draagvlak? En, ga je door als productie of kwaliteit onder druk komen te staan? Dit zijn vragen voortkomend uit de opgedane ervaringen met verandertrajecten en met name de laatste vraag doet in de praktijk pijn.

Hfd. 3. Het enthousiasme aanwakkeren om snel in beweging te komen
Veranderingen beginnen met een ambitie en een van de belangrijkste factoren voor slagen is het enthousiasme wat je voor de verandering creëert binnen de organisatie. Enthousiasmeren gaat niet vanzelf; dit hoofdstuk omvat een aantal richtlijnen ter ondersteuning. Toepasselijke quotes die de auteurs aanhalen zijn Sense of excitement in plaats van het ‘oude’ Sense of urgency.

Hfd. 4. De verbeterbeweging vasthouden en uitbouwen
Als de verandering eenmaal in gang gezet is, is het zaak deze goed te begeleiden en echt door te zetten. Hoofdstuk 4 beschrijft enkele behulpzame aandachtspunten: houd praktijk en verbetertraject bij elkaar, blijf experimenteren en zorg voor de noodzakelijke randvoorwaarden. De nadruk ligt echter op de belangrijkste uitdaging – het behouden van focus. Net als bij Scrum wordt gewezen op kleine trajecten, duidelijk omschreven oplevercriteria en terugkerende leermomenten. Deze rituelen helpen voorkomen dat medewerkers opgeslokt worden in de waan van de dag.

Hfd. 5. Gedoe benutten om verbetering robuuster te maken
Hoe noemen we alle discussies, die bewuste en onbewuste weerstand? Juist: gedoe. In het laatste hoofdstuk staat het gebruik maken van gedoe centraal. Door jezelf hiervan als veranderaar bewust te zijn kun je gedoe in het voordeel van de verandering laten werken. Het scheppen van een open leerklimaat is een van de factoren die hierin een rol speelt.

Tot slot

Het leukste intermezzo is opgenomen tussen hfd. 3 en 4. De drie gastauteurs laten zien dat bij ieder gesprek of ontmoeting de voorgenomen verandering een stapje verder gaat. Met name het inzicht dat veel doelstellingen als een omgedraaid probleem zijn geformuleerd, zet aan het denken. Bij een persoonlijke terugblik herken ik deze formuleringen in het merendeel van verbetertrajecten waarin ikzelf betrokken ben geweest. De kracht zit hem juist in het concreet maken van de doelstelling.

In een kleine middag of ochtend kun je Move before you’re ready doornemen en bekijken welke tips en voorbeelden van toepassing zijn binnen jouw eigen organisatie. De handvatten zijn praktisch en concreet genoeg om zelf direct toe te passen, zonder dat hiervoor veel georganiseerd hoeft te worden. Juist die combinatie van herkenning en makkelijke toepasbaarheid maakt dit boekje tot een prima reispartner in je verandertraject.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op twst.nl/move-before-youre-ready.

Filled Under: book review Posted on: 15 January 2017

Leading Image

Must I Do This Now? In an Agile context

Over the years, I have worked with many teams within organizations moving from left to right in constant change. People from all places are targeting Engineers and other team members with ad-hoc questions or small assignments. Of course, in Agile environments Product Owners and Scrum Masters should be there to shield part or most of these interruptions. Yet, that is not always possible. The result is people who get distracted and are not confident about priorities. This is only a ‘big’ problem when there is more work to do than is possible timewise. So that is pretty much anywhere. Hence, we have to prioritize to keep ourselves and our teams focused. The mnemonic ‘Must I do this now’ can help you redefine your priorities.

Must I do this now?

There is a lot of power stored in this little sentence constructed out of 5 words. Let’s play a game and change the emphasis 5 times in a scenario where someone asks you to do something right now. See what happens to the meaning of the question and how it can help you redefine your priorities. In each case I’ll reflect on the way the question should be answered in an Agile context.

1. [MUST] I do this now?

Is the chore or question really necessary? People working in projects are used to MoSCoW [1]. I reuse that idea: if it is not a Must you probably should not do it. Often you immediately know if something is that important or just a nice thing to have.

In Agile: In using Scrum or Kanban, you can check the current Sprint Backlog or Work in Progress and verify that nothing in there is less important than the new chore at hand. In case you are doubting, the Product Owner should be there to help you decide. Do not hesitate to ask for clarity or advice.

2. Must [I] do this now?

During your day you might receive a lot of questions. For some people asking something is even second nature to them. Often easier than thinking or solving a problem by themselves. Well, your time is valuable as well. The next step is to rethink if you are indeed the best person – or the only person – that is capable of handling this request. Perhaps the requester or another colleague is equally equipped.

In Agile: Teams should be able to handle all the tasks and preferably all skills are shared and well distributed among the team members. At least there should be someone else – besides you – capable of responding to the request. If someone else is looking to pick up something new and he or she is capable you don’t need to interrupt your current task. This will help you to stay more focused.

3. Must I [DO] this now?

Before rushing into solving mode or chasing a problem, check out what the best modus operandi would be. What would solve the request? Sometimes no action is required at all. If the answer is the latter, there is no need to use the other questions. It is for this reason that this question is sometimes promoted to the top. In this blog, I stick to the order of the words for simplicity.

In Agile: In Scrum all user stories that are part of a Sprint must be ready and crystal clear. That means that the outcome itself and the way to achieve the outcome are also clear. If the “Do” part of a chore is not clear than the first step would be to get that clarified by the Product Owner or other stakeholders before adding it to sprint. Scrum Masters should learn teams to make stories as clear as possible and should check the clarity of the “Do” part regularly during refinements or planning sessions.

4. Must I do [THIS] now?

Then there is the actual “this”. Is the “this” the most appropriate and feasible action? Do you know what is driving the enquirer? The key element is not to rush into action mode just because someone has come up with an idea.

In Agile: Scrum and Kanban both push teams to get these aspects out of the way before they start working on something. Refinement sessions are used to clarify all stories and make sure we can actually do all the “thisses”. These tactics can also be used for random questions that come up during a sprint. Bottom line: If they are not clear, just don’t start working on them right away.

5. Must I do this [NOW]?

Last but not least is the “now” part. Now implies urgency. The urgency, however, is perceived by whoever raised the question. Often an action can wait, maybe for you to finish what you are working on, or maybe even longer like a week or more.

In Agile: Again, the Product Owner is the first go-to person to support you in assessing the urgency of the new request. If the assessment is made that the urgency can wait for a week, most times it can be planned and picked up in the next sprint. When organizations are in the midst of the transition to an Agile mindset you often see this ad-hoc pattern recurring. Team members receive requests directly from various stakeholders within the company and not via the Product Owner and Backlog. This indicates that more energy has to be put in the organization of these request flows to fully support the sprint rhythm.

Agile & Common sense

Of course common sense should always prevail and will hopefully be your first advisor. When an important production system is down, there is no time to waste. DevOps Teams often use practices like reserving time for production support or unexpected work to protect their Sprint Goals. A relevant quote from the Scrum guide in the Sprint section: “No changes are made that would endanger the Sprint Goal.” [2]. That is a firm statement. Yet, it also provides guidance to teams to judge whether there is room left in the sprint to help others or to stay focused to the current goal. So, for me these 5 words help me in the coaching of Agile teams to get their priorities straight out in no time. As mentioned in the intro, this approach is not only applicable to Agile teams but useful for everyone with more to do than time available. For another approach you could explore the usage of the Eisenhower Decision Matrix [3].

Side note

Firstly, I don’t take credits for the mnemonic as I did not invent it. A former colleague showed it to me a few years ago. I was not able to find it original roots [4][5]. Secondly, the sentence is a translation from the Dutch “Moet ik dit nu doen?”, which means literary the same – word by word – only in a different order. Since it is an external obligation in the question, the usage of “to have to” in stead of “must“ would improve the sentence’s grammar [6]. I guess the meaning as-is is still solid enough and in this way the original esthetics of the sentence remain intact, instead of “Do I have to do this now?”.

References

[1] MoSCoW method: en.wikipedia.org/wiki/MoSCoW_method
[2] Sprint Goal: www.scrumguides.org/scrum-guide.html
[3] Eisenhower Decision Matrix: www.artofmanliness.com/2013/10/23/eisenhower-decision-matrix
[4] Origin I Moet ik dit nu doen: lifehacking.nl/persoonlijk-tips/moet-ik-dit-nu-doen (Dutch)
[5] Origin II Moet ik dit nu doen: www.carrieretijger.nl/prioriteiten-stellen (Dutch)
[6] Grammar Must – to have to: www.englishgrammarsecrets.com/musthaveto

Filled Under: agile,interim management,scrum Posted on: 14 November 2016

Leading Image

Digital Empathy

Digital Empathy – De achilleshiel van IT, de eerste twee woorden van de titel van het boekje van Marco Gianotten zijn zowel paradoxaal als prikkelend. Zoiets als binair inlevingsvermogen, nullen en enen – maar dan met gevoel. Bestaat deze combinatie überhaupt wel? Voor praktisch iedere IT-manager biedt Digitale Empathy – de Achilleshiel van IT van Marco Gianotten een interessante kijk op de huidige werkwijzen en contractuele afspraken die IT partijen met elkaar en de business aangaan. Empathie is wat vaak ontbreekt en juist daarvoor breekt de auteur een lans. In zijn boekje Digital Empathy – de achilleshiel van IT behandelt Marco van Gianotten op een toegankelijke manier de behoefte aan empathie in het vak van IT-management. Met treffende voorbeelden en een scheutje theorie schetst hij een modern alternatief voor de huidige afsprakenkaders en uitgangspunten zoals deze gebruikelijk zijn binnen IT afdelingen.

Het beknopte boekje is in een handzaam formaat gegoten en bevat 3, min of meer gelijke, hoofdstukken voorzien van illustraties en toepasselijke quotes.

Hoofdstuk 1 – Op weg naar een IT-crisis?
In het eerste hoofdstuk schetst de auteur de korte geschiedenis van IT-afdelingen en hun managers zoals deze in de laatste 50 jaar zijn uitgegroeid tot de spil in menig organisatie. De eisen die momenteel gesteld worden aan de afdelingen, maar nog meer aan de mensen die hierin werkzaam zijn, blijken drastisch veranderd. Hiermee zijn de geijkte vaardigheden zoals abstract denkvermogen en analyse – veelal voortkomend uit de logisch denkende linkerhersenhelft – niet langer toereikend. Er is meer behoefte aan balans in de gevraagde skill set van betrokkenen en het hebben en gebruik van empathisch vermogen is daarbij essentieel.

Hoofdstuk 2 – De ingrediënten van IT nieuwe stijl
Wie regelmatig vliegt, begrijpt direct het voorbeeld van Mintzberg in hoofdstuk 2. Het illustreert hoe lastig organisaties het zelfs nu nog vinden om vanuit klantbeleving hun dienstverlening in te richten. Dit wordt nog een stap lastiger als het twee IT-organisaties betreft die een samenwerking aangaan. De meest voorkomende vorm waarin een samenwerking is vastgelegd, is vaak een Service Level Agreement, kortweg SLA. Met voorbeelden geeft de auteur invulling aan de nieuwe ingrediënten die nodig zijn voor een succesvolle samenwerking: openheid, inzet van de rechterhersenhelft en focus op het resultaat voor de business. Met andere woorden een ‘SLA nieuwe stijl’.

Hoofdstuk 3 – Experience first met de XLA
Het zwaartepunt van het boekje ligt op het begrip eXperience Level Agreement (XLA) en hoe je hiertoe komt. Maar wat is een XLA? Met die vraag start hoofdstuk 3. Zoals de auteur aangeeft is een XLA ‘geen product, geen dienst, geen model.’ Hij maakt handig de brug naar meer bekende termen als DevOps en Agile. Ook dit zijn principes welke tot uiting komen in de wijze waarop mensen hun werk uitvoeren. Een XLA stelt de beleving van de (interne) klant centraal en vult pas daarna harde KPI’s en interne sturingsmodellen in. Hiermee geven organisaties zichzelf de kans een betere aansluiting te vinden met diezelfde klant. Dat dit nodig is blijkt wel uit de kenmerken en verwachtingen van generaties Y & Z en de Millennials. Met een grote glimlach bekeek ik de geschetste Millennial Maslow piramide. De auteur heeft aan het origineel twee lagen onderaan toegevoegd: Battery en daar bovenop Wifi. Als ik zie hoe de huidige generatie jongeren in hun zoektocht naar Pokémons het park bij mij om de hoek onveilig maakt, zou dit zo maar eens waar kunnen zijn.

Tot slot

Het formaat, de vlotte stijl en de vormgeving met ondersteunende afbeeldingen en uitspraken maken dat je Digital Empathy – de Achilleshiel van IT in één adem uitleest. In een avond of een ochtend, je zult niet kunnen stoppen. Niet dat er revolutionaire ideeën naar voren komen, maar de overduidelijke behoefte aan empathie en begrip is datgene dat na het dichtslaan blijft hangen. Voor Service Level Managers, inkopers of dienstverleners is dit boek een echte aanrader. Daarnaast biedt het voor iedere manager in IT een andere kijk op de samenwerking met partners en afdelingen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op giarte.nl/digital-empathy.

Filled Under: book review Posted on: 20 September 2016

Leading Image

First LeSS Conference – Ever

The first LeSS Conference – Ever
So the first ever LeSS conference was about to take place in Amsterdam. A few former colleagues were planning on going so I was immediately interested as well. The lineup was promising, Bas Vodde and Craig Larman would be present and Gojko Adzic was one of their guest speakers. My knowledge of LeSS was limited to what I had read online as I have not yet been in an organization using LeSS as a scaling framework. Well, you guessed right, I ended up going and in this blog I will share some of my personal highlights of this two-day-event.

Opening and setting
The body organization of LeSS is not a big commercial vehicle which rolls out events like this every few weeks. So things were new and the atmosphere was also newish and therefore relaxing. Cesario had the honor of opening the conference

Story of Less- Bas Vodde
The history of Less may be told during trainings, yet as I heard the story for the first time it was entertaining, recognizable but also refreshing. LeSS is still Scrum, but with a little extra. The focus on Feature teams is an important aspect and needs to be strong. Component teams are not ‘forbidden’, but they mustn’t form the majority. Another interesting point is continuing the Scrum mindset as a framework. The opposite as with RUP, which you have to tailor down, meaning don’t use everything except the parts fitting your own situation. In LeSS it is called “Build Your Method Up”. Bas can probably tell the Story of Less like no one else and the good thing was, he told the story like sitting around a bonfire (just a fire on a video this time). He only showed the slides of the actual story in a total of 20 seconds when he was finishing up. The story was mainly on the core essence and the history of LeSS and not like a mini-course.

Teams and assignments
One of the goals the event organization has was to establish new communities and to enhance the interaction between visitors. The leading mechanism they initiated was the forming of new team who should collaborate on genuine product to be shown at the end of day two. So the entire group of people were gently pushed to form teams by self-organizing. Every visitor had received one or more small buttons indicating a certain capability, e.g. developer, designer, LeSS expert. The goal was to create teams with all the capabilities covered. Yes indeed like a true cross functional team. So this was my team:

Less Conference 2016 My team

The method worked pretty well and it was indeed good for introductions to new people. The actual goal for the assignment wasn’t that clear so most teams lost quite a bit of time on discussions and a few teams dissolved entirely the next day. Yet, experimenting is also a foundation of LeSS so no harm there.

Owning versus Renting Your System – Craig Larman
The title sounds somewhat more relating to a car or house but it made quite an impact on me. When coaching and convincing people to adopt Scrum and to adhere to the rituals correctly you can really see the difference. Some teams start breathing Scrum and start coaching each other- yes and me – when things are not done properly. Stand ups are swift, the board is neat and people respect priority set by the Product Owner. Other teams, are never prepared for anything, forget Dailys when the Scrum Master is not around and follow the coach or Scrum Masters guidance a bit reluctant. The latter team is just Renting Scrum they don’t Own it, the first team does! Craig didn’t use this example, that’s just my reflection of the difference in my daily struggles.

Less Conference 2016 Craig Larman
The way to make people buy into an idea and letting them own it was the main thread in his talk. The Why (by Simon Sinek) is solid starter and he then used some more examples based on system theory to let people reach their own opinion and ideas about the way of working. In doing so people are coming up with a part of the solution and start owning it – bit by bit.

Memorable Quotes:

‘No more yak shaving’

‘Underpants gnome profit plan’

So..
The relaxing atmosphere and openness to experiment with the format was nice. Only downside was that it perhaps was a bit stretched and for me personally the last sessions of the second day lost some value. All in all it was very interesting and an excellent place to meet like minded people and increase your network and at the same time increase your knowledge!

Contributions & References

[1] Conference home: less-large-scale-scrum.com
[2] Program and slides less-large-scale-scrum.com/program.html
[3] Less: less.works
[4] Story of Yak shaving: sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html
[5] Origin of Underpants gnomes: www.youtube.com/watch?v=tO5sxLapAts
[6] Impact Mapping (Gojko Adzic): github.com/facilitation-games/revenue-stream-map

Filled Under: agile,scrum,software development Posted on: 5 September 2016

Mission statement

Setup, guide and coach high performing teams capable in delivering truly great software.

Be Awesome

How? Try to improve something small everyday..... In management, in coding or life.

Learn from anybody

Be aware that every colleague, teammember or friend is capable of something that you are not.

Fail and letting fail

Failure is the only way to success, so fail fast and fail often, especially in software development.