The art of coaching is not as easy as it looks. One of the main reasons for this is that being a successful coach is not measured by what you do but by what is achieved.

I’ve discovered a few ‘patterns’ in my own coaching behavior that leed to on ‘working hard’ instead of ‘achieve results’. And I’ve found some alternatives for these behaviors that will help me to become a great coach.

I would not like to use the word ‘anti-patterns’. It’s better to speak about wolves in sheep’s clothes. Some amazing results can be achieved working like this. However, on the long term it will neither help the coach become any better, neither help the organization to live on without the coach.
Love the sheep, but be aware of the wolf !

What wolves am I talking about :

1. Do whatever is needed to make the change a success.
2. Do whatever is expected from the coach.
3. Focus on the biggest impediments.

A coach who manages to do all three above is a great coach, right ?
Read more →

This is the tenth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The tenth principle we discuss is called “Architecture emerging from Projects“.Read more →

There are many misunderstandings about Agile and what it is or is not.
I’ve met some people who were really convinced that ‘Agile’ and ‘Scrum’ are like synonyms. Or who think ‘Agile’ is a synonym for ‘flexible’.

Both are not true. If Agile would have just been about flexibility or responsiveness, I suppose they would have called it ‘The Manifesto of Responsiveness’ or something like that. However they didn’t so there must be more to it than just the Responsiveness.

Agile is a mindset. A set of principles to guide you in the choices you make.

Read more →

In my experience as a Scrum trainer and coach, I have seen too many Scrum teams that fail to do what Scrum was invented for: Inspect and Adapt.

Do the following statements describe the situation of your team?
– Little is done about problems discussed in Retrospectives.
– Sprint Reviews have no impact on what is build in subsequent sprints.

If so, you may be interested to read my article on the Scrum Alliance website: Effective Retrospectives & Reviews.

In our work with clients we often have discussions about the function of architecture and the role of architects. These discussion are largely due to fact that architecture does not visibly contribute to organizational goals and is perceived as a nuisance for projects. Many discussions originate from a lack of understanding of the role and place of architects in the organization. We have defined three goals of the architecture function in IT organizations: The Three C’s of Architecture. These are: Connection, Cohesion and Changeability. Taking these as the prime principles of architecture provides focus on what to do and how to position architecture in the organization.
Read more →

While recently fiddling with some more runtime generic type extraction for Deployit, I was caught out by some unexpected behaviour by the reflection API. A check of the Javadocs quickly revealed that I had once again been too hasty in relying on “common sense”. Still, the case seems sufficiently unintuitive to merit discussion.Read more →

Within an Agile project environment periodic demos are one of the main strongholds. Demos are good for the team and the customers. They set focus and make progress painfully transparent. Agile promotes demoing the teams results every iteration, so every 2-4 weeks, and from the first iteration on. In this article we will present 2 real life cases, and discuss some considerations one should take into account to prevent early demos to have a boomerang effect on the project. Early demos can set the customers expectations to unrealistic levels which will lead to frustration all around. Read more →

When running Selenium tests from JUnit it’s very useful to be able to capture screenshots when something fails. Especially when you run it in a Continuous Integration environment which you aren’t monitoring. A screenshot combined with the stacktrace makes identifying and fixing the error easier. When you combine this with a JUnit @Rule you can make it transparant and use it for every testcaseRead more →

What does it mean when a Scrum team “commits to a Sprint”? There is a subtlety in the English language that leads to misinterpretation and misuse of the verb “to commit”. I have seen too many cases where a team is held accountable (“bad team, bad!”) because they did not achieve their Sprint goal in some way. And it will be accompanied by the accusation: “…but you committed to the Sprint, didn’t you?”. As a coach, this is the moment I step in to explain what “to commit” really means, and that you want to fail every now and then: succeeding every time is a failure mode all of its own.
Read more →

Static calls, final classes, objects created in test code: there are few things some of the current mocking frameworks cannot handle. Using powerful approaches like bytecode instrumentation or custom class loaders, these libraries make code that was previously a ‘no go’ area amenable to unit testing. This, moreover, in an elegant and convenient manner that will feel familiar to developers used to ‘standard’ mocking frameworks.
The question is: does such power perhaps come with hidden dangers? Might it be possible that the ability to test more could actually result in less code quality?
Read more →