When I’m joining new teams at clients it often becomes clear that the added value of refinements is not always seen. Team members complain that hours are wasted. The refinement sessions shouldn’t be long draining meetings with endless discussions. Refinements should instead provide a clear added value in the form of requirements that the whole team can work with to deliver added value. How do you shape your refinements in a way that they add value? Read on to see how BDD / Specification by Example can help you!

Read more →

I remember when the Product Owner stepped into our room with a new user story. He asked if we could make a minor change to one of our web pages. What he did not know is that nobody understood the code, nor the ancient documentation that was written for this webpage.  After running a few tests we even discovered that half of the features did not even work. We made a proposition: we implement this user story if we get three extra weeks to rebuild this page and rewrite the documentation. Luckily our awesome Product Owner understood our situation and we managed to get these extra weeks.

Read more →

I was 21. I just graduated from MBO college, it was night and I was strolling around town with a couple of friends. We just celebrated our graduation and did not want to go home. After a few hours, we got lost and arrived at this big haunted mansion. We saw a sleek figure standing at the entrance. He was looking directly at us, and asked: “Would you like a tour?”, inviting us in. For a second we looked at each other and then we succumbed to our curiosity, following the man into the mansion. With no idea what could happen next.

Throughout my life, I have done several stupid things like the example above. And I knew these were not my brightest moments, but my curiosity simply took over. I wanted to explore or discover something (and I also love to get a good story out of it).

But whether you love taking risks and doing stupid things, or you prefer to dive into books and study in a safe zone, we all have the same internal drive to learn, to grow and to become the best version of ourselves. This is called ‘mastery’ and it is the subject of this blog post.

Read more →

What are we doing? Why are we implementing this sorry excuse of a user story? What will this user story achieve in the bigger picture? Is there even a bigger picture?

I have attended several refinements as a coach, where I was waiting for those questions to arise… Unfortunately, they are rarely asked. Usually, because there is no easy answer to these questions. The difficult truth is that we all like to please others, so we would rather stick our heads in the sand and hope everything will turn out fine.

And that is exactly what we get. Instead of having an awesome job, doing cool stuff and making a difference: our job will be just that, it will be fine. And it could be so much better, with some practises I will share in this blog.Read more →

Often the team or somebody in the role of product owner gets either the question ‘When will it be finished?’ or ‘What will be finished at <some future date>?’ and some forecasting is necessary to answer the question.

This blog shows an alternative way of forecasting that is based on empirical data and skips estimation altogether. In a follow-up blog I will address the ordening of the backlog of items.

Read more →

This is my fifth and last part of my blog series about Being an Agile Officer

In the previous parts I showed how Security Officers can align with the Agile process and let security become a standard considered quality attribute again. Unfortunately many teams not only need to be made aware of security requirements, but also need technical advise and guidance in designing and implementing them. As an Agile Security Officer you therefor need not only to act as a Stakeholder, but also as a Domain Expert for Security.

Read more →

This is the fourth part of my ‘Being an Agile Security Officer series’. In this blog post I will go deeper into the details of how user stories are created and what role security stakeholders should play in that.

Read more →

The other day a discussion moved towards the -changing- role of Business Analysts in an Agile environment. I referred to the Business Analysis Manifesto. Created by and for Business Analysts, but never published. I realized I could share it with ‘the world’ and wrap it in blog-paper.

Read more →

There is no greater waste than building something extremely efficient, well architectured (is that a word?), with high quality that nobody wants.

Yet we see it all the time. We have the Agile manifesto and Scrum probably to thank for that (the seeing bit.) “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. It’s the valuable bit that is embodied by the Product Owner in Scrum, or “the value maximiser”.

Lean Startup has taught us that we suffer from cognitive bias and simply assume we know what customers want, and therefor should treat our requirements as assumptions. Get out of the building and ask our customers! We all know that Henry Ford would disagree. But could both be right.

Read more →

Let’s imagine it’s the year 2025 and we peek inside an average IT company to take a look at the software development teams working there: what are the chances that there will still be a person who is a tester in each of these teams? Some of you will say: “of course they’ll be gone, everybody will be a developer by then”, while some will hope that the role of the tester will still exist. What would that role look like, then?

If we go back to the current day and age, we can already see a trend that’s been going on in a lot of companies that will give us a peak in a not so pleasant future.Read more →