Joe Little: "The Nokia Test is in two parts.

First, are you doing Iterative Development?

• Iterations must be timeboxed to less than 4 weeks
  
• Software features must be tested and working at the end of each iteration
• The Iteration must start before specification is complete
  

• •You know who the product owner is
• •There is a product backlog prioritized by business value
• •The product backlog has estimates created by the team
• •The team generates burndown charts and knows their velocity
• •There are no project managers (or anyone else) disrupting the work of the team"

I would say the Nokia test is neccessary, but not sufficient, and add 3 more tests:

• Did the project start with an end date or with estimates?
• Is the team autonomous (whole team), or does it have external dependencies?
• Does the definition of 'tested and working' include ORTs, or just  ATs and UTs?
  

Without answers to those I think you won't always know whether you're doing Agile, Agilefall, or deadline driven development.

Why ask these questions?

 - Classic agile literature suggests you won't know the end date upfront. Now, of course you can do Agile within what the open source community called TBR (Time Based Releases), but you have to be conscious you're doing exactly that to organise the feature pipeline - otherwise the result will be feature coverage at the cost of quality, probably as a result of the business owners arguing out estimates that extened beyong an externally (pre) committed date.

- Whole Team imo is one the the most considerations of Agile, but it doesn't get much press. When it does it's interpreted as located the team together or Obeya, but really it's about the team being aving the facilities and support to proceed with their work. Systems designers will understand the autonomy principle, which says when a subsystem comes up it should have minimal external dependencies so it can to do work - a workflow version of cohesion. But we don't usually apply that thinking to software development itself. Modern manfacturing processes deal with autonomy/departmental tradeoffs using methods like Lean, TPS or Kanban, but software business are rarely that sophisticated, typically organising departments along cost centres instead of opportunity costs. All of which is a longwinded way of saying that Agile methods can't simply be siloed inside development teams and always be expected to work - non-autonomous agile teams will be required to do more upfront planning than is strictly neccessary to coordinate and secure access to resources and specialists.

- Operationally readiness if it matters at all, absolutely matters. It's not always enough to have gotten green bars and customer acceptances. The system itself must be operationally ready and hardedened. And then we need operational readiness tests to be sure. In fairness this isn't special concern to Agile, but we need to be careful not to confuse functional milestone or demonstrable releases with production readiness in all cases, expecially for web services, or any system with demanding quality properties (the 'ilities). The best way to deal with this is capture ORTs and operations usescases the way you capture ATs and user stories.