The Slack Power
It's now been a month I have been hired for coaching a team that develops a Web Application in a bank.
Apart from the XP methodology and the Java language, most things are new to me: a new domain (I come from the telecom field), a new kind of application (I am used to heavy client Java/Swing apps) and a team scattered geographically (2 members out of 5 live in India).
Surprisingly enough, I very soon noticed that these little shortcomings would not be the most important difficulty to deal with ; the team was invariably overwhelmed with urgent matters or interruptions, and thus had no way to get on top of the project for the upcoming year.
After 1 week of observation, I gathered the team to have a wide discussion about organisational stuff, XP and the Agile movement in general.
I first told them theoretically what the Agile movement is all about, the recurrent problems it attempts to resolve, then we reviewed the Agile Manifesto and some of the methodologies that inspires it. I then explained in more details XP (values, principles and practices), and what had proved to work well in my previous assignments. Afterwards, we identified together the weaknesses and bottlenecks of the team organisation, and what were the concrete actions that could address directly these.
This meeting took a complete afternoon, meaning of course that no task and almost no support had been accomplished by that time. However, everybody in the room perceived the powerful relevance of this activity: they were eager to participate in a debate around what team organisation could produce more value for our concrete project.
This kind of activity is really what makes a team alive: it enables adaptation, innovation and responsiveness. (I strongly suggest on this subject the excellent book "Slack" from Tom DeMarco)
We will certainly spread over the next iterations a few other subjects, like building a shared vision for the product and the internal design, optimising the relation with users to better understand their needs, readapting again the process for effectiveness, organising an open 360-degree feedback session for all team members, and so on.
Of course, the team should obviously not spend days and days in endless debates! The aim is to take advantage of the brain diversity and the mutual feedbacks to improve our performance and have more fun at it.
These slack times are more generally for brainstorming (think more thoroughly, share ideas, ...), organising (logistics...) and investing (learn about promising tools or languages, refactor the code to reflect the shared design vision, ...).
Trust me, this is worth the regular investment. Enjoy!
Apart from the XP methodology and the Java language, most things are new to me: a new domain (I come from the telecom field), a new kind of application (I am used to heavy client Java/Swing apps) and a team scattered geographically (2 members out of 5 live in India).
Surprisingly enough, I very soon noticed that these little shortcomings would not be the most important difficulty to deal with ; the team was invariably overwhelmed with urgent matters or interruptions, and thus had no way to get on top of the project for the upcoming year.
After 1 week of observation, I gathered the team to have a wide discussion about organisational stuff, XP and the Agile movement in general.
I first told them theoretically what the Agile movement is all about, the recurrent problems it attempts to resolve, then we reviewed the Agile Manifesto and some of the methodologies that inspires it. I then explained in more details XP (values, principles and practices), and what had proved to work well in my previous assignments. Afterwards, we identified together the weaknesses and bottlenecks of the team organisation, and what were the concrete actions that could address directly these.
This meeting took a complete afternoon, meaning of course that no task and almost no support had been accomplished by that time. However, everybody in the room perceived the powerful relevance of this activity: they were eager to participate in a debate around what team organisation could produce more value for our concrete project.
This kind of activity is really what makes a team alive: it enables adaptation, innovation and responsiveness. (I strongly suggest on this subject the excellent book "Slack" from Tom DeMarco)
We will certainly spread over the next iterations a few other subjects, like building a shared vision for the product and the internal design, optimising the relation with users to better understand their needs, readapting again the process for effectiveness, organising an open 360-degree feedback session for all team members, and so on.
Of course, the team should obviously not spend days and days in endless debates! The aim is to take advantage of the brain diversity and the mutual feedbacks to improve our performance and have more fun at it.
These slack times are more generally for brainstorming (think more thoroughly, share ideas, ...), organising (logistics...) and investing (learn about promising tools or languages, refactor the code to reflect the shared design vision, ...).
Trust me, this is worth the regular investment. Enjoy!
posted by Pascal at 10:24 AM
0 comments
links to this post
