I recently read a brilliant article on the myth that Scrum is faster and cheaper than traditional development. I highly recommend reading it, and no, I’m not affiliated with the writer or Scrum.org!
The article articulated something I feel is poorly understood. Following the ceremonies, roles and artifacts of Scrum is not a faster way of developing software. In fact, I am fairly certain that if you had two similar teams, gave them the same large specification and had one team develop to that specification using two week increments and the other using a waterfall approach, the second team would finish earlier. Why? (I’ll explain the underlining below) Continue reading
Over the last few posts, I’ve discussed how the MVP method is very frequently referenced but rarely used, and there is a good reason for this. It’s not easy. There are many tall obstacles to applying it successfully. My previous post described how the organisational structure can challenge the process. This post is about an obstacle that may be easier to change, but sometimes more difficult to recognise: You.
You want to be a visionary
The big buzzword these days seems to be MVP, meaning Minimum Viable Product. It’s a reference to the approach to product development described by Eric Ries in his book The Lean Startup. However, while I’ve been hearing and seeing the term MVP a lot, I’ve almost never seen anyone executing the process that Eric Ries describes.
More often than not, what is called MVP is what I call MPP, or Maximum Possible Product. The word Possible has a double meaning: Continue reading