Agile / Product Management / Requirements / Requirements gathering / Software development

The Agile Dragon

Posted on:

When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.

Process Improvement / Software development

Why Incremental Delivery Is Good

Posted on:

Incremental delivery is a key component of most software projects today – it allows us to deliver the most valuable elements of a system first, which allows our customers to start getting benefit from the system earlier. As additional features are developed, and additional use cases are enabled, they are delivered to the customers, who get incremental value from those features. This can have a significant impact on ROI projections for a project – and can be the difference between getting the deal and losing it.

Requirements / Software requirements specification / Writing

Stop Wasting Your Time – Don’t Bother Writing Functional Specs

Posted on:

Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now – on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business