Gojko Adzic

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.

For the last couple of years, I’ve been working with mid-size and large UK bookmakers, trying to introduce agile development practices into those environments on several projects. Although for most of the readers of this blog using agile practices is no longer a question, agile development is fairly rare when it comes to databases, and all these systems were heavily database-centric. About a year ago, I finally found the right formula to do agile development on top of big legacy databases. I presented my experiences at XpDay 07 in London, on a session called “Fighting the monster - agile development on top of legacy databases”. This is the content from that presentation. Continue Reading »

If you are interested in how agile development works with databases, come to XPDay 7 in London on November 19th. I will be talking about the project that inspired me to create DbFit, and sharing my experiences on how to fight attitudes and technology to bring database development into an agile form.