Evolutionary Project Management

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!

Track your team mood!

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.

Reviving JRake

The post about the need of a new build tool had many comments and reactions so I started, before coding something brand new, to search on the web for something to solve the current, well known build tools problems.

I found out that Gant is pretty cool but then I started to search for something using ruby, rake and java…

And I found that back in 2006 Martin Fowler and Mattew Foemmel were already talking and working on this…

So I’ve sent an email to Mattew since his svn repository wasn’t neither working, I’ve got the code of his jrake and I’ve started a project on Google code, the name, unfortunately is j-rake (another jrake project was already there).

I’ve just did the first check in, compacting the vendor folder on all the scripts. J-Rake in fact comes out with jruby, rake and all the libraries you need to compile and test your code.

The next small step will be to upgrade all the libraries to the latest version, then some more clean up and then writing more examples on how to write J-Rake tasks.

I’ve a very bad rake/ruby knowledge so any help/suggestion is more than welcome.

It’s time to write a better build tool

That’s what I’ve heard more than one time in the last months, half of my friends complain about maven, the other half is just almost happy with ant. The rubists are generally happy with rake, the biggest problems are on the java/.net world.

So I thought about branching ant and rewriting it in a slightly different way, using yaml instead of xml and having always only one option for any task parameter. I always hated and found difficult to remember how to do things in ant since there are always two or more good alternatives (like why there’s a dir and a file parameter option in the delete command? Isn’t a directory a file?).

So, I don’t think I’ll be able to allocate a lot of time to this, but I would love to hear something from you, ideas and comments.

In the last weeks I’ve started to write a shared mind map with Staffan Nöteberg on micro time boxing… Maybe we can do the same with this topic.

Ping me if you’re interested.