Evaluating your Agile project
It's possible to follow an Agile process to the letter without internalizing the value system that makes Agile development really work. To determine if your Agile projects is doing well with its Agile adoption and maturity you need to look at the properties of a successful Agile project and not the adherence to specific process points.
These seven properties of successful Agile development projects come from Alistair Cockburn's book Crystal Clear. To assess your project, look at each of the seven properties and grade yourself - "A" through "F." The result is your Agile report card. It's appropriate to grade your project on a regular basis as things will change and improve over time.
Grade a team engaged in the delivery of a project, not a company. The makeup of the team and the nature of the product you're constructing affect the project context. Different teams building different products will score differently on these seven properties.
1. Delivery Frequency 
Have you delivered running, tested, usable functionality to users at least twice in the last six months?
Software requirements are often speculative until they're actually validated through inspection and use. Value from software ultimately comes from that use. Score your project high if it delivers frequently.
2. Reflective Improvement
Did you get together within the last three months to discuss and improve your group’s working habits?
A process must be tuned to match context such as the skills of its participants, geographic distribution, and the demands of the product being created. As the project context changes, the process must adapt. Frequent use of project retrospectives, or reflection sessions, that are targeted at identifying process improvements are critical. Score your team high if your team regularly reflects on and changes its process.
3. Close Communication
Does it take you under 30 seconds to get your question to the attention of the person in your team who might have the answer? Do you overhear something relevant from a conversation among other team members every few days?
Taking a long time to get questions answered or solve problems slows the team down. Even worse, proceeding with misinformation may cause unneeded back-tracking. Collocated seating arrangements with the ability to make eye contact with your coworkers are ideal. Sitting close enough to easily get up and ask questions is good. If you can't see each other or easily talk, developing the habit of quickly instant messaging when a question arises can help. If questions are answered quickly within your team, score your team high.
4. Focus
Does everyone understand the goal and desired outcome of the delivered software? Does each person know what their top two priority items to work on are? Are they guaranteed at least two days in a row with two uninterrupted hours each day to work on them?
Knowing what you're doing and why, and having the time to do it is critical to success. In some organizations you may know what you should be doing, but have little understanding of the purpose of the software you're building and how it benefits its users. In some organizations interruptions dominate, or team members may be scheduled on multiple projects such that they have little time on any one project. Score your team high if you have clarity of purpose at the team level, the individual level and enough time to make progress.
5. Personal Safety
Can you give your boss bad news? Can people end long debates about each other's designs with friendly disagreement?
Ideally team members will have trust in each other's abilities, opinions, and judgment. The first step to building that trust is being able to speak freely without concern of political or social risk. Failure to deliver bad news out of fear keeps a project from recovering from setbacks and improving. Fear of sharing opinions can impede collaborative activities. Score your project high if members of your team can and do speak freely.
6. Easy Access to Experts
Does it take less than three days from when you have a question to when an expert answers it? ... a few hours?
To understand the context that helps you make decisions about product requirements you'll need access to subject matter experts, business stakeholders, and users of all types and experience levels. You'll need access to these people to validate prospective software designs, and finished software. Ideally access is easy and frequent. In the worst cases you won't get the information you need or be able to validate decisions until after delivery. Score your project high if you know who your experts are, and have easy and frequent access to them.
7. Strong Technical Environment
Do your developers use the configuration management system? Are your verification tests automated? Do you integrate the system at least twice per week?
To make additions and changes to software quickly requires a technical environment that minimizes risks associated with change. Configuration management, and frequent code integration followed by automated regression tests reduce risk of change. Score your project high if your team has strong technical tools and practices.
As a team sit down together and give your project a grade. Who knows - it may be your first test of personal safety, property number 5. Don't stop there. Take your lowest grade and discuss what you could do to improve things. (This is an example of reflective improvement - property number 2.) Put the changes your team came up with into place. Then, set a date to do this again in a month or so.
