One of the worst nightmares of a plant manager or a supermarket owner is the silence that accompanies a complete halt at the production line or at the checkouts. Complete halt means nothing progressing, which means no revenue, which means no money. Which means big problems now.

At Toyota, however, the philosophy is quite different. Problems happen all the time, and the longer we delay fixing them, the bigger they become. So the worst thing is to let problems ferment and become big problems later.

Add a comment


So, you’ve long ago embraced on your agile journey, you enact Scrum so elegantly that new recruits get on boarded in a matter of days, and you are well on your way to excel in engineering practices. And now you want the Holy Grail of Scrum: that each team will be able to take any feature, and complete it end to end. Ahhhh, on to Scrum perfection!

Or is it?

If that’s your aim, think again. In particular if you're organisation is very large. Say larger than 5-10 teams.

Add a comment

When learning about the SAFe methodology one might come to a conclusion that in order to achieve agility in large organizations there is a need to add roles, artifacts, processes, etc. Recently the SAFe institute even published the “SAFe essentials” trying to answer the question “What is the minimum subset of practices beyond which SAFe isn't safe?” and feel free to read it yourself and judge. I would say that the list is far from being minimal.

The common reasoning behind this approach is that the bigger the organization is, the more complex it becomes to effectively align the entire organization towards a shared goal.

Add a comment

Writing tests for legacy code may seem risky, even daunting: will we break our code? Will we need to rewrite extensive parts of our code in order to test it? Not many know that by following fairly simple practices we can start unit-testing our codebase with minimal risks. Here are two examples of how to overcome a well known obstacle - the “initializer blocks”.

Initializer blocks

Consider the following example:

Add a comment

I’ve had this thought for a while now of demonstrating how can people and organizations deal with everyday situations and present an analysis of them based on my personal views, while some might find this judgmental, others may find this an interesting reflection of their behavior and explore alternatives.

For the sake of the following scenarios I will assume that we are discussing a Large Scale Scrum product, 6 feature teams, one product owner (That is you!)

Add a comment

How can we help?

multiply one and three and get

Register to get notified about new blog posts