Gojko Adzic

At the SPA 2010 conference today in London, Harvey Wheaton from Supermassive games talked about applying an agile process in a start-up games development studio. After leaving EA in 2008, he set up his own games development studio in an agile way, which is unusual for the games industry. The business grew very fast to 75 employees and established the process with only 4% staff turnover, which is again very unusual for the games industry. Review scores and critic ratings are crucial for success, so the teams producing games are always chasing an elusive concept of quality which is very hard to define, according to Wheaton, introducing an unusual constraint for agile development. Continue Reading »

David Evans and I facilitated a session on designing a killer agile test management tool last week at the UK Test Management Forum, with the goal of learning what are the biggest currently unsolved problems for agile teams in the area of testing at the moment. So for any tool vendors our there, here are the ideas.

We ran a variant of the Product Box game, described by Luke Hohmann in Innovation Games: Creating Breakthrough Products and Services, with five teams competing to design the best agile test management tool. They gave their products the following names: Silver Bullet, Agile Manager, Perfect 10, Nimble and FleXT. Continue Reading »

Long term maintenance cost is one of the biggest issues that teams face today when implementing agile acceptance testing. Tests that are just written and automated without any long term planning are guaranteed to cost you more than they are worth. But then again, a properly designed testing framework saves a lot of money, time and effort in the long run. It seems that the community is now going through the same learning cycle as we went through with unit tests, with people writing any crap code in unit tests at first, then learning that testing code maintenance hurts as much as it would hurt for normal code, and cleaning up their act. The ongoing research for my new book has helped me understand that, in the case of acceptance tests, the problem is much deeper. Continue Reading »

Speaking at the BBC QA Day today, Liz Keogh said that learning is often a constraint on software projects. Software projects deal with many risks and unknowns as they are mostly about new product development. Doing a project which took eight months again, with the same people and same technology, would take two months said Keogh, explaining that people would be much more efficient as they have already learned everything they need. One of the key ideas in lean software development is not to go faster than their main constraint and trying to help that constraint. Missing an opportunity to learn is waste, said Keogh, adding that focusing on learning as much as possible can help projects move much faster. Continue Reading »

While doing research for my new book, I was very surprised to find out that Jim Shore gave up on acceptance testing. I use his “describe-demonstrate-develop” process description all the time in my workshops, so I guess I better stop doing that. Jim Shore wrote:

My experience with Fit and other agile acceptance testing tools is that they cost more than they’re worth. There’s a lot of value in getting concrete examples from real customers and business experts; not so much value in using “natural language” tools like Fit and similar.

The two failure patterns that Shore describes in his post are falling back on testers to write everything and merging acceptance and integration tests. I’ve experienced both of these myself, and it seems that they are common in general. We discussed both during the top 10 ways to fail with acceptance testing openspace session at CITCON Europe last year. However, there are good ways to solve both problems. Continue Reading »