The Ultimate Tester: Build Quality In

Maaike Brinkhof


One of the most important aspects of agile working is the fast pace. In an ideal world, you can deliver to production constantly. However, if you deliver software fast, but it is full of bugs, your product has a lower chance of succeeding. As an agile tester, one of your focus points has to be to speed up the feedback loop while maintaining good quality. We no longer want to give feedback about the product with a manual regression testset that takes days or even weeks. That’s simply too much time to waste. Let’s stop that nonsense, we’re better than that.

Before you start automating your regression test on GUI level, hold on a second. Think about what you want to achieve first. What do you want to test on which layer of your application? There are a couple of helpful concepts to help guide you: the testing pyramid, testing scales (to help you map out components of your application and think about how how heavily you want to test those)  and the agile testing quadrants (to see what types of testing you have used and what you are still lacking). Always consider your context and where the risk is, do not write tests without asking yourself what value they provide. Read more

7 Agile Practices You Can Apply in a Controlled Environment

Chris Lukassen

So your teams want to do Agile, perhaps have even started doing so. Now your project managers run around wondering what story points are and why any number of people seem to be attributing hours to their project code. So the question is: what can you adopt easily without turning the Governance of your organisation upside down?

Prince2 can severely hinder your agility

Prince2 can severely hinder your agility, but that is no reason to stop smiling

Is this an ideal Agile way of working? No it's not, but it's a good first step that you can take without frustrating the environment too much. That will make additional steps easier.

 Read more

"Tealing" The Capitol using Holacracy, Lean and Scrum

Paul Takken

Something absolutely revolutionary (or should I say evolutionary) is currently unfolding @WaTech. This CIO-department of the State of Washington is transforming towards the first Teal governmental organization in the US and perhaps even worldwide.

C24DFB21-3029-4E3A-BC31-A6C9CEB01A34Invited by initiator CIO deputy Michael DeAngelo, Joe Justice and I visited the WaTech offices in Olympia to observe and coach the Scrum teams applying Scrum, Lean, and Holacracy.  What we’ve seen there can be described best as energizing, accelerating, customer centric and dedicated.   Characteristics you’ll expect from a start-up, not from a governmental organization.

This was exactly what Michael DeAngelo had in mind starting this journey in order to be more competitive with WA-State based companies like Microsoft, Disney, Expedia, Amazon and Boeing by creating an awesome "Smell of the Place".

Ingredients for this tasteful recipe were Agile, Lean and Holacracy.  These methodologies paved the way for a different, more empowered mindset of WaTech employees.

WaTech is using Scrum to enable fast learning and acceleration and stay focussed on the most important Minimal Viable Product (MVP). In combination with the core principle of Lean, how do I create a maximum of customer value with as little effort as possible, a powerful combination was born.

But still, bureaucracy and time-taking decision making would still be there without Holacracy.  How does Holacracy eliminate this?   Holacracy is a system that makes accountability in an organization crystal clear.  Decisions don’t need to travel looking for a home.  They belong to the person who is empowered for the specific role.  As a result, 80% of team members feel empowered and confident they can lift impediments themselves.

hola sergeAnother powerful mechanism in Holacracy which prevents long decision making, is consent.  Unless you have a tangible example how a proposal could cause harm or move the organisation backward, the proposal will be accepted. Currently, an average decision in a governance meeting takes less than 2 minutes. This means a decrease of 93%(!) with the situation before Holacracy.

Step by step but determined, WaTech is moving towards a self-organizing Teal Organization.  WaTech employees feel more empowered, valued and happy.  It's no rocket science to draw the conclusion this a blessing for the citizens of the state of Washington.

Perhaps the most important outcome is team members don't think in restrictions anymore but use their imagination again pushing borders achieving the unthinkable: projects which would have taken 3 years before, are now executed in just 3 months.

The next phase of this transition will be even more exciting and challenging; Leadership from the local government is needed to enroll Agile, Lean and Holacracy in more departments. However, new elections are underway later this year.  Let's see what happens. But I'm convinced the teams we've seen in Olympia would even survive the biggest storm!

Screen Shot 2016-05-21 at 10.12.11 PMCurious about a more in-depth analysis and the current situation @WaTech?  Join our presentation and panel discussion @Agile2016 in Atlanta!  See you there on July 25th!


Keeping dependencies up-to-date in Maven

Jesse van Bekkum

Keeping your dependencies up-to-date is more important than ever in modern projects. Everything is connected to the internet and needs to be secure. New vulnerabilities in libraries are found, exploited and patched within days. We use a lot of dependencies, and due to continuous delivery some of your dependencies will need updating every day. Solid dependency management is a primary requirement for good software.

In this blog post I will describe how to keep a Maven project up-to-date with the versions plugin. Using the versions plugin has a lot of benefits and configuring it takes less than an hour. So I suggest using it for all maven projects.

 Read more

Pitch your product using the 3x3 framework

Chris Lukassen

When pitching innovative product ideas, you only get between five and fifteen minutes of attention. To make those minutes count, you should be able to define your product vision in a simple but comprehensive way. For this, I’ve found this 3x3 framework technique useful. Not only is it a pretty good format for pitching your product, but it also helps you define the vision.

 Read more

Versnel je team met Scrumban!

Pieter Rijken

Herken je dat ook? Teams die meer dan een half jaar aan het scrummen zijn en sprint commitments maar niet halen? Of maar geen stijgende 'velocity' laten zien? Blijven verbeteren zonder een echte verbetering te zien? Scrumban is het toepassen van de Kanban Methode in de context van scrum en geeft deze teams een weg hieruit door een structuur en principes te bieden.

Veel voorkomende symptomen

In de praktijk kom ik het volgende veel tegen:

  • herhaaldelijk missen van de sprint commitments,
  • het hebben van 2 Definition of Dones,
  • een velocity die over sprints heen hetzelfde blijft,
  • het blijven sleutelen aan het proces zonder zichtbare verbetering,
  • 'deployment' user stories, of 'user acceptance testing' user stories.

Het probleem met het 'snel' repareren van deze symptomen is dat als je de eigenlijke oorzaak niet goed genoeg onderzoekt en deze niet wegneemt, het symptoom in een andere vorm terugkomt. Het komt dat terug maar in een andere vorm en herken je het niet zo snel meer.

Om te weten hoe de Kanban Methode hierbij kan helpen, duiken we een beetje dieper in Kanban.

Kanban Methode principes

De 4 principes van de Kanban Methode zijn:

  1. Neem het huidige proces als startpunt,
  2. Respecteer de huidige rollen en verantwoordelijkheden,
  3. Spreek met elkaar af geleidelijke verbeteringen na te streven,
  4. Moedig leiderschap aan op alle nivo's.

Juist vanwege de eerste 2 punten maakt dat de Kanban Methode uitstekend is toe te passen op Scrum teams: hun huidige manier van scrum doen, is het startpunt!

Met deze principes weten we wel dat het toe te passen is op scrum teams, maar nog niet 'hoe'.

Aan de slag met Scrumban

In de praktijk merk ik vooral dat:

  • het doel of purpose van het team niet helder is voor hen,
  • sterke focus op het 'eigen' werk,
  • een backlog die bestaat uit verschillende soorten werk.

Purpose. Een van de eerste dingen is dat om de focus op juiste dingen er weer in te brengen. Dit doe ik dan door samen met het team het purpose te achterhalen. Voor wie doen we het en wat zijn de behoeften van de klant? Hoe herkennen we dit? Maak het meetbaar. Dit maakt het makkelijker te bepalen hoe we het nu doen en of dit al voldoende is of juist niet.

Soorten werk. Waar komt het werk vandaan? Hoe komt het aan bij het team? Aan wie levert het team het op? Met wat voor regelmaat: ineens, met pieken, via een backlog, terugkerend werk, etc. Wat zijn de kwaliteitseisen en verwachtingen?

Focus op het geheel. Als de purpose helder is, breng ik met het team de keten waar ze onderdeel van uitmaken in kaart. Van begin tot in productie. Hier kun je ook prima afhankelijkheden op andere teams en partijen kwijt. Ook maakt dit transparant dat het doel is dingen in productie te krijgen.

Metrics. In ieder geval beginnen met het meten van 3 dingen:

  1. gemiddelde doorlooptijd per soort werk,
  2. hoe vaak komen verschillende doorlooptijden voor?
  3. hoeveelheid werk dat er in de keten tegelijk onderhanden is.

Met deze informatie bepaal je een eerste verbeteractie met het team waarbij je ook een link legt naar de purpose; je wilt dat deze er beter van wordt.

Hoe pak je het aan? Een stappenplan

Wat hiervoor beschreven is, zijn de eerste stappen in wat bij de Kanban Methode onder STATIK wordt verstaan. STATIK staat voor 'Systems Thinking Approach to Introducing Kanban'. Bij sommige stappen sta je wat langer of korter stil dan bij andere stappen.

De aanpak bestaat erin met het team de volgende stappen te doorlopen:

  1. Doel of dienst van het team: wat is de identiteit van het team?
  2. Onderzoek bronnen van ontevredenheid bij klanten, gebruikers en het team zelf,
  3. Analyseer de vraag van de klant en de mogelijkheden van het team,
  4. Wat voor werk komt er op het team af? Waar gaat het naar toe? Wat zijn de verwachtingen ten aanzien van kwaliteit en snelheid?
  5. Breng in kaart wat er daarnaar met dit werk gebeurt,
  6. Kijk naar de risicoprofielen van dit werk,
  7. Ontwerp het kanbansysteem (met bord)
  8. Doe het!

Met name de eerste 2 stappen zorgen ervoor dat de veranderingen altijd een verbetering van de dienst zullen zijn, of op z'n minst de verwachtingen hebben deze te verbeteren.


Tot nu toe heb ik een algemene aanpak beschreven die in de praktijk werkt. Voorbeelden hiervan zullen in komende blogs verder aan bod komen.

Monorepos for true CI

Arjan Molenaar

On the 15th and 16th of April CITCON Europe took place in Cluj-Napoca (Transylvania). CITCON is an open spaces conference. The agenda is made up by the people attending the conference. Because of this there are always a couple of nice takeaways.

This year Ivan Moore (@ivanrmoore) made a claim that you can not do CI without using monorepos. A monorepo is simply one repository where all source code ends up. This is contrary to a setup with (for example) Git source control where you have a single repository per module. The idea of having a single (big) repository with all code seems strange. After some thorough discussion the merits of monorepos were clear to me.

 Read more

Test Masters - Robot Challenge

Xavier Viuda

The Test Masters series is created to experience testing in a fun and new way. Play games, use robots, experience new tooling and techniques to make yourself a better tester! During the meetups we organize you can try out these new tools and techniques and engage in a friendly competition with your peers. In the first serie we will dive into the Robot Challenge.

The Challenge

The Robot Challenge is a mix of feature/software/hardware testing that will make the Testers think out of the box. The Testers will work together in teams to work out the features presented by the Product Owner. When all features are worked out the teams get the chance to test the features on the presented robot. The biggest challenge will be having working software but still seeing the hardware responding differently. How will the teams handle that?

 Read more

5 ways to organize Agile teams

Daniel Burm

Do you feel like your teams could be organized better? How to organize teams in an optimal way is a common question in Agile organizations. A question you should always discuss and answer together with the people in the actual teams.

This post provides you with an overview of 5 possibilities for organizing teams and the main factors to take into account. Your main considerations should be based on product complexity and maturity, as well responsibility, coordination efforts and sustainability. Depending on your specific context one will suit your situation better than the other, or maybe you will come to the conclusion you are so Agile you can leave the concept of team all together!

 Read more

The Ultimate Tester: Curiosity

Maaike Brinkhof

In 2014 Bill Sempf posted this Tweet:

His message caused a chain reaction of awesome responses from people thinking of all the edge cases in this scenario. Among the most hilarious responses were:

 You can read the rest of the responses here.

This funny example illustrates perfectly how testers think. We think out of the box and don’t assume that some functionality will work because the developer said so and wrote some unit tests. Sure, automation in testing and scripting has its place and use (as we will discover in the next blog in this series), but it seldom proves that the application works as intended as a whole. Automated scripts are usually following a path without feeding the path new data every time. This can give a false sense of security, “we’ve covered this path”, when inputs matter more to find lingering errors.  Read more