I am sorry to break this to you. Even if you’ve realised this before, this blog post is for you just the same.

You will never be able to look at situations any other way - both at work and elsewhere.

You will see it in movies, and find it in books.

Speaking of books, you will read other kinds of books. You will become an avid learner. You will wish you have been such a learner earlier in life.

Yes, it will change you.

It will start as a work only thing, most probably: Having a Scrum board, figuring out what a Burndown chart can offer, get the idea behind relative estimations.

And then it will start creeping in to other aspects.

Add a comment

Testers_program

Back in 2013 I published the following post, but since I know, no one actually read these links I’ve chosen to quote that post in full. Sadly enough I still get that question way to often to my liking. 

MUST TESTERS KNOW HOW TO PROGRAM? 

One of the most common question that arises when talking to testers in an Agile context is “Does testers have to possess programming skills in an agile team?” For a long time my answer to that was no, since testing includes a vast number of activities which doesn’t require programming skill there will always be room for testers who can't program.

Add a comment

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

Stem_Teams

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