This year, nearly 1400 attendees contributed to the second largest Agile conference in Chicago, USA. Next year the Agile 2010 conference will be in Nashville.

I have used some time to do some reflection about the conference. I also got back to a more stable internet connection (the internet connection at the conference hotel was not that stable…), so now it is time to do some more thinking and writing.

Instead of writing about all the sessions I attended, I thought it would be more interesting to slice the whole conference in different areas combining the many different viewpoints into some kind of context. If you are interested in all the sessions, you can find the complete program with all the sessions at www.agile2009.com.

I have selected to view the conference from the following 5 slices:


For the following days, I will post a new slice. In that way, I will try to incrementally create a more complete view of the conference and try to put the value from the sessions into a context. At least from my point of view.

Stay tuned more to come.

By Mads Troels Hansen

At Agile 2009, I attended an interesting workshop on the problems of end-to-end testing. Here is the idea that I presented at the workshop:

I believe you need to have some end-to-end testing, because it helps you get fast feedback about end-to-end-related bugs. But we don't need to have a lot of those tests because then most of them test the same end-to-end-related stuff. The problem is that it is so easy to write those tests, especially for legacy code, so people end up having a lot of them. So a solution might be to put a limit on the amount of time that end-to-end testing is allowed to take. And of course we can let the build server enforce that limit by failing the build when the limit is exceeded. When a developer exceeds the limit, some of the end-to-end-tests must then be converted into isolated unit tests. When we only have a few end-to-end tests, neither their slowness nor their brittleness is such a big problem.

By Lars Thorup

Games is a big topic at Agile 2009. Not computer games, but participatory, experential learning games where the players learn about the dynamics of organizations and Agile software development. I've been to several great sessions where games played main role, e.g. The Bottleneck Game and Applying Systems Thinking for Organizations through Play.

My take on the popularity of experential learning games at the conference is that we've tried for some time with all the hard-hitting, rational arguments for why Agile is a better way of developing software but those arguments fall short with people that are deeply rooted in other ways of seeing the world. To be able to reach out to those people the Agile community needs ways to provide those people with experiences that will convince both intellectually and emotionally. Experiental learning games is a great way of doing that. And fun too.

By Thomas Blomseth

As previously reported here we are establishing a new kind of contract for developing software solutions, currently dubbed the "Collaborative Agile Contract". In short this contract introduces fairness to ensure that both risks and gains are shared between customer and supplier. This ensures incentives for both parties to reach the right solution as fast as possible.

On the front page of todays Wall Street Journal is an article 'Billable Hour' Under Attack. This article focus on the trend in relationships between clients and law firms to find better kinds of contract than "payed by the hour", exemplified with the following quote:

"Pfizer could have demanded a discount from firm's hourly rates, Ms. Schulman said, but she hopes for a shift to a system that encourages firms to work more collaboratively with Pfizer."

It seems that the collaborative agile contract might be useful also outside the software business.
agile kontrakter

By Lars Thorup

Kanban is the japanese word for signalling card, but a signal for what? In the 1950s a Japanese delegation including Sakichi Toyoda (founder of Toyota) and Taiichi Ohno (on of the masterminds behind the Toyota Production System) went to
the United States to observe how Ford was mass producing cars. They were not impressed. During a stop at an american supermarket they witnessed how items were automatically resupplied once sold. The beauty of this concept was its ability to ensure a sufficient number of items was available to customers, without having to bind too much cash in unneeded inventory.

Reading the InfoQ newsletter the other day, I found that "Kanban is the hottest buzz since the dawn of XP" (eXtreme Programming). It is really so? Kanban is great for limiting queues of items with a certain level of uniformity - but does software requirements fit that? We certainly have queues of work that needs to be controlled - and requirements certainly can be described in a somewhat uniform way. The question really is - before implementing a kanban system to limit work-in-process, do you know for a fact that this is your biggest issue? I look forward to see kanban systems implemented in software development organizations where highly varying task size, complexity and context is addressed effectively.

By Sune Gynthersen