There’s a lot of material and opinions about organisational change. It seems that –in our enthusiasm for efficiency, planning, “managing” change – we often overlook some critical questions. Not very good, right? What if we go back to basics? Here are 12 of questions that could lead to more effective action, but seldom get asked.
Do you know the coolest thing Europeans added to Judo? The belt system. Japanese are patient by nature, they either do or don’t. In fact they distinguish only the black belt, you either have it or are progressing towards it. Ok, so what are five distinct levels of Product Ownership that we can observe and what must change before we move on to the next level, all the way to the black belt?
It’s a common question. Mostly it’s answered using either Stacey’s complexity model, or Cynefin. What if we answer this question from product lifecycle perspective. When does Scrum work the best? When does Kanban work better? Roman Pichler answers this from the product perspective.
You are virtually certain to hear some good things and an equal number of bad things about SAFe. Like it or not. It does provide some value. But why the vehement insistence by many Agile consultants that SAFe is not Agile? (same applies to other ‘mythologies’). Many companies are using it. Are they very excited about it? Doesn’t look that way. Here’s a perspective on the good bits in SAFe, and not-so-good-ones also.
A team is not a group of people who work together. A team is a group of people who trust each other. Successful collaboration requires trust. It’s much harder to build trust when some of the team members work thousands (or hundreds) or miles apart. What becomes of the team work then? Here are 12 practical tips to help distributed teams.
Nowadays, it seems that it’s common for people to attempt to display their wisdom by sharing their opinions. How about a better way? Centuries ago it seemed popular for people to ask questions as a means of displaying how wise they were. The Socratic method is a perfect example of this. Here’s quick overview of how it applies to a developer, but the concept applies to all roles.
End-to-end tests can catch bugs that manifest across your entire system. But many times,, end-to-end tests are slower, more flaky, and more expensive to maintain than unit or integration tests. Why is this the case? And what to do about it? Have a look.