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.

Permanent link to this article:

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.

Permanent link to this article:

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.

Permanent link to this article:

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.

Permanent link to this article:

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.

Permanent link to this article:

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:

Permanent link to this article:

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:

Permanent link to this article:

Aug 24

After continuous integration there is continuous validation

It’s a funny thing to say that delivering business value is the most important thing when developing software. It doesn’t matter that a framework like Scrum is far from efficient, because we focus on value. We deliver business value. Working software. Every sprint. Period.

But in the end we often just don’t know the impact of the things we make. What do we really know about the business value we supposedly created? Is it a one-time validation? Is it a one-way validation?

We keep adding stuff to our products because that is what we are expected to do. We always need more features. But do we know the difference these features make, except that there are more features now? More stuff. What if one feature undoes the effect of another? Wouldn’t that be valuable to know? Wouldn’t it be nice to remove it?

Software development has everything to do with validations. There are at least three rounds of validation from ideas to maintaining the software in a production environment.

Validate your ideas and business goals

Cycle 1

The first round of validation is about vision, business goals and problems to solve. Is the vision of the product (still) right? Are the right personas defined? Is the desired impact of the software defined? Are the right activities defined? Are the goals clear? What is the desired ROI?

Continuous Integration

Cycle 2

The second round of validation is about technical and behavioural validation. Features are being designed, built, tested, accepted and deployed.

Live validation

Cycle 3

Hooray! Your software is live! Well, let’s NOT sit back and relax. This is usually the moment where we tend to run back to the product backlog and get started on new features. Burn down those points! Move post-its around like there is no tomorrow! Like dropping your children off at school without ever speaking to the teachers.

Let’s make sure that this is what the world really needs. Let’s also make sure we keep it that way.

Proactive monitoring

Monitoring is often limited to raising the alarms when something is seriously wrong. With continuous validation you are monitoring something else entirely: you want to know the effects new features or changes have on the system and be able to act on them. Use the feedback you get from your users, that is, from the behaviour of your users. For instance:

  • What is the performance of the most important business transactions? Do the new features affect these? If so, how do they over a period of time?
  • What do heatmaps say about the assumptions you made earlier? Or the usage data? Do the users really use the new feature more than the older one? And what about over a period of time?
  • What do the statistics say about the increase or decrease of a certain feature? Was that the intention?

Validate goals

You make your software with a purpose, right? You want to reach business goals or you want to solve problems. But to make sure your software achieves what you intended it to do and keeps doing you need to validate this continuously. If your goal was to sell more items and you implemented functionality to reach this goal, you’ll need to validate its effectiveness. And then you need to keep validating it because software is no concrete structure and will change.


I cannot emphasise this enough: remove functionality that doesn’t meet the criteria anymore. The world is full of bloated expanding products which become even bigger and unusable. Like the gate in the picture. I’m sure there was a good reason to make it and it worked very well when there was a fence. For now it only costs us because it needs maintenance.

Does your product have gates without fences? Are you aware? Not all as visible as the one in the picture I’m sure, but they’ll cost you money just the same.

Permanent link to this article:

Aug 24

More with LeSS

MatroesjkaFor a while now I’m coaching and training Scrum. And for a while I had the feeling that, even though Scrum works, it is very hard to get it to work in a larger environment. so I needed something extra. So I read books about scaling Scrum and I read blogs and talked to other coaches. But somehow I felt that I missed something. I know that in order to get Scrum to work it is important that the entire company is willing to change. But that is easier said then done. I provided training and talked with management. I also provided workshops and sessions. And everything was great and fun but still something was missing so I started focussing on the Scaling models. SAFe (Scaled Agile Framework) was the first one, and even though it seems to work as a larger framework, it didn’t feel right to me. I’m not saying that SAFe is wrong but it just was not my thing. So I looked further. LeSS (Large Scale Scrum) was the next option. I read about it and I liked it. So I went on a course. Four days buffering over powerpoint slides. Games, debates and theory. It was inspiring and fun. The fun thing was that LeSS is just Scrum, only bigger. And that is what I liked about it. The Scrum part was very familiar, but the strategy to get a company to change was something I loved. Not just a big bang and go on with it. The “Here is your training and now you can do it” mindset. The approach with LeSS has much more to do with slowly preparing the entire company for the change. And only doing that change when everyone and everything is ready.

One thing you have to be prepared for is that the change towards a larger Scrum environment takes time. I often have talks with managers who want Scrum in their company and want to hire me as a coach. When I predict the future and tell them that it will take two to three years before everyone knows a little how to work with Scrum, they turn pale. One or two months is what they hoped for and two to three years is not what they anticipated. But when you come to think of it, it makes sense. Most companies have taken years to get to where they are. Through growth and using various models they are what they have become. And all of a sudden they want to change because the market demands it. You can’t just divert overnight. It takes time. And you will have to take small steps. I know now that LeSS provides in those steps and it can help make the transition transparent for everyone.

LeSS is not easy and I don’t think that every company can just adopt it. Same goes for SAFe or any other scaling model or even Scrum for that matter. Change is difficult and for some people nearly impossible. And in order to do so you have to prepare everyone for the change. Make everybody a part of the the new way of working before you start working like that. LeSS provides in this. It provides a gentle slope of change. But once you have started to climb that hill together, the higher you get, the easier it gets but turning back becomes harder. I know, this sounds fluffy but take it from me, don’t just read a book about scaling but follow a good training. Also hire a coach to help you with the change. Sorry, i’m advertising myself and maybe other coaches. But if you want Scrum to work on a larger scale, you need every help you can get. It is no longer a development team with a scrumboard and a daily standup. We are talking about organizational change, and this is something not to be taking lightly. So, more with LeSS, I’m sure it will but you have to invest for the long run.

Permanent link to this article:

Aug 03

Don’t hire a ScrumMaster

smroleThe ScrumMaster is a role and not a job title, so companies posting a vacancy for ScrumMaster are on the wrong track. Earlier we talked about the idea to first answer the “why” question and then start by looking for the right people to help you with the Agile transformation. Lately we see that roles are becoming much more important. Companies need to change to keep up with the dynamically evolving market. But also need to change to adapt to the way people work together. For long we are saying the specialisme is no longer needed. People need to work more together and divide the various roles amongst each other in order to get the work done. Holacracy is more and more the new way of thinking within the business.

So why not hire a ScrumMaster? As the ScrumMaster is a role within the team, the parts of this role can be divided amongst the various team members of a Scrum team. Keep in mind that one of the goals within Scrum is to evolve a team towards self management. So in other words, the ScrumMaster becomes obsolete when a Team is evolving. In some situations the Scrum master role can grow. So someone filling the role might start helping more than one team and slowly evolve towards a team coach and eventually a company coach. When this happens, you know that the agility growth within the company is happening. The Agile maturity is a different matter and we’ll talk about this some other time.

Also when looking at a ScrumMaster vacancy in most cases the role and responsibilities within the role are poorly described. When you analyse that there are more coaching aspects described, the company does not understand what a ScrumMaster should do. A ScrumMaster role is completely different from an Agile Coach role. An Agile Coach is someone who will advise the teams and organization in how to become more Agile. He or she will be advising them how to play the game. An Agile coach also has the goal to go as wide as possible through the company. He or she is asked to help changing. From teams to management and not so much just doing Scrum but also help with the change to become more Agile across the entire business spectrum. An Agile coach is more a change manager and in large companies this is also a fulltime job. A ScrumMaster facilitates Scrum teams to become more efficient in playing the game. A real facilitator.

When there is a poor description of roles in a vacancy, you are probably dealing with a Non Agile organized company. In most cases those companies ask for a ScrumMaster but actually there is need for an Agile Coach implementing Agile or transform a company to become more Agile. When contacting those companies, in most cases, if you’re lucky they have read some books about Agile Scrum. Majority in Agile is low.

When dealing with brokers in between or recruiters, in most cases they do not ask questions to the companies who have published the vacancy. When asking questions about the role in most cases you get no answer either.

So for you companies who feel they need to hire a Scrum master, first look at the real question. Is Agile Scrum sufficiently incorporated into my company. Do I need more knowledge? And if so. Wouldn’t it be better to hire an expert to get things going. To train the Scrum master role with the people already working. Keep in mind that hiring someone from the outside to fulfill the role of a ScrumMaster might also have a negative effect on the people already working in starting Scrum teams. “Am I not good enough?” or “Why do we need someone from the outside when we are supposed to overcome difficulties within the team?”.

For Agile coaches it is one of the first important signals that there is need for more than just a simple filling in the vacancy. It is a clear signal that they are probably dealing with a company who needs help. For the human resource department it is a first signal that others are struggling to work towards change. Help is needed. For teams and management a clear signal that knowledge and support is needed, but not so much by just hiring a Scrum master. And well for you brokers and recruiters, start by doing your homework.

Co:writer Erwin Verweij

Permanent link to this article:

Older posts «