Dependencies. That’s what cause trouble. It’s difficult to have a project that does not have any dependencies — internal or external, upstream, or downstream — on projects, initiatives, vendors, tools, or functionalities. Here’s a simple tool to identify dependencies.
How far should you push yourself? Have you ever left the office feeling you’re terrible at your job? If the answer is no, are you really growing? Is it worse to solve the wrong problem or to build the wrong solution to the right problem? What would you do? How do you chose features (thus say no to lots of features)? Here are 5 key product ownership lessons.
When you mention Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. Is that really the case? Can it be done earlier? What can we learn from build-measure-learn that can help us get to a meaningful experiment quicker? Have a look.
Continuous Delivery is all about making small changes. Work flows more easily, planning is simpler, error detection is cheaper. How do you maintain a coherent design when each change is small? How to design incrementally? If we expect some of our design choices not to work, how do we tell? Here are some ideas.
IQ is not enough on its own. Well, it is if we are to work only on our own. But we work in teams. In organisations. With customers. Emotional intelligence is the critical ingredient which makes the equation complete. Is it just only on sociability, sensitivity, and likability that matter? Or are there more things to emotional intelligence than that? Read on.
User stories are great at capturing product functionality, things people can do with a digital product like searching, evaluating, and purchasing products online. What are some downsides of User Stories? What are the scenarios where it won’t really help if you write User Stories? Here are some thoughts.
“I once used a hammer and it didn’t work”. Therefore, people should never use hammers. Doesn’t really sound right. If we assume the hammer did what hammers normally do, then what might it mean “it didn’t work?” Most likely, they meant they did not achieve the result they expected or wanted when they used the hammer. We tried Scrum/Agile/Kanban/Pair Programming/etc. and it didn’t work. How to avoid this trap?