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:

A 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.