I didn't knew of Evo before, I just bumped into it reading some stuff about post-agile project management... 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!

Team mood is very important, it's an indicator on how the project is going, a good mood is essential to exit from bad situations, a bad mood should be fixed as soon as possible. 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.

On the italian XP mailing list, Tommaso Torti asked an interesting question to the list few days ago. When do you define a team 'mature'? Translating myself, my reply was something like:

A mature team is a team that implements at its best the theories written on books, that makes concrete what's on paper in value for the client. It's cohesion and communication. A team that's mature is a team that hasn't nothing to do anymore, it's mature, can still improve? In my very personal opinion it's a death team, the mission is achieved, it's time to change, it's time to shuffle the cards. Roll in new people, change.

Some other interesting replies to the question: PierG wrote: A mature team is a team robust to change, wich means that it's able to change without crumbling the process. Francesco, being a strong XPer wrote: A mature team is a team that doesn't need a manager, a project leader, an architect or a designer in order to produce results. It's able in an autonomous way to increase its own productivity. Luca Minuduel quotes from the website of Joseph Pelrine: * Flexible and responsive to changing organisational conditions and wider environments.
* Able to work with pressure, uncertainty and disagreement.
* Able to be self-organising and self-regulating.
* Maximise the strengths and creativity of each team member.
* Satisfies both organisational and individual needs
and Marco: AEntre más reglas poker compares mejor. system in equilibrium naturally tends to resist to change and that's why we need to apply a force (questions/retrospectives/etc for people, splitting for stories, refactoring for code), because we need to take the system at the edge of chaos to facilitate the emergence of a new, spontaneous configuration. Definitely a nice conversation, and for you what's a mature team?

In the team we are used to be Agile, and especially what I call being Agile doing Agile stuff. Which means being not dogmatic: stop doing a practice when it does not give us enough value and starting it again when we feel that we are missing it. Not only: we also try always to introduce something new. Since the beginning of the project we had 2 swim lanes on the wall, one for actions  to do and one for actions done, we just added a third column, the keep doing actions, it's like having a star fish always there. The waste bin. Yeah, we are interested in what's going on with lean, so now there's a box on the wall, if someone in the team feels that is wasting (s)he can put a card there, we'll discuss it during the retrospective. As a reminder, the seven lean waste types:

1. Overproduction = Extra Features
2. Inventory = Requirements
3. Extra Processing Steps = Extra Steps
4. Motion = Finding Information
5. Defects = Defects Not Caught by Tests
6. Waiting = Waiting, Including Customers
7. Transportation = Handoffs

I always used a text file for my todo list, I never found something better than moving lines coping and pasting, nothing so easy and immediate. I've tried for a while tadalist  which is cool since it goes on the web, you can share it, it has an RSS interface, but the usability wasn't so great. Yesterday searching for a software that I've seen on the Gaz Mac I've found another one,  iGTD The guy says:

You are a busy person, aren't you? And there's an easy way to track all things that have to be done... and to get those things done! iGTD takes some concepts from Getting Things Done methodology and makes them easy to understand and use in your every day life. But it's definitely not limited to the GTD concept - you can really use it the way you want.

It's simply one of the best Mac Os apps I've ever seen, I try to list here what I love of it so far:

• Export to iCal: awesome
• Easy to use, simple, logical, keyboard shortcuts for everything
• Integration with Quick Silver: cool
• Widget, integration with almost all the apps
• It's free

Are you still reading this? Let's try it out!

Retrospectives are ok. But how many, how much retrospective we need? One every end of iteration? How long is your iteration? One week? Then maybe is too much. One at the end of the project? Then maybe is too late. As always in medio stat virtus or Lagom är bäst. How many then? I have the idea that in the beginning of every project there's more need for retrospectives, in the middle of the project the team is in a state of high productivity (should be at least!) that a retro is just a waste of time and in the end, to double check how the situation is progressing and for planning next actions, in order to delivery last stories without pain and then go live. Flexibility, PM/IM insight, experience and so on should drive the number, a fixed number is just not agile. 

Le quattro regole del bravo manager.

• Scegli le persone giuste
• Scegli per loro il giusto compito
• Motivale
• Aiuta il loro team ad essere affiatato

Il resto è solo regolare amministrazione. Chissà se al SIESAI hanno mai letto Tom DeMarco "The Deadline - A novel about project management"  o conoscono Webster Tompkins? ...No, credo proprio di no :-)

This is one of the greatest post I ever seen in a blog :-) Raible Designs | Tips for Productivity and Happiness at Work Tips for Productivity and Happiness at Work Every so often, I get asked what my strategy is for "getting things done". This morning, I had a short session of mass productivity, and on my ride into work, got inspired to jot down a few tips productivity tips. Keep in mind that I grew up in the back woods of Montana with no electricity and I'm mostly Irish.