Often I hear colleagues or co-workers talk about Agile transitions and the impediments that certain scrum teams encounter. For instance, the team struggles with how to plan and execute the non-functional testing for the next sprint in the retrospective session (as part of the sprint review). Later in that same session, the team has a discussion how to cope with the fact that the business keeps changing the scope in the middle of the sprint. ‘How can we keep the scope fixed’ they wonder.

What intrigues me is that some of these colleagues/co-workers have a very theoretical view and approach these challenges almost as if they are out of the mud for too long. They write great literature and are experienced lecturers but when was the last time you were actually part of a scrum team (as an Agile coach at the minimum level of involvement). These colleagues have not been part of the vanguard of an agile, scrum or DevOps team at all. How committed does that make you to the actual engineers in the field, do you know their daily struggle, their real impediments as outlined in the first paragraph? Can you still identify with them, based on recent experience rather than theory?

This got me thinking because a lot of people nowadays seem to be adapting (or trying very hard to adapt) to a more healthy lifestyle. They feel they are too caught up in work and thus have lost the work – life balance, the sense of self in a way. Caught up in biological food, calorie- and step counting on different kinds of smart devices that are all part of the internet of things, and off course lot’s of fitness and/or running. In a way, they go back to basic to “find themselves” again and rediscover or redefine what that entails for them. Some of them are even strongman runners or mud masters, but are they also (or still) a mud master on a professional level?

Why not organize a mud master contest for IT professionals/colleagues? After all, a mud bath revitalizes the skin and kills dead cells, refreshing at times don’t you think? Going from books and theories to the actual playground makes one realize what that is and what that means once again. It refreshes the memory and revitalizes the view about things, you can do a firm reality check too. Look objectively at what has changed and how that impacts your approach in practice in the future. Change your reality and theory accordingly is my advice.Part of the, let’s call it “IT-mud master challenge” would be an annual mud bath of at least a month. The winner will be the person with the most hands-on experience kaizen, continuous improvement that is.


Becoming or staying a mud master can definitely aid in refreshing your approach towards different things.
This brings me to the conclusion that if you want to realize a change, it may actually require you to get your hands dirty.
So I invite everybody to keep muddling! Metaphorically speaking that is.


Posted in: DevOps, Human Behaviour, Human Interaction Testing, Internet of Things, Quality Assurance, Scrum      
Comments: 0
Tags: , , , ,



Work Agile

turkey thanksgivingBy now you undoubtedly heard of the whole Agile trend or working in Scrum teams. In my opinion a lot of companies try to evolve into a company with an Agile mindset, an Agile way of work, and most of them choose to implement Agile by working in scrum teams.

The thing I find interesting is that the start of this transformation, or evolution if you will, comes from the management of these organizations. Somewhere in an ivory tower where the management resides the decision is made to “work Agile”. You and I both know that management have no idea what this is, means or implicates.

Simple example: various studies show that anywhere between 20 and 30% of the “workers” are unsuited for working in an agile environment. Thus they will not develop, let alone adapt, the Agile mindset. Is management prepared to lay-off that amount of people, and far more important, is the company ready for such a shake-up?

The contradiction is beautiful in a way. Management is top-down saying “We must do Agile, we are going to work in scrum teams tomorrow” while scrum (among other Agile methods) tells us that up to sometimes 3 or 4 management layers are no longer needed when truly adapting this way of work, or living even. Project managers, (some) test managers , team managers, deployment coordinators, release coordinators, department managers……the list goes on…..are all redundant and thus waste.

Off course, ignorance is bliss, until the hammer drops. ‘Wait a minute, does scrum mean I am going to lose my job? My well-earned, respected management job’.
At this time they begin to frustrate the transformation, sabotage the evolution if you like. If they succeed at doing so, Agile (or scrum for that matter) will fail and they will point and say: ‘see, I told you so’ or since they are management, they will say: ‘I informed you thusly’

So at the tipping point of knowing what Agile is and understanding Scrum (knowledge they should have had in the first place) they become the turkey giving advice about what to eat on Thanksgiving……guess what that’s NOT going to be.

Bon appetite!


Posted in: Application Lifecycle Management, communication, Digital strategy, IT strategy, Research, Scrum, test data management, Testing and innovation, Transformation      
Comments: 0
Tags: , , ,



As the world around us keeps spinning, every spin brings change, some small, some disruptive, some life changing. Let’s say the company you work for decides to make a transition to an Agile way of work, this will add more direct value to the product and will increase time to market for that product or increment. This will have a big impact on the people working at that company.

In this blog I want to emphasize on the impact on Human Resource, traditionally called, HR.

HR has a key role to the company’s transition to Agile. For instance to create open, transparent workspaces, no booths or small offices for two, no time to bring out the big coffee table for developers or software engineers as you like.

I guess value by design in this context can be taken literally, design the office space for maximum value. Human Value that is. Not literally, but more in context of skills is that the developer is empowered to make decisions. The team is trusted with certain considerations, this is opposite to the command and control atmosphere of the zombie companies that haven’t adopted Agile yet.
An Agile environment where people are not referred to as resources but rather as relations is another example.

So why not call the HR department Human Value (department)?

It’s not only about the value of the individual developer, it’s also the recruitment department, they have to make “Agile profiles” and recruit people with an Agile mindset. This is one of the reasons why a shift to Agile can never happen overnight, sometimes it even takes an entire generation to retire, so realize this takes time, among other things of course.

Of course just changing the name of HR or redecorating the office place is not going to get it done. The Human Value Department will have to support a bottom-up approach in which employees decide on their competence, so no budget-driven top-down approach, that belongs to the zombie companies you and I see all around us, problem is they don’t know that yet, I will come back to this in one of the following blogs around Value by Design.

Value by Design through a Human Value department that builds products around motivated people in self-organized teams. Empowered, trusted developers that thrive as an organic team, committed to the sprint goal: create value by design!

This blog is part of the Value by Design concept that I work on with SogetiLabs co-fellow Ben Visser, more to come in the upcoming weeks and months. Stay tuned!

Connect with me on LinkedIN



Posted in: Agile, Developers, Digital strategy, Human Behaviour, Human Interaction Testing, Human Resources, Innovation, IT strategy, Research, Software Development, SogetiLabs, Testing and innovation, Transformation, Transitioning, User Experience, User Interface, Wearable technology      
Comments: 0
Tags: , , , , , , , ,