Learn how to do Specification by Example
I’m speaking here:
- Agile Practitioners 2012, Tel Aviv, Israel, 30-31 January 2012
- Software Passion Summit, Göteborg, Sweden, March 19-20, 2012
- Scandinavian Developers conference, Göteborg, Sweden, April 17, 2012
- Dutch Testing Conference, Bussum, NL, 18 April
- Testing and Finance, London, 17 May 2012
project management Archive
-
How to divide and conquer software projects effectively
Posted on October 19, 2009 | 2 CommentsDuring ‘The one thing you need to know’ talk at the Agile Testing Days 09 in Berlin, Mary Poppendieck presented a summary of how software development tried to deal with complexity historically. Poppendieck started by quoting Fred Brooks, who wrote that “Complexity is the enemy in software, inherent complexity software... -
The waterfall trap for “agile” projects
Posted on December 4, 2007 | 11 CommentsJeff Patton from Thoughtworks held a very interesting session at XpDay last month in London, focusing on a common misconception that causes “agile” projects to fall into the same trap that the waterfall ones typically do. Incremental is not iterative Using a very interesting combination of pop music and rock... -
The Zero-Testing Time Bomb
Posted on October 23, 2007 | 1 CommentEvery now and then some ingenious project manager thinks of a way to deliver faster by negotiating to skip testing. At first glance, this looks like a win-win deal: customers get software faster or cheaper, as long as they “understand” that there will be problems. Developers, on the other hand,... -
Developers are from Magrathea, Customers are from Ursa Minor Beta
Posted on December 25, 2006 | No CommentsFrom the naïve view of an average enterprise software developer, the situation today is a bit insane - most customers will always choose more functionality and faster delivery over testing and documentation - not to mention GUI polishing. They will look you in the eye, tell you that they sincerely understand the software will have problems once it is live, and then come back furious when the software does not work. As if we were not all speaking the same language, somewhere the meaning of 'it will have problems' gets lost in translation. Or maybe it's not the definition of 'problems', but the definition of 'done', or maybe developers and customers really come from different planets...

