May 01

Our agile scan is zero. Great!

ScanAt some point in every company that is doing some sort of change towards Lean or Agile, the big question is asked. “Are we agile or Lean enough?”. So coaches start being busy with all sorts of scans to measure the level and even maturity of the teams and surrounding business. There are many types of scan’s and the latest count that I could make is that there are about sixty or more. They all ask about the same questions in different order and all of them have various outcomes. It is impossible to figure out which one is the best and when you get to a certain measurement it is impossible to accurately do something with the outcome.

Let me give you a few examples of the questions you will find in these scans:

The team knows who the product owner is.

All team members, including testers, are included in the sprint retrospective meeting.

Automated unit testing is implemented where appropriate

Is the team focused on working on the most important things?

Are changes in approaches by the team(s) leading to changes in the overall organization?

Is the team…… ah forget it. I can assure you that every survey has more or less questions like this. All about teams working together and in a business environment. And you can get all sort of numbers and nice graphics out of them. From spiderwebs to growing charts.

The question is what is the goal? I agree that the questions in themselves may lead to some sort of self awareness, and that is a good thing. “Hey guys! We don’t have a visual sprint board.Let’s build one” but appart from that everything else is just numbers on a scale from 1 to whatever.

I find that in almost every case the measurements are used to inform management that there is movement. “Great, look we are on a five on the agile scale. We are doing great.” But because there is no baseline for what is good or bad, it is meaningless. We all know that you cannot compare one team with another. I have had teams who sucked at doing scrum but delivered perfect and great software. And I have seen teams who do perfect scrum but deliver shit. And when it is impossible and useless to compare teams. What if you want to do the same with business units or various parts of the company. One unit can do perfect while the other one is doing a lousy job. Even when the number say that they are equal.
scanSo is there a good measurement to use when you want to read the success of teams or even the company. I think there is only one. The measurement you can do is time how long a agility report is stuck to a wall. You know what I mean. The nice graphs somewhere on your visual wall. Or how long it takes before someone is asking about that certain number in a powerpoint and why it is up or down. “Yes we measure velocity, bugs, happiness, agile maturity or whatever but it is just so we do them” Well stop doing them. I think that is your ultimate goal in measuring is not doing it at all. There is nothing to gain out of growing numbers. The questions are great to get people to think and please keep asking questions. But stop turning the answers into numbers.

I’m a Certified Enterprise Coach. There are about ninety in the world. That must mean that it is very hard to become one so one a scale from zero to  maturity that must make us the top of the line. I think that on the agile coach scale I’m a five. Cool and there is no higher level than this. Wait.. what? Forget it. I learn every day and there is always room to grow. The same goes for teams and companies Stop labeling and measuring and focus on what is important. Good communication, great software and collaboration and keep on changing and asking questions.

Your ultimate scan is when there is no more need for scans. Within our company the number of maturity scans in brought back to zero and we work hard to keep it that way.

Permanente koppeling naar dit artikel:

Dec 19

Enjoy your trip, follow the map

I stumbled upon this image. Christopher Webb designed this London Subway map of all the different ways to work. It has to do with Agile thinking and different frameworks and methods to work in this way of thinking. Apart from the fact that it is a complex network it made me think. You can look at it the same way as you look at a real subway map. The whole is complex. So many directions and options to travel. But that is the whole point. You don’t need to go everywhere. You just need to pick one destination and take the correct route to get there. When you travel in the real world you just need to follow one, maybe two colors to get to your destination.


The same goes for change within your company. Don’t do everything. Pick one route and stick to it. Forget all the other tunnels and tracks and just travel to where you want to go. Or at least what feels right to go to. I often see companies that adapt to almost everything. Who mix up various routes and try to get somewhere and often that does not work. Like in real live traveling you cannot just pick the nice stations and skip the boring, smelly and ugly once. You need to pass each one. And that is why I like this map. Not for all the information it provides and the connections it shows. But for the metaphor it provides. So I can keep this blog very short and hope that you get what I’m try to explain. If you want to get to a certain destination, pick your framework, method or way of working. Do every step, even the once you don’t like or that don’t seem to add value. Learn from each step and know why you like or dislike it and see what is there. Until you get to where you want to be. And if you see a different route that get’s you to the same destination and it feels that it is better suited for you, then take it. But only switch stations at the right moment.

And sometimes the old road seems like the best. But like in real life sometimes you have to take a new direction to get to new places. Traveling back gets you nowhere apart from places where you already have been. Oh and a few more obvious ones. It’s much more fun to travel together. If you get lost get back to the map and the fun of traveling is not the destination it is the trip itself. So enjoy the ride and have a fun journey (I wanted to say safe but that’s a bit too much of a metafore)

Permanente koppeling naar dit artikel:

Nov 29

Kill the hybrid


Picture by Sarah Derememer

Often I venture into companies that already started to use some sort of Agile way of working like with Scrum or Kanban. When it concerns a large company, frameworks like Scrum or Kanban most of the time aren’t enough. So scaling methodologies are available like  LeSS (Large Scale Scrum), SAFe (Scaled Agile Framework) or Nexus. But often I don’t see this happen. In most cases a hybrid form is incorporated into the company. The Spotify methode, I didn’t even know there was one, is used like a very popular way of making things bigger. Always spiked with SAFe, LeSS and Scrum parts. Unfortunately only the easy parts and that is where it goes wrong.

Don’t get me wrong, even though as a coach i’m quite a fan of using a good framework or methodology, i’m not a Agile fanatic. I don’t go running around yelling at people when they do it wrong. If it works it works. But when you want to change a large environment you need to take into account all the variables. It is not just adopting a nice model from a music publisher and throw in a weekly retrospective, some stand ups and a half designed Kanban board. Every scaling model has it’s own unique way of working. In every model there are great things that can work immediately but also, and often more things, that don’t seem to work as easy or as fast as one would like. And by throwing those out and just use what seems nice is not the way to go. When designing a hybrid you need to know what you are doing and just copying that what the competitor does is very dangerous. Even copying a model that was presented by a music publisher two years ago. Sure, the Spotify way of working is great. It has cool names and the way of working seems to work. But it works for spotify. And you are not Spotify, even if you publish music. I bet that your company DNA, people, culture, product and so on is different. Be careful what you take on as your perfect way of working. Don’t become someone else’s untamable hybrid even when it looks so cool on Youtube.

Agile has to do with change. And change has to do with pain. If you don’t feel pain then you are not changing. Most of the time when I introduce a framework I get to hear that what I show will not work. “That will never work at our company, it is way too different from what we are used here” but that is exactly the point. In order to change you need to do something that is not what you already do, otherwise why would it be called change? Also when you want to move with your company into a different direction, you need to move with the entire company. Not just the development departments but also with management, board, customers and so on. It is movement and you can only move fast and easy if everyone moves in the same directions (I know it’s obvious but that’s what i’m here for).

A hybrid develops over time. It is not something you engineer before you start. A hybrid forms due to small changes to a basic model. Start with Scrum, SAFe or LeSS or whatever model you prefer and fits best. And over time adapt it, tweak it and shape it so it works. But even better. Don’t! If you really want to do it the right way start with adapting, tweaking and shaping your company. Then you actually are changing. When you keep the model that you incorporate in tact and change the way you work so it starts to work, then you are actually doing the right thing. Don’t design a hybrid but try to kill the hybrid. Don’t become a next Spotify adaptor but become your own original. This means you have to go through the changes the hard way. There are no shortcuts. Change takes time and dedication. But let’s face it. What is more fun and something to be proud of?. To become another company who copied something from the others or one who stayed true to itself with the help of a well designed framework. I know what I would choose.

Permanente koppeling naar dit artikel:

Sep 18

Stop starting with Scrum

Don’t worry: I am not going to jump on the “agile is dead and a failure” bandwagon. I do not want you to stop working with Scrum. I just want you to stop starting with it.

A lot of companies realize something’s got to change in order to survive. Especially software development departments feel the need to be more flexible and innovative in order to keep up with a rapidly changing world. We’ve been promised that an agile framework like Scrum will do just that.

Often the larger agile transitions are primarily focused on the Scrum aspect. Development teams are doing everything by the Scrum guide, but things don’t seem to go as the book described it. Many times it is an isolated implementation that is started on, limited to the development department.

Crap in, crap out

All the while the input – or requirements – stays just as it has been the past decades: not prioritized, a lot of demands for per-customer customization, and lacking a clear vision. Yet this is where you should start: sort out the input. After that the implementation on a team level will be much easier and more meaningful.

There needs to be a concise and clear business case, which results in a vision of the product. The impact that the product needs to have must be clear. ROI needs to be validated with stakeholders. Only after these the roadmaps, epics, features and story maps can be made. And when they are done they need to be revalidated. Make no mistake about the amounts of time this will take: it will be substantial. But all that is logical, since this is the hardest part.

Even if gathering the input is the only action taken you will still have gained a lot. With a better quality of input the product stands a much higher chance to be better. Whether by Scrum or Waterfall. Yes, Waterfall.

unfulfilled promises

There is a theory that Scrum will have a butterfly effect on organizations; that when a single team starts the rest of the company will see the benefits and follow. Everyone will become agile and focus on business value. Well yes, sometimes that’s the case. In most cases however, starting with Scrum on a development team level is not going to bring you more than frustrated isolated development teams, because the agile promise isn’t coming true. Agile was supposed to be more fun, software would be better and customers would be delighted.


The rest of the organization is as frustrated as ever, because the development teams can’t be bothered to deliver on time: “deadlines are a thing of the past, and just not agile”. The gap between business and IT that we were supposed to bridge with agile is now even bigger than it was.

Fulfill the promise

So in order to fulfill this agile promise – which is not necessarily dead, as some may say – we need to stop starting with Scrum.

Permanente koppeling naar dit artikel:

Aug 29

Trust the bike

A while ago I read a parody of the Agile Manifesto at a Agile Coach Gathering.  Myself and other coaches laughed about this. It is often that when agile coaches meet that we laugh about things. And sometimes we cry a little.
Schermafdruk 2016-08-29 10.45.03

We laugh because somethime this is the only logical thing to do. We talk about our experiences and share what we know. It is our job, or should I say our passion, to help others. That’s why we do what we do. We know something and it is know as using common sense when it come to working together within a group, team or company. We love to see people grow and excel in their work. And to see companies change into fun and creative places where people love to interact and create. We get paid, a lot sometimes, but our real payment is to see that what we know and share is used to do good.

So why do we laugh? Because most of the times we see that the ideas that we promote and teach are used in a strange way. Often even in terrible ways. Our trainings are misinterpreted and even our role is misused. We laugh because sometimes it is the same as seeing your child riding a bike for the first time and ending it in the bushes or the garbage cans. A bit scary and you will never laugh in there face because you know they are trying and eventually ride that bike. We also know that one day they even borrow our car (I know, even more scary but it will happen). They are able to surpass the master. Ok, let’s turn that laugh into a smile.

But sometime we cry because we see that what we do is used in the wrong way. And when we say something about it we are ignored or even expelled from the room. We see entire companies using Agile and Agile frameworks to there own liking and bidding. Roles are invented so people don’t need to change. Events are planned around the Agile events so controll won’t change. And reports and numbers are introduced around the Agile transparency so people can keep using the old ways.

We as coaches try to help and say something about this but it’s the same as withthe child riding a bike. When you try to correct them they will become agitated. They want to do it themselves and that is fine. But when they keep trashing into the garbage cans or falling down, eventually they need help. But children and companies are a little bit the same. When they keep hurting and don’t see that this hurt is part of learning and growing up they start blaming that stupid bike.

To bad that the comparisons end here. Because kids eventually get back on that bike because all their friends also ride bikes and they want to join the race. Companies however often change the bike. Ad side wheels and safety bumpers. Or they throw away the bike and tell everybody to just walk or better, keep crawling on all fours like they did in the past. And we cry because we see a lot of people working in companies who know how to ride that bike.

So what is the big thing that is holding companies back into really changing, to really start riding that Agile bike and to have an open mind in falling down and standing up. What is holding them back in trusting us Agile coaches and throwing all the old ways overboard. To kick out that pacifier ( i love metaphors) and change? It is trust. The one small word for something big. Trust in people who want to change or just simply do the thing that they are hired for. And what is the point in hiring experts and then not listen to them. That is stupid and a waste of money and time.

So what I’m trying to say is that if you really want Agile and Agile frameworks to work, start using that bike properly. Trust that the people using it will fall down but also get up again. And trust the guy or girl behind you who has that one hand on your back and the other hand on your steering wheel. Eventually the will give you that one big push and let go. That is also trust. And yes you will hear us shouting behind you not to let go and keep pedaling and to trust the bike.  But the further you get, the less you will hear us.

Permanente koppeling naar dit artikel:

Jun 29

Functioneringsgesprek en beoordelingsgesprek zijn niet meer van deze tijd

workersDe welbekende jaarlijkse of halfjaarlijkse feedback gesprekken werden eind vorige eeuw ontwikkeld om de prestaties van werknemers meetbaar te maken. Functionerings– en beoordelingsgesprekken gaan ervan uit dat werknemers gecontroleerd moeten worden en zijn vaak niet gericht om de ambities en ontwikkeling te ontplooien. Vaak zijn deze gesprekken een management moment waar aansturende managers met mooie inzichten kunnen komen over het functioneren van mensen. Vreemd genoeg zitten veel werknemers niet te wachten op deze gesprekken. Deels omdat ze vaak beperkt zijn en vaak omdat de persoon die ze afneemt, meestal de leidinggevenden, een momentopnamen maakt.

Tegenwoordig werken steeds meer werknemers zelfstandig en bepalen hun eigen werktempo, werkplek en werkmanier waardoor ze voor veel managers onzichtbaar zijn. Interviewmethoden zoals bijvoorbeeld de Star methode zijn ontwikkeld om inzichten te krijgen in het functioneren van iemand zonder dat de interviewer zelf getuigen is geweest van het functioneren. Op zich vrij vreemd. Iemand beoordelen op basis van aannames en een bepaalde manier van vragen stellen.

De gesprekken hebben ook geen toegevoegde waarde omdat het vaak over globale punten gaat waar werknemers op dat moment niet veel mee kunnen. Een terugblik op een halfjaar is van geen enkele toegevoegde waarde en vaak weet men niet eens meer waar de kritiek of lof over gaat.  Iemand krijgt liever direct feedback op het moment dat het van toepassing is. We kunnen ons prima vinden als we  bijvoorbeeld na voorzitten van een vergadering onmiddellijk feedback krijgen over hoe we de vergadering hebben geleid. Daar kun je gelijk iets mee. Of in een gesprek met een klant direct terug krijgen hoe dat gesprek gegaan is. In trainingen is het heel gewoon om na afloop een beoordeling te vragen, waarom dat niet vaker doen bij alles wat we doen. In organisaties die met vernieuwing bezig zijn is directe feedback zeer belangrijk en nodig als het nodig is. Jonge werknemers weten vaak heel goed welke kant ze op willen met hun ambitie en grijpen ieder feedback moment aan om zichzelf te verbeteren.

Vaak worden beoordelingen ook gekoppeld aan een beloning. De gesprekken bepalen of iemand meer salaris krijgt of budget mag aanwenden voor een opleiding of training. Een slechte beoordeling kan zelfs betekenen dat iemand wordt gedegradeerd, geen bonus ontvangt of zelfs ontslag kan verwachten. Geen wonder dat veel werknemers niet uitkijken naar deze momenten. Ik zou ze liever veroordelingsgesprekken willen noemen (dank je Laurens). Beladen momenten die vaak zorgen voor demotivatie en ontwijkend gedrag. “Doe mij maar als laatste”.

Het is jammer dat er nog veel organisaties zijn die niet op dit vlak vernieuwen. En dat terwijl er veel nieuwe manieren zijn ontwikkeld om feedback te geven. In nieuwe werk manieren als bijvoorbeeld Scrum zitten al momenten waar men elkaar feedback geeft. Er zijn rollen binnen het model, denk aan de coach en scrummaster, die mensen van gewenste feedback voorzien. De eerste regel binnen het Agile Manifesto is zelfs dat mensen en interactie tussen mensen krachtiger is dan processen en tooling. In modellen als Holacracy worden mensen op hun rol aangesproken met het idee om deze rol te versterken. Mensen kunnen binnen Holacratisch ingestelde organisaties veel sneller ontdekken waar ze goed in zijn en in kunnen excelleren. Het hele functiedenken binnen Holacratische omgevingen is zelfs afgeschaft, dus daar ga je met je functioneringsgesprek.

Mocht je als organisatie niet bezig zijn met Agile denken of Holacracy dan zijn er natuurlijk andere manieren dan het impopulaire functionerings- en beoordeling gesprek. Denk bijvoorbeeld aan Impraise waarbij mensen direct via software en een app om feedback kunnen vragen of deze elkaar geven. Kleine momentjes die continue kunnen plaatsvinden. De feedback is ook vrij direct waardoor mensen onmiddelijk kunnen leren en inzichten kunnen verkrijgen om zich te verbeteren (mocht dat nodig zijn).

Vaak krijgen we te horen dat het allemaal wel leuk is. 360 graden feedback. Continue feedback (op wat voor manier dan ook). Afschaffen van traditioneel en achterhaald denken en ga zo maar door maar dat het helaas nu eenmaal zo is binnen het bedrijf. Vaak zijn het processen die ingesteld zijn zonder dat men eigenlijk nog echt nadenkt of ze wel effect hebben. Iedere vorm van weerstand komt aan als weerstand tegen de organisatie. Je wil niet meedoen met het verplichte veroordelingsgesprek dus je bent daarmee tegen de organisatie. En dat komt natuurlijk weer niet als goede beoordeling in je dossier. Begrijpelijk dat men vaak in een vicieuze cirkel zit en het moeilijk is om deze te doorbreken. Managers en werkgevers zitten vaak zelf vast aan het proces en werknemers spelen het spelletje maar mee.

Het eerste goede gesprek om te houden is een functioneringsgesprek mbt tot de vorm van het functioneringsgesprek. En natuurlijk een beoordeling van het beoordelingsgesprek. Als met zo graag de werknemer krachtiger wil maken en wil laten groeien, luister dan ook naar de echte wens van mensen. Voorzie in de behoefte van mensen en niet in de behoefte van een achterhaalt systeem. Vernieuwing vind plaats door op alle vlakke te veranderen en verandering is goed (KaiZen). Vooral als het gaat om verandering rond mensen. Want als de mens centraal wordt gesteld binnen een organisatie en de processen eromheen dusdanig worden ingesteld dat ze toegevoegde waarde hebben voor die mensen, dan pas ontstaat er een krachtig geheel waarin mensen kunnen groeien.

Permanente koppeling naar dit artikel:

Apr 30

With law our land shall rise, but it will perish with lawlessness

VikingsThe Agile Manifesto was written in February of 2001 by seventeen independent-minded software practitioners . While the participants didn’t agree about much, they found consensus around four main values. For those of you who are not aware they are as follows.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I think everyone working with Scrum or any other agile framework should be aware of the manifesto (if you’re not, shame on you).

But the Agile manifesto is nothing new. Working together and do something that is worth something for someone is a good idea. Knowing that a plan does not always work and things might change is good to know and react upon. For a while now the manifesto is used. As agile coaches we say that is good to be agile and not do agile and that is fine, but it is still a concept that for most newbees is hard to grasp. We work together and deliver software or something else but still clinch to old habits and ways of thinking. It is not easy to become agile and change your mindset overnight. And how can you become something if there is not a real example. Or if you like, there is not a real role-model. I like the way the first agile thinkers came up with this but I wouldn’t wanna be them. I’m not a Sutherland, Swabber or any other agile founding father (that sounded really scary). So how can you become something else without something to inspire you. It’s fine that you can work in a team and deliver high quality products to a happy and engaged customer, but that does not turn you in a agile minded person. So where can we find inspiration?

As I said, the manifesto is not something new. There is something that is much older and it originated somewhere in 10th century. Yes, more than a thousand years ago somewhere in the north of europe. Somewhere in the Norse world the first of these laws originated amongst the vikings. They were not made up with Agile in mind but with something else as a goal. They were written to conquer and rule. The vikings came up with the “Viking laws” and over the years they changed a bit. The Norse also were very straightforward incoming up with all kinds of laws and agreements on how to behave or life together. The very word LAW in English is a Viking word. After the vikings stopped their reign of terror and christianity spread, the laws changed and became less aggressive. But the first four basic laws are still very powerful. So what are they, and keep in mind that the sub-laws derived from the original four laws.

First law: Be brave and aggressive

Now this one strikes me as a good first rule when you are a warrior, but it can also be used in business. It is also very well usable in producing something. So what does it mean, Be brave and aggressive?

  • Be direct
  • Grab all opportunities
  • Use varying methods of attack
  • Be versatile and agile
  • Attack one target at the time
  • Don’t plan everything in detail
  • Use top quality weapons

Second law: Be prepared

Need I say more. It’s all about team and team dynamics. And to be prepared means you can do the following.

  • Keep weapons in good condition
  • Keep in shape
  • Find good battle comrades
  • Agree on important points
  • Choose one chief


Third law: Be a good merchant

This one could apply to product owners, salespeople and even managers. I think it should be an sales oath.

  • Find out what the market needs
  • Don’t promise what you cannot deliver
  • Don’t demand overpayment
  • Arrange things so that you can return


Fourth law: Keep the camp in order

Workplace, work environment and working together. And it is not just keeping you sprintboard up to date.

  • keep things tidy and organized
  • Arrange enjoyable activities which strengthen the group
  • Make sure everybody does useful work
  • Consult all members of the group for advice


If you read these laws with a working environment in mind it makes sense for your team and even your company. These simple laws worked for the vikings and admittedly they are written so they are a bit more acceptable for our thinking.  The vikings didn’t have a workplace or went out to find what the marked needed. And also being on the other side of the viking blade was not a really good place to be as they used these laws to plunder, pillage and rape. But for the vikings it worked.
From now on I don’t print the Agile manifesto to be posted on the wall, I provide a cool poster with these viking laws. I think they are much better to understand and relate to. Because let’s be honest. I much more like to be associated with a tough viking then with one of the seventeen software practitioners who gathered in Utah to come up with the Agile manifesto. I’d rather be a Agile Viking then a Agile Coach. I think I will put that on my next business card.

Many thanks to Rolf Dräther from for introducing me to the Viking laws.

Permanente koppeling naar dit artikel:

Jan 22

The Curriculum Vitae is history

Erwin VerweijLet’s face it. The Curriculum Vitae (CV) does not work. Curriculum vitae is a Latin expression which can be loosely translated as [the] course of [my] life according to Wikipedia and is used by many of as to show to potential employers what we have done with our professional lives. It is a sum of all the thing that are in the past, our former jobs, education and so on. I’m sure that you as a reader have your own version. Needly designed with the right typeface, layout and information, ready to provide at the first opportunity. Or better, ready to provide at the first demand. So why does it not work?

The truth is not in there
At first, let look at the name, Curriculum vitae, course of life. It is a document that looks backwards in time. It tells what you have done. This seems something of importance but we all know that in our CV we only tell the things that we are proud of. We tell of our achievements and the victories, it doesn’t say anything about the lessons learned. The struggle, the pitfalls or the failures. Why, because we are not keen to share this and potential employers would skip your CV if you would mention them. This is strange as it is in these lessons that makes us unique and also very interesting. So we keep those difficult questions for the job interview where we have to share a little of our bad experiences but not to much as that would also jeopardize the interview and the change of being hired. So when you come to think of it we lie on our CV and try to camouflage the truth as much as we can. So first of all, what is the point in writing down the past when it is only half the real thing. And sharing a reference, same thing. You would not share the name of the manager of the job that you screwed up, or the one that screwed you up.

You don’t want to go back
Second, we send our CV to potential employers in the hope to move forward. To get that new job or assignment and to grow and learn more. Most of the time we do that because we have to. either the current job is ending or we are not happy at where we are. If you look back into your past all of us have jobs that we hated but also jobs that we really liked at that point in time. But there is a very small change that you would want to go back to that former job. Even if it was the greatest job in the universe, there was a reason that you moved on. Either you got bored and there weren’t enough challenges. Or the payment was bad. Maybe the company moved and you were not that dedicated to move with them, or they simply went bankrupt. Just to name a few. Either way those ships have sailed and you moved on. So why keep lingering in the past. As I mentioned before, we only tell the good things about our past experiences so again there is no point in doing this.

Surpassing the teacher
The third thing is what we have learned. We sum up all our training, certificates, diplomas and so on. Nothing wrong with that as it is something that you have achieved and worked hard to get. But how many of you remember their basic teachings. All that gained knowledge has grown over the years and we added a lot more from experience, reading and doing. When I look at my own learning past I even got diploma’s for welding, steel machinist and even electrician. Trust me, you don’t want me in your workshop or let me do your electrical wiring. I simply forgot and probably end up making a mess of it. But still people ask me for information about that part of my life. Who cares, I moved on way beyond that knowledge. Although I still have some affection to technique. So, when we are honest about what we know, most of it is from experience and learning on the job. Even from reading but I haven’t seen a single CV where there is a prefered booklist.

Look ahead
So three things that just look into our past and none of them makes any sense. So what should we do then. Well that is very simple. Talk about what you would like to do. Where do you want to go, what is it that you still want to learn or experience. Often we are asked to write a motivation alongside that CV. Why do we want to work somewhere? Well to be honest, I don’t want to work anywhere. I much more would like to sit in my garden drinking a cold beer and reading a good book. I would only trade that for a really nice challenge, something cool, where there are great people from whom I can learn and share my own experience with. I would love to leave my garden and cold beer if I can really make a change somewhere. And no, i don’t want to do what I did in the past. The same things over and over again, I want to grow, learn, teach and experience. When I’m asked why I want to work at a certain company I have no idea because I haven’t worked there yet. I do know they have a great product or service that I would like to get to know more of and maybe even leave my mark on it so maybe it can become even better.

Who do you want?
When you think of this as an employer, who would you rather have. Someone who has done the same thing over and over again at different companies. Or someone who is keen on doing new things, eager to grow and willing to make mistakes and learn from them. I agree that a CV provides a shallow look into someone’s past, but admit that someone’s future is much more interesting. A new thing, especially in europe is the Resumé. A short description that, when done right, tells what someone would like to do. What they want to learn and where they want to go. My CV, that I hate to use and send, is about 4 to 6 pages long. My Resumé is one page and let’s you know what I like. It has two or three lines in it about what I have done and learned. Until know I have had more success with it, than with my Curriculum Vitae. And I’m even replacing my Resumé with just a picture of myself with my passions displayed. 

The CV is looking backwards and somehow, the way they are written, not really reliable. You better spend time in looking what someone is willing to do and where they can take you. Don’t look for someone with ten years of experience. Look for someone who is willing to experience for the next ten years. You want energy not waste. And be honest, you want to read a small poem about someone’s dreams, not a six page history book. And if you want to know about someone’s past. Just ask them over for a nice cup of coffee, I’m sure you will switch very fast towards dreaming about the possible future instead of lingering in the past.

Permanente koppeling naar dit artikel:

Nov 16

Impact mapping and continuous validation

There is always a reason for making software. Let’s rephrase that: there should always be a reason, at least from a business perspective. How else could our products have any impact?

Whether we want to make an app that that seamlessly connects riders to drivers or build a community where you can hire and rent apartments while earning tons of money: it is basically all about adding value and solving problems from a software point of view.

Impact Mapping

Impact mapping is a technique that can be helpful in defining the impact you want your product to have with all that follows. Why are we doing this? You first define the desired impact with some criteria that you consider necessary to make this impact. These criteria stand for the how and the what.

The example below from by illustrates how impact mapping works:

  • We want to reach 1 million players on our platform.
  • We think that there are three personas that can help us with that: players, internal employees and advertisers.
  • We think we know how they can help us with that.
  • We think we know what will facilitate them on our platform.

The impact map cheat sheet made by Craig Smith can be a helpful aid to keep everybody focused while doing the impact mapping:



With impact mapping we make a lot of assumptions. In the example below we assume that the actor called Player can help us in making the desired impact (1 million users). We also assume that Player will do this by inviting friends, and we make the assumption that semi-automatic invites will help.


Following up on your stories

The thing I don’t see happening often is following up on the impact of a piece of functionality. We have a review or demo and sometimes we get feedback from users. Yet apart from some performance monitoring we do not really know a lot about the impact we are making. Did we make valid assumptions?

Continuous validation

With continuous validation we also make many assumptions. In contrast to automatic unit tests we want to keep validating the same assumptions in production as long as the functionality is alive, and not run it only once. It is very common that the impact of one feature is diminished by a newer one. To create great projects this is something you really want to know and should act on.

We introduce validation as an extra dimension to a user story. We call this an experiment. These experiments will run scheduled in production as long as the functionality is there. The experiment for the example above could be:

Experiment: By giving players the option to invite friends semi-automatically the number of players will increase.
Baseline: Get the current number of players.
Assume: There will be a 10% increase in new players.
Time: 1 month.
Success: Send cake to the whole team with congratulations.
Failure: Push message to Product Owner.

Other things I would like to know and want to create experiments for is how much the invite option is being used, who uses it, and what the assumed effect is after 6 months?

Impact mapping and continuous validation

In a sense continuous validation is the automation of impact mapping. Where impact mapping is a great way to define products, continuous validation makes sure your assumptions are being validated. Not once, but as long as the functionality is alive.

Creating great products is not only about adding new cool features. It is also about removing or changing existing features whose goals aren’t met. We know which impact we want to have. Are we in any way achieving this goal? Are our assumptions right? Is there functionality that is not contributing to our goal?

Manual monitoring of all the assumptions that were made is undoable most of the times. Working software must be delivered at an ever faster pace. That’s why after continuous integration there is continuous validation.

Hylke staperma @hylke1982 and myself are currently working on a continuous validation framework called Gareth ( It is an open source project and we would really like to hear from you if you are interested in contributing, trying Gareth out or just discuss it. Fork us on

Impact mapping:

Continuous validation:

Permanente koppeling naar dit artikel:

Sep 16

Meet Gareth. He is seriously unpleasant.

Hello world, please meet Gareth. He can be seriously unpleasant. Trust me, we know. But he is becoming more and more indispensable.

He will tell you clearly, without emotions, when your ideas are rubbish. He will certainly not hold back and he will give you the facts when your assumptions don’t hold up. He will keep validating that your business goals are reached. If not, he’ll let you know.


What Gareth does

Gareth validates the Why, the reason certain functionality was built in the first place. He makes sure that the (business) goals are reached and keeps validating these goals. We all know that implementing one feature can affect another. This also has impact on the success of the related goals.

Gareth loves business goals. He doesn’t want to talk about functionality. He wants clear assumptions like: the performance of feature x will be 25% better after implementing this change; feature y will decrease the usage of functionality z by at least 50% over the next 3 months, and so on.

Why we really need Gareth

There is a lot of focus on software craftsmanship and automation. We can build and deploy software very quickly with current technologies. However, it’s the post-deployment stage that worries us. How can we be sure that this new functionality has the impact the business needs?

We believe user stories and backlogs are too detailed and complex as an aid to communicating with stakeholders. We think it would be better to talk with them about goals and assumptions. What are the goals and how do we want to validate them?

We know the world changes, and so must our software. That’s another reason we need Gareth. It’s vital to know that your goals are still reached after changing parts of the software. Sometimes one feature makes another unneeded. If so, Gareth will let you know.

Gareth Logo incl Name

How Gareth works

We introduce validation as an extra dimension to an user story. We call it an experiment and it consists of:

Experiment: Name of the experiment
Baseline: What is the initial state.
Assume: Which impact do we hope/wish the software is going to have?
Time: What is the interval and period of the experiment?
Action: Which action does Gareth have to take when an experiment fails/succeeds?

Let’s describe an example:

The story:
As the owner of the hotel booking site,
I want the users to see the rooms with discount first,
So that they will be booked first.

The experiment could be:
Experiment: I want to validate that by showing the discounted rooms first, there will be an increase in booked rooms.

Baseline: Get the current number of discounted rooms booked per week.
Assume: There will be an increase in bookings for discounted rooms of 25 per week in the first month.
Time: 1 month.
Success: Send email to the whole team with congratulations.
Failure: Send an email to the Product Owner.

Baseline: Get the number of discounted rooms booked in the last 6 months.
Assume: After 6 months, bookings of discounted rooms have increased by 80%.
Time: 6 months.
Success: Send reminder to buy cake for the developers.
Action: Create an investigative story on the backlog.

Gareth will run these validations as often as described in the assumptions and take the appropriate action. It is a great way for a product owner to be sure the right things are being built and kept that way. This is what we want to communicate to our stakeholders.

It is also great for teams to see that not only code, but also business goals are validated continuously.

Gareth Schema Business

Get Gareth

Are you interested? Please be our guest and try Gareth. Gareth is open source (GNU General Public License v2.0) so that we all can benefit. Do you want to contribute in any way? Please let us know! We are really looking forward hearing from you.

Get Gareth:

Permanente koppeling naar dit artikel:

Oudere berichten «