How to do agile when we only have 50 crap developers?

Why do people complaining that they can’t do agile development with 50 crap developers not see that the problem is in the second part of that statement, not the first? I got an e-mail last week that shows the point perfectly:

We discussed whether an agile approach is right, and I concluded that not everyone can work that way.

Quite true. I find it self-evident that not everyone can do software development, agile or any other way. That requires brains, knowledge, experience is a plus, and hopefully some talent as well. And of course, there is no generic approach that works in every context.

We think that an agile approach asks programmers to be much more engaged than when they’re just being served what to do

It’s hard for me to make a comparison to answer this. I’ve always tried to be very engaged in my own work and I expected the same from everyone else working with me, even before I ever did anything resembling agile. I’ve never seen a project where people were asked not to be engaged into what they need to do, but out of general principle I would refuse to participate in one.

If your programmers aren’t engaged and they get everything served to them, your problem is right there. It is not in a process, agile or non agile.

Which means the choice of people is very important

I completely agree. Once again, this isn’t particularly specific to agile software development approaches – or even software development at all. This is important for any craft. My former colleague Relja Jovic, who was the executive editor at PC World Yugoslavia when I worked there, used to say “From shit, you can only make a shit pie” whenever we were asked to get someone unqualified to write an article (“how hard can it be?”). That holds true for programming, testing, analysis, project management and anything else to do with delivering software. With crap people, you get crap output. Tough luck. Maybe hire people who know how to deliver software instead?

Anatomy of a good acceptance test

The long term benefits of agile acceptance testing come from live documentation – a description of the system functionality which is reliable, easily accessible and much easier to read and understand than the code. In order to be effective as live specification, acceptance tests have to be written in a way that enables others to pick them up months or even years later and easily understand what they do, why they are there and what they describe. Here are some simple heuristics that will help you measure and improve your tests to make them better as a live specification. Continue reading

Agile in a Start-up Games Development Studio

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

Acceptance tests are not a by-product of development

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

Are tools necessary for acceptance testing, or are they just evil?

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