Agile Wagile

At each of the last 3 companies I've been at, I've helped them implement an agile development process. At it's essence, it's always a good idea...people talk more, they collaborate and they are able to flex with the ever changing requirements of a software company. That's all good.

With every methodology (agile, scrum, XP, pick your poison) there are zealots, mantras and rules. "You must use story points, you must do pair programming, you won't be able to predict the end date because we're agile, every sprint must be prioritized, and the backlog too"...and this is where I start to disagree.

Believe me, when it comes to the "spirit" of an agile development process, I am 100% on board.  I believe that specs from the waterfall days are obselete, that you need to break work down into deliverable chunks, and you ALWAYS must prioritize the work. But there are some business realities that need to be taken into consideration...this is where agile breaks down.

Every software company has customers, board members and business realities. The idea that we'll "release early & often" is great in practice, but there needs to be MVP (a post for another time)...and the date is not just a whim. it's tied to business results. There is still a date.

So that's why I've started to call it Wagile in my mind...You need to think about the MVP, you need to think about when things are due, and frankly you need to be able to enable the whole company to support a release. "We'll release sometime" isn't good enough. So the one thing I'll take from waterfall is the date...and the ability to make sure that the rest of the organization is ready...