Gojko Adzic

John Rae and James Shiell presented tips and tricks for hiring the right people for an agile team yesterday during their session titled “Building a successful agile team” at XPDay 08 yesterday. Their startup grew rapidly last year, and was almost constantly hiring. The traditional hiring techniques and practices did not work for them, as they wasted too much time and effort on finding and filtering out the right people. Continue Reading »

At the XpDay 08 conference today, I participated in a workshop on pair programming organised by Matt Wynne and Laura Plonka. The participants were spit into several groups, discussing various challenges for the adoption and implementation of pair programming. I was in a group which was given a task to come up with the answer of when pair programming is appropriate. Continue Reading »

Chris Ambler, European test manager for Microsoft games, spoke about how games companies are testing software during his keynote Testing games is not a game – it’s serious stuff at XPDay 2008 today in London. Ambler said that the game industry is from a technology perspective doing much more bleeding edge than traditional industries, so it faces bigger challenges. As examples, he cited instantaneous response times for players worldwide, worldwide concurrent releases in twenty or more languages and having to get it right in first release (“what goes on disk stays on disk”). Because of that, Ambler argued that games producers face much bigger technical challenges and their QA practices have to be more advanced than in other branches of the software industry. According to Ambler, the trends and practices that he sees in this field are applicable to more traditional software markets, such as finance, and can help people produce better software. Continue Reading »

Jeff 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 star images, Jeff Patton told a story of a failed agile project in his XpDay keynote “Embrace Uncertainty”. The project started off nicely, almost by the book, with customer involvement and stories split into iterations, based on what functionality is to be delivered in what release. After they got something delivered to play with, customers changed their minds (as they so often do) and new stories and features were introduced into the plan. After a few deliveries, the scope kept growing and growing instead of reducing. From the developer perspective everything worked as planned – customer was expanding the scope and developers are there to oblige, because that is the essence of agile practices. Spice Girl Mel B was used for the role of a developer writing user stories and losing all sight of the big picture (while “So tell me what you want, what you really really want” was playing in the background). For the customer, the thing simply did not work – iteration after iteration, they were not any closer to having the project done. Continue Reading »

Acceptance tests should reflect customer’s perception of when the job is done, so they must be defined by a customer or a business analyst. That still leaves us with a question who should translate that definition into FIT/FitNesse tables. There was an interesting discussion on this topic at the XPDay 2007 conference in London, during a workshop called “Working With Customers towards Shared Understanding”. Several participants noted that if developers are left to do that on their own, then tests turn out too technical and task-oriented. Acceptance tests are more effective if they are focused on larger activities and expressed in the business domain language. FitNesse allows customers and business analysts to write tests directly without involving developers, but this may be a step too far, as customers often forget about edge cases and focus only or general rules.

Antony Marcano, one of the maintainers of TestingReflections, spotted nicely that the conversation during test writing helps a lot to clarify the domain and enable developers to understand the problem better. If tests are written by customers on their own, then the value of this conversation is lost. So, ideally, a developer and a customer representative, or a business analyst, should write those tests together.