Gojko Adzic

During ‘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 rises exponentially”. Divide and conquer is the traditional solution to this problem, used from the first software projects and still in use today. However, the lines along which the complexity is divided changed and there is still a debate on which way is the best. Continue Reading »

One of central agile programming ideas is to deliver frequently and get feedback early. To get the full benefits of this approach, it is not enough just to make sure that we deliver often and seek feedback — it is extremely important to plan our deliveries correctly as well. If the deliverables are not complete in the sense that they can really be used in production, then the feedback is not as relevant as we would like it to be.

Here is a situation I have seen a few times more than I would have wanted: the team and the clients split the whole project into several phases that will be shipped every few weeks; early deliverables mostly provide the plumbing for the later ones, and have only enough user-interfacing functions for the plumbing to be tested functionally. The clients set up and play with each new release. They dutifully give their feedback and participate in testing each time. When the whole thing comes together on the end, it turns out that the system still requires a lot of changes to solve the problem that it was intended for — the iterations and customer feedback failed to provide the directions. 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 »

Every 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, get more time to focus on new features. In reality, that is just one big lie, and a very dangerous one. Continue Reading »

From 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. Continue Reading »