It’s not so far from the agile I know (at least the agile I used so far)

Evo Principles SUMMARY:
1. Real results, of value to real stakeholders, will be delivered early and frequently.

2. The next Evo delivery step must be the one that delivers the most stakeholder value
possible at that time.

3. Evo steps deliver the specified requirements, evolutionarily.

4. We cannot know all the right requirements in advance, but we can discover them more
quickly by attempts to deliver real value to real stakeholders.

5. Evo is holistic systems engineering – all necessary aspects of the system must be
complete and correct – and delivered to a real stakeholder environment – it is not only
about programming – it is about customer satisfaction.

6. Evo projects will require an open architecture – because we are going to change
project ideas as often as we need to, in order to really deliver value to our stakeholders.

7. The Evo project team will focus their energy, as a team, towards success in the current
Evo step. They will succeed or fail in the current step, together. They will not waste
energy on downstream steps until they have mastered current steps successfully

8. Evo is about learning from hard experience, as fast as we can – what really works, and
what really delivers value. Evo is a discipline to make us confront our problems early –
but which allows us to progress quickly when we really provably have got it right.

9. Evo leads to early, and on-time, product delivery – both because of selected early
priority delivery, and because we learn to get things right early.

10. Evo should allow us to prove out new work processes, and get rid of bad ones early.

Full doc, with description of every single point here

Worth having a look to the website of the creators of the document above.

The only thing (marketing probably) I don’t really like is the sentence “Evo makes project failure structurally impossible!”

That’s structurally impossible!
Evo fails, Agile fails… Just slightly less than Waterfall!

I never tracked the mood in a team (I think I’ll in the future) and I reckon a graph like this:

Grab it from the Agile Vital Signs Dashboard file, from the good blog all about agile.

The end of spring/iteration retrospective could be the ideal moment to record the team mood.

What’s behind a good mood? Let’s try to make it happen on the next iteration!
What’s behind a bad mood? Let’s try to fix it creating some actions.