As I started the above mentioned project, I discovered that the questions I proposed were not that helpful. The real problems become obvious very quickly as I watched the team do its sprint retrospective and sprint planning. Reacting to what I see is more important than doing an academic evaluation.
As I write this article, 8 people have voted on the poll. Not exactly the wisdom of crowds, but you can get an idea of what people consider important. Here are the top vote getters:
- Colocated: Is the team colocated? - 8
- Releases: Have you delivered running, tested, usable functionality to users at least twice in the last six months? - 7
- Continuous: Do you do continuous build / test / deploy? - 7
- Retrospective: Does you team conduct a retrospective after every iteration? - 7
- Testers: Do you have testers? - 6
- Bug DB: Do you have a bug database? - 6
- Access: Does it take less than three days from when you have a question to when an expert answers it? - 6
- Build: Can you build in a single step? - 6
- Talk: Does everyone talk to each other, constantly? - 6
- How many releases have you put out in the last 6 months? ( 0 or 1 is a problem)
- How much effort is required to build and test the software?
- Does fear play a role in deciding when to give the boss bad news?
Question for you, gentle reader: What are the symptoms and smells of bad software development and especially bad agile development?