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?

The timeboxing technique well known in Italy as Pomodoro technique is going international. My friend Matteo Vaccari had a speech at the xp days Benelux 2007. Online slides are on slideshare.

The original paper from Francesco is also now translated in English.

I’ve tried the technique and wrote also the mobile timeboxing app. I found it useful and valuable with unskilled xpers but more a drag than a benefit on more experienced / high focus capable people. Interrupting can be really annoying.

I see a big value on the time is passing consciousness but instead of a fixed, mechanical time machine I prefer to have an event based boxing. The typical cycle write the test, write code, run the tests, commit is enough.

And you: what do you think? Give a feedback to the guys!

On wikipedia there’s an amazing page about learning, and I’m more than anything else interested in the Observational learning.

Learning is the acquisition and development of memories and behaviors, including skills, knowledge, understanding, values, and wisdom. It is the goal of education, and the product of experience.

Why Observational learning? Pairing in an XP team is the perfect environment for Observational learning.

Example can be a motivation for learning. Imitation of a role model is a natural mechanism for infants and children, when learning from experience. Child’s play is another method for learning by the example of other children, who naturally gain satisfaction by playing the role of teacher or mentor to a less-experienced child.

What’s the Example then? Talking about code it’s the code base.The code base is your friend, coding having a look on how solving the same problem has been already solved makes easier to solve it again, keeps the code base consistent and helps to find patterns, to tackle the technical debt, etc.Talking about Methologies, it works well as well. The Example it’s just the behaviour of the coach/mentor. It’s again very interesting on the page what are the required conditions

for a successful learning:

• Attention to the model

A person must first pay attention to a person engaging in a certain behavior (the model).

• Retention of details

Once attending to the observed behavior, the observer must be able to effectively remember what the model has done.

• Motor reproduction

The observer must be able to replicate the behavior being observed. For example, juggling cannot be effectively learned by observing a model juggler if the observer does not already have the ability to perform the component actions (throwing and catching a ball).

• Motivation and Opportunity

The observer must be motivated to carry out the action they have observed and remembered, and must have the opportunity to do so. For example, a suitably skilled person must want to replicate the behavior of a model juggler, and needs to have an appropriate number of items to juggle at hand.

What really works well in an XP team as well is the Informal way we teach and learn stuff and we the spread the knowledge across the team. The performance over time in an XP team is different from the one shown on the picture.

It will be an honor to speech after the key note of Tim Mackinnon at the AgileDay organized by Marco in Bologna, I’ll present how we went from amber to green in four weeks in our last project in London, presenting a speech that Pat and I were setting up for the Xpday in London, but we were fired off cos it was “just” a description of a perfectly aligned agile/XP project, they said(!).

It will be also cool to speech again about Domain Driven Design at the Javaday in Rome, with 700 expected attendees that’s now the biggest Java Gig in Italy, it will be the 3rd refactoring of the slides presented since this summer, more focus on mocking, testing and IOC as well, since in Turin I had a lot of questions about it.

Slides in English coming soon here, after the events.