After some feedback from the Done Fallacy post, I feel I need to explore done-ness a bit more. How we work and talk make up some very interesting distinctions. For example, let’s think about what the word “done” really means. It sounds simple, but the meaning changes over time. Let’s take a story, for starters. When we
At Agile Israel conference, I was recruited to a “Hit The Experts” panel on engineering practices. Ok, I didn’t put too much of a fight. Most of the questions were not of the engineering nature, though. One of the questions went like this: We’ve adapted the Spotify model, and now there’s no specialization, expectations from
Are your daily meetings effective? When you ask what people want from daily meetings, the answer is that they’d be short. Or Shorter. These answers usually come from people who suffer from long meetings and many other meetings in general. They want to just get back to their work. However, focusing on the length of
You’ve probably heard that a start-up’s chance of success is very low. There are many factors of why that happens. I want to illustrate this through the waterfall process that plagues many companies,. Waterfall, the root of all evil? Wasn’t it killed by agile? We’ll see. The process we’re talking about looks like this: Vision
Because having source control is a solution. Sometimes we get fixated on something that’s missing, and we’re sure that’s the problem. When we can control it, it really isn’t a “real” problem, because it’s easily solved. But in many cases, the solution is out of our control, and we think that if only we had
A while back, when I wore my product hat, I started referring to the product backlog as an option backlog. We had lots of ideas going in there, but they were basically stories that we didn’t commit to implementing. Instead, we could pick from our options based on our understanding of the market, our capabilities
Pawel’s post about Shu-Ha-Ri fallacy, came about the time I was reading the chapter about it in Lyssa Adkins’ book “Coaching Agile Teams”. And at that time I was thinking about learning and understanding. Coincidence? I think not. Shu-Ha-Ri is describes the progress in how we do practices: From doing, to understanding, to modifying them.
“We are uncovering better ways of developing software by doing it and helping others do it.” The first line of the agile manifesto talks about continuous learning. We want to improve, and therefore we try something, learn from it then move on. Anyone you ask will say they are encouraging learning, and that theirs is