As I already said in previously post, it was a nice try of Aigle in ENovation.

Although we can’t say it succeeded, but definity not failed. When reviewing what happened, what I learned, there are some experiences can be shared.

<p style="color:green">Pains</p>

Distributed Agile Teams

The worst experience is distributed developing teams which even not sharing same developing enviroments. Put aside the network and timezone problems, it’s still quite difficult to cooperate when stories interfere with each other.

Time loosing is not a small issue. It’s not just make team missing release, but also destroy the confidance. When everyone accept frankly the mission for improving efficiency is impossbile, the project is doomed.

Blaming Game

As the developing team is distributed, in some project, we were sorry to see work became a blaming game. Email then becomes not just a communication tool, but hatred bullets flying every where.

To trust some one you see everyday still a huge challenge, not to mentions some body you never familiar with. The result is imaginable.

No Professional Customer

We don’t have real customer join developing, but we do have Product Owner that plays customer’s work. But when PO not sitting in the same office with you, and can’t deliver quality documents in time, that slows down everything.

People Problems

To do job by a Team requires people to think and active of one mind. To do a successful Agile project, people’s intentions and ability are vital important.

I do spend a lot of effort trying to IMPROVE people, to make them satisfied team requirements. But failed most of the time.

People can’t be changed unless he/she wants to. Even he/she wish to that’s not one day’s work.

<p style="color:green">Gains</p>

Avoid Distributed Team

The best is never setup a project with distributed developing teams in different places. At least put developers together.

If there’s no choice, then you have to accpet you can’t be that AGILE. You have to spent much more time concerns communication and people’s status.

And documents becomes vital important! If the team can’t agree on that, it’s better give up at the beginning.

Small Team is Beautiful but People matters

Our practise also show small team has the best efficiency. But how you build that team do have secrets.

People willing to communicate is the precondition, but you can’t just consider coding ablity for everyone. In Agile process, there’s quite a lot of work not refer to coding at all, choose suitable people to drive specific aspect is the best.

Trainning is Essential

Tranning can help everyone understand more and keep up with each other, but you can’t hope make all understand just by a Trainning.

The reality is you have to train day by day, story by story, meeting by meeting.

Non-attenction for developer’s time spend

Although we do care about how much time spent on one story or one sprint, but you can never expect people fill in real time for you. Even you annuouced, we just have a look, no side－effect, will they believe you ?

Unless you are working alone for you own’s project, otherwise you can never get realistic data. Then how can we do to improvig efficiency?

Our practise is keeping close eye watched when efficiency sucks. Make sure estimation is done by team together and everyone understand each other’s idea and how much time is esimated by team. Let programmer’s pride supervise. After that, you have to trust people and try to remove all the obstacles before them.

Then blessing :) ofcouse if people’s adjustment is needed, never hesitate to do it.

Management’s Supporting

Surpporting not just means say it superficially, but decided by whether they do accept the decision made by team even it seems not good.

Once team is unleashed and able to try their ideas, they will become more and more positive and active.

<p style="color:green">At Last</p>

At last, it’s People makes project success not Agile Process.