Automated UI Testing with React Native on iOS

React Native is a technology to develop mobile apps on iOS and Android that have a near-native feel, all from one codebase. It is a very promising technology, but the documentation on testing can use some more depth. There are some pointers in the docs but they leave you wanting more. In this blog post I will show you how to use XCUITest to record and run automated UI tests on iOS.
 Read more

Making Agile even more Awesome. By Nature.

Paul Takken

Watching the evening news and it should be no surprise the world around us is increasingly changing and is becoming too complex to fit in a system we as humankind still can control.  We have to learn and adapt much faster solving our epic challenges. The Agile Mindset and methodologies are an important mainstay here. Adding some principles from nature makes it even more awesome.

 Read more

Robot Framework and the keyword-driven approach to test automation - Part 2 of 3

Michael Hallik

In part 1 of our three-part post on the keyword-driven approach, we looked at the position of this approach within the history of test automation frameworks. We elaborated on the differences, similarities and interdependencies between the various types of test automation frameworks. This provided a first impression of the nature and advantages of the keyword-driven approach to test automation.

In this post, we will zoom in on the concept of a 'keyword'.

What are keywords? What is their purpose? And what are the advantages of utilizing keywords in your test automation projects? And are there any disadvantages or risks involved? Read more

FitNesse in your IDE

Arjan Molenaar

FitNesse has been around for a while. The tool has been created by Uncle Bob back in 2001. It’s centered around the idea of collaboration. Collaboration within a (software) engineering team and with your non-programmer stakeholders. FitNesse tries to achieve that by making it easy for the non-programmers to participate in the writing of specifications, examples and acceptance criteria. It can be launched as a wiki web server, which makes it accessible to basically everyone with a web browser.

 Read more

Nine Product Management lessons from the Dojo

Chris Lukassen
Are you kidding? a chance to add the Matrix to a blogpost?

Are you kidding? a chance to add the Matrix to a blogpost?

As I am gearing up for the belt exams next Saturday I couldn’t help to notice the similarities of what we learn in the dojo (it’s where the martial arts are taught) and how we should behave as Product Managers. Here are 9 lessons, straight from the Dojo, ready for your day job: Read more

Which Agile Organizational Model or Framework to use? Use them all!

Paul Takken

Many organizations are reinventing themselves as we speak.  One of the most difficult questions to answer is: which agile organizational model or framework do we use? SAFe? Holacracy? LeSS? Spotify?

Based on my experience on all these models, my answer is: just use as many agile models and frameworks you can get your hands on.  Not by choosing one of them specifically, but by experimenting with elements of all these models the agile way: Inspect, Learn and Adapt continuously.

For example, you could use Spotify’s tribe-structure, Holacracy’s consent- and role principles and SAFe’s Release Trains in your new agile organization. But most important: experiment towards your own “custom made” agile organizational building blocks.  And remember: taking on the Agile Mindset is 80% of the job, only 20% is implementing this agile "organization".

Probably the worst thing you can do is just copy-paste an existing model.  You will inherit the same rigid situation you just wanted to prevent by implementing a scaled, agile organizational model.

Finally, the main ingredient of this agile recipe is trust.  You have to trust your colleagues and this new born agile organization in being anti-fragile and self-correcting just right from the start.  These principles are the same as successful agile organizations you probably admire, depend on.

Hoe om te gaan met Start-ups

Daniel Burm

Dit is een vraag die regelmatig door mijn hoofd speelt. In ieder geval moeten we stoppen met het continu romantiseren van deze initiatieven en als corporate Nederland nou eens echt mee gaan spelen.

Maar hoe?

Grofweg zijn er twee strategieën als corporate: opkopen of zelf beter doen! Klinkt simpel, maar is toch best wel complex. Waarschijnlijk is de beste strategie om een mix te kiezen van beide, waarbij je maximaal je eigen corporate kracht gebruikt (ja, die heb je), en tegelijkertijd volledig de kracht van start-up innovatie kunt gebruiken.

Deze post verkent de mogelijkheden en je moet vooral verder lezen, als ook jij wilt weten hoe jij de digitalisering van de 21ste eeuw wilt overleven.

 Read more

Backlog ordering done right!

Pieter Rijken

Various methods exist for helping product owners to decide which backlog item to start first. That this pays off to do so (more or less) right has been shown in blogs of Maurits Rijk and Jeff Sutherland.

These approaches to ordering backlog items all assume that items once picked up by the team are finished according to the motto: 'Stop starting, start finishing'. An example of a well-known algorithm for ordering is Weighted Shortest Job First (WSJF).

For items that may be interrupted, this results not in the best scheduling possible. Items that usually are interrupted by other items include story map slices, (large) epics, themes, Marketable Features and possibly more.

In this blog I'll show what scheduling is more optimal and how it works.

 Read more

Demonstration of the Exactness of Little's Law

Pieter Rijken

Day 18

Little's Law is a powerful tool that relates the amount the work a team is doing and the average lead time of each work item. Basically there are two main applications involving either 1) the input rate of work entering the team, or 2) the throughput of work completed.

In previous posts (Applying Little's Law in agile gamesWhy Little's law works...always) I already explained that Little's Law is exact and hardly has any assumptions, other than work entering the team (or system).

This post demonstrates this by calculating Little Law at every project day while playing GetKanban.
 Read more

Achieve The Unthinkable using Hyper-Sprints

Paul Takken
2015-06-25 12:38:41 AMSTERDAM - Wereldkampioen sprint Dafne Schippers poseert naast de Nuna 7S van het Nuon Solar Team. De atlete neemt het in Olympisch Stadion op tegen het Nuon Solar Team, de wereldkampioen zonneracen. Het Nuon Solar Team doet dit ter voorbereiding op het verdedigen van de wereldtitel zonneracen half oktober in AustraliÎ. ANP REMKO DE WAAL auto dafne het neemt op schippers tegen zonne ORG XMIT: 33177940

2015-06-25 AMSTERDAM - Wereldkampioen sprint Dafne Schippers poseert naast de Nuna 7S van het Nuon Solar Team. De atlete neemt het in Olympisch Stadion op tegen het Nuon Solar Team, de wereldkampioen zonneracen. Projecten zoals Nuna en Forze worden door Hardware Scrum coaches van Xebia begeleid.

In my opinion, the best indicator how "agile" teams actually are, is their sprint length.  The theory says 2-4 weeks. To be honest, as an agile coach, this doesn’t feel agile all the time.

Like I wrote in one of my previous posts, in my opinion the ultimate form of agility is nature. Nature’s sprint length seems to vary from billions of years how the universe is created to a fraction of a second how matter is formed.

Of course, it’s nonsense stating we could end up in sprints of just a few nano-seconds.  But on the other hand, we see our society is speeding up dramatically. Where a service or product could take years before it went to market a couple of years ago, now it can be a matter of days, even hours.  Think about the development of disruptive apps and technology like Uber and 3D-printing.

In these disruptive examples a sprint length of 2 weeks can be a light year.  Even in Scrum we can be trapped in our patterns here. Why don’t we experiment with shorter sprint lengths?  All agile rituals are relative in time; during build parties and hackathons I often use sprints of only 30 or 60 minutes; 5 mins for planning, 45 mins for the sprint, 5 mins for the review/demo, 5 mins for the retrospective.  Combined with a fun party atmosphere and competition, this creates a hyper-productive environment.

Try some hyper sprinting next to your regular sprints. You’ll be surprised how ultra-productive and fun they are. For example, it enables your team to build a car in just an afternoon. Enjoy!