I’m coming out of the closet today. No, not that closet. Another closet, the tabu closet in the Agile community. Yes, I was (and to a point still am) a control freak, traditional, command and control project manager. Yes, that’s right you read it correctly. Here’s why this is important: in 2003 when I first …
Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in …
Specialization in software development hurts our business! I’m not talking about the kind of specialization that leads to spend some more time in one area than in others. I’m talking about the specialization that leads us to have Database Administrators (DBA) or Database Designers (DBD) or Kernel programmers that don’t do anything else! Take the …
While reading a post and associated Twitter chatter between Karl Scotland and others I got to think that the world is not yet ready. For what? For flow. The idea that if you do one thing (to Done) first and then start working on another thing and get that to Done, you will be faster …
I’ve discussed this idea a few times with some friends, but I’ll concede that the ultimate argument for stopping to estimate altogether is still to come… In the meanwhile here is more food for thought. Rob Bowley argues why estimations are bad in software development. My favorite part of his presentation: [In a study discussed …
Thinking back to how we value our work, we must recognize that, in software, quantity is not value! The number of things we do in a sprint does not vary too much, we can consider it a Gaussian (assuming correct and consistent measurement) — or in Black Swan (TBS) parlance: velocity is a variable from …
