TDD/XP - sharing thoughts

[Srinivas Ramgopal]

Hi all,

We evaluated XP and TDD for 8 months with a new developer (with good previous experience in them) added to the team.
The team is a group of seasoned developers but new to agile development.

I thought I would share with you the team evaluation with the main intent to know your input based on your experiences with TDD.

The team evaluation was as follows:

1) TDD is difficult in case of AMDD and major spiking.

2) TDD must not be a rule to be followed by the team since
-not every one is comfortable with design with tests without a little bit of upfront design to start with at the least.
- lot of redundant tests (beacuse of design on the fly) that needs major refactoring.
- leads to interfaces to every class, though there would be only one class that implements the interface.

3)Pair programming - did not always help in terms of productivity, depending on the type of personalities that pair together (Especially when one of the developer mind set is to finish things and move on to a new task and other's being more laid back).

4) Tests/code with no documentation - class/method level documentation is needed to be maintained inspite of XP saying that documentation is not necessary as tests and code must be self explanatory.

5)running integration tests before checkin into version control tool - integration tests take about 5 - 10 minutes to run. Thus most of the developers want to run the integration tests during after business hours.

Basically most of the team members think that TDD/XP must not hinder their approaches and creativity based on the experience with software devlopement; instead they must be given a choice to choose depending on the situation.


My personal thought is that I would follow agile development by completely adopting the new mindset of agile devlopement since it proven to lead to a project's success.

But I guess though the TDD/XP books/coaches recommend the approaches, it is hard to follow them in their entirity in the practical world, given the different/strong views in a team.

Your thoughts are highly appreciated.

[Lasse Koskela]

Originally posted by Srinivas Ramgopal:
TDD is difficult in case of AMDD and major spiking.

Could you elaborate on why AMDD and spikes make TDD difficult?

Originally posted by Srinivas Ramgopal:
TDD must not be a rule to be followed by the team since not every one is comfortable with design with tests without a little bit of upfront design to start with at the least.

I don't know that TDD should prevent little bit of upfront design to start with. You need to know which direction to start walking. When you're on your way, you can read the road signs (tests) and adapt accordingly.

Originally posted by Srinivas Ramgopal:
TDD must not be a rule to be followed by the team since lot of redundant tests (beacuse of design on the fly) that needs major refactoring.

I'm not sure why is this a bad thing? The redundant tests are gone as you refactor, right? And if you don't refactor, you'll end up with an unmaintainable mess of test code regardless of whether they were written test-first or test-last.

Originally posted by Srinivas Ramgopal:
TDD must not be a rule to be followed by the team since leads to interfaces to every class, though there would be only one class that implements the interface.

Interesting. I haven't noticed this happening. Are you possibly writing interaction-based tests extensively using tools like EasyMock or jMock?

Originally posted by Srinivas Ramgopal:
Tests/code with no documentation - class/method level documentation is needed to be maintained inspite of XP saying that documentation is not necessary as tests and code must be self explanatory.

Note that XP does not say that documentation is not necessary. XP says that documentation should be written on a need-to-write basis. In other words, don't write documents because "that's what we do" but because "we (team) need it".

Originally posted by Srinivas Ramgopal:
But I guess though the TDD/XP books/coaches recommend the approaches, it is hard to follow them in their entirity in the practical world, given the different/strong views in a team.

It sure is hard to follow TDD or XP, especially if the rest of the team is barely lukewarm or even hostile towards the practice.

Regarding the notion of working in a "practical world", I'd claim that for most it's not a matter of being in a practical world--rather it's a matter of truly believing that the practice makes you more productive.

[Ilja Preuss]

Thanks for the interesting report. I will add my own thoughts, which will partly overlap with what Lasse already said...

Originally posted by Srinivas Ramgopal:
1) TDD is difficult in case of AMDD and major spiking.

As Lasse, I don't see why this would be true. But even if it is, the true question is, or so it seems to me, whether it's *worthwhile*. If it is, it being *difficult* just means that it takes us longer to learn and/or do it - not that we shouldn't do it.

-not every one is comfortable with design with tests without a little bit of upfront design to start with at the least.

First, TDD doesn't really preclude a little bit up front design. Ten minutes on the white board are actually quite common in the community, as far as I can tell.

Second, when we are not comfortable with a practice, that's often because we aren't (yet) good at it. One possible reaction is to therefore not do it, another to get good at it.

If we, as leaders, prefer people to try the latter, there are some things we can do to widen their comfort zone - things like providing slack, training, room for failure etc. pp.

- lot of redundant tests (beacuse of design on the fly) that needs major refactoring.

How comes?

One rule of the "design on the fly" part of TDD is that duplication (including redundancy) should be removed as early as you observe it. So if we have a lot of redundancy that seems to suggest that we need to learn to notice and remove it earlier.

- leads to interfaces to every class, though there would be only one class that implements the interface.

As Lasse indicated, this seems to suggest that you are doing a lot of interaction based testing. If it concerns you, you should probably look into doing more state based testing. See http://www.martinfowler.com/articles/mocksArentStubs.html

3)Pair programming - did not always help in terms of productivity, depending on the type of personalities that pair together (Especially when one of the developer mind set is to finish things and move on to a new task and other's being more laid back).

Pair Programming is a (mostly social) skill that needs to be learned. What did you try to resolve those conflicts?

4) Tests/code with no documentation - class/method level documentation is needed to be maintained inspite of XP saying that documentation is not necessary as tests and code must be self explanatory.

The rule is that every time you feel the need to write documentation, you should first try to express the same thing directly in the code. If you fail to do that, write the documentation.

Having said that, I have never seen code that couldn't be refactored in a way that class/method level documentation could be reduced to virtually zero. If you think you have found such code, it might be interesting to post an example to the community and see whether something comes up with an idea how to express the thought directly in the code.

5)running integration tests before checkin into version control tool - integration tests take about 5 - 10 minutes to run. Thus most of the developers want to run the integration tests during after business hours.

How often do those tests fail? How much time does it cost you to not find defects before the next day?

What have you tried to improve the performance of the tests?

Basically most of the team members think that TDD/XP must not hinder their approaches and creativity based on the experience with software devlopement; instead they must be given a choice to choose depending on the situation.

My personal thought is that I would follow agile development by completely adopting the new mindset of agile devlopement since it proven to lead to a project's success.

Well, the Agile mindset exactly *is* that the experience of your developers is more important than a process. But it also is that you gain experience by trying things, by reflecting about what worked and what didn't, and to work an the *root causes* for the things that didn't work.

With other words, an set of practices as provided by, for example, XP, is just a starting point for a team. The team is expected to give it a serious try, and to not abandon a practice before they are sure they did it the way it was supposed to be done. And *then* they are *required* to reflect on what works for them and what could work better, and to *adapt* their process to their current needs and insights.

Which begs the question: how and how often did your team reflect on how they are working?

But I guess though the TDD/XP books/coaches recommend the approaches, it is hard to follow them in their entirity in the practical world, given the different/strong views in a team.

Remember that XP is a description of what real, successful teams actually are observed doing in practice.

Having said that, it is also true that *change is hard*.

One of the reasons that change is hard is that people don't know whether they will like the new way of working, wether they even will be able to perform adequately using them.

Another reason is that most people aren't aware of the fact that the inevitable first phase of change is *chaos* - they therefore think that something is wrong when the change feels akward. Google for "satir change model" for more.

"Fearless Change" is a very good book on how to be an effective "change agent".

[Srinivas Ramgopal]

Thanks a lot for the prompt replies.

Originally posted by Ilja Preuss:
Could you elaborate on why AMDD and spikes make TDD difficult?

I guess this all comes down to the certain level of strong resistance shown by few developers aganist the agile approaches of the new developer/coach, which lead to the withdrawal of the coach from those developers. Thus some of those developers who worked on AMDD/spiking, did not get the actual feel of XP/TDD and thus found it hard to implement.

As Lasse indicated, this seems to suggest that you are doing a lot of interaction based testing. If it concerns you, you should probably look into doing more state based testing. See http://www.martinfowler.com/articles/mocksArentStubs.html

Yes, we are using mock objects which need interfaces.

This leads to another question - what is wrong with having interfaces even if there is only one class implementing it?

Pair Programming is a (mostly social) skill that needs to be learned. What did you try to resolve those conflicts?

Most of these conflicts are not reported as part of team dynamics but it does hinder the motivation especially for the developers who previously worked in goal oriented and highly motivated teams.

[Lasse Koskela]

Hi,

Originally posted by Srinivas Ramgopal:
I guess this all comes down to the certain level of strong resistance shown by few developers aganist the agile approaches of the new developer/coach, which lead to the withdrawal of the coach from those developers. Thus some of those developers who worked on AMDD/spiking, did not get the actual feel of XP/TDD and thus found it hard to implement.

I'm not 100% sure I get what you mean by "AMDD/spiking" and "XP/TDD". Are you saying that one half of the team tried to do agile modeling (AMDD) and implemented spikes while the other half of the team practiced XP but didn't do spikes nor model?

When you say "XP/TDD", which practices of XP are you referring to?

Sorry for flooding you with questions but I'm starting to get really curious about what's happening in your team.

Originally posted by Srinivas Ramgopal:
Yes, we are using mock objects which need interfaces.

Libraries such as jMock and EasyMock can also work with concrete classes with certain limitations (as in the class has to have a default constructor and must not be final).

Originally posted by Srinivas Ramgopal:
This leads to another question - what is wrong with having interfaces even if there is only one class implementing it?

There might be nothing wrong with that. You need to make the judgment case by case...

[Srinivas Ramgopal]

Originally posted by Lasse Koskela:

Are you saying that one half of the team tried to do agile modeling (AMDD) and implemented spikes while the other half of the team practiced XP but didn't do spikes nor model?

Yes.
The nature of the work/components that second set of developers worked on, did not need much of spiking or model and thus had no major issues with test driven approach.

Originally posted by Lasse Koskela:

When you say "XP/TDD", which practices of XP are you referring to?

All the 12 principles of XP!?

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:

The nature of the work/components that second set of developers worked on, did not need much of spiking or model and thus had no major issues with test driven approach.

So we are talking about *two* teams here?

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:
Yes, we are using mock objects which need interfaces.

Well, as I said, you might want to take a look at set based testing - it will greatly reduce the need for mocks. (Overuse of mocks is a common "beginner's disease", in my experience.)

This leads to another question - what is wrong with having interfaces even if there is only one class implementing it?

Probably not much, although I find it to be a little bit harder to navigate through the code when interfaces are present.

But if you are using mocks, you are already having at least two classes implementing the interface, of course.

Most of these conflicts are not reported as part of team dynamics but it does hinder the motivation especially for the developers who previously worked in goal oriented and highly motivated teams.

I'm sorry, I don't get the meaning of this sentence at all. Could you please try again? Thanks!

[Lasse Koskela]

Originally posted by Srinivas Ramgopal:
The nature of the work/components that second set of developers worked on, did not need much of spiking or model and thus had no major issues with test driven approach.

Ok. So you've got two teams and the other team felt they needed to model and do a spike. That clarifies the situation quite a bit.

What's still bothering me, though, is that I still don't see how the need for spikes or modeling can make TDD more difficult?

[Srinivas Ramgopal]

Originally posted by Ilja Preuss:


I'm sorry, I don't get the meaning of this sentence at all. Could you please try again? Thanks!

Long story short...I was trying to see the drawbacks of pairing up programmers in my team's scenario atleast - I realize that it might be better to pair the programmers when needed but not expect them to pair up continously for 8-10 hours a day. Thus there might not be any issues related to productivity etc.

Anyways, thank you all for your valuable input.

This posting helped me understand that it might be better to give the team some more time to read related books and trying out things before making another/final evaluation of the agile developement that is to be adopted by the team.

Thanks once again.

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:

I realize that it might be better to pair the programmers when needed but not expect them to pair up continously for 8-10 hours a day.

Programmers shouldn't "be paired" at all - they should fully decide for themselves when and with whom to pair.

On the other hand, it isn't fully intuitive when pairing pays back and when not, so you might want to encourage the programmers to experiment with pairing in situation where they initially don't expect a benefit from it. Note that they need slack to be able to do so.

As an aside, 8-10 hours a day don't really sound like a sustainable pace to me. Most people I know are most effective when they work 6-8 hours a day - when they work longer, they actually (have to) slow down.

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:
Well, as I said, you might want to take a look at set based testing - it will greatly reduce the need for mocks. (Overuse of mocks is a common "beginner's disease", in my experience.)

What's set based testing? I tried Googling it but couldn't find anything.

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

What's set based testing?

A typo. I meant state based testing...

[Srinivas Ramgopal]

I have one more question:

1) Pair programming: We could not rotate team members each day among different pairs. Instead we changed pairs after each iteration (each iteration is one month).

The ISSUE being the fear that whatever the paired programmers researched or thought about (especially if in analysis phase) might be lost.
In other words, we felt there needs to be a some amount of knowledge transfer each time a programmer is rotated among pairs; this demands allocation of time, which is hard to find due to the tight deadline for the iteration.

But with this approach, we could not achieve the 'team ownership' prinicple of XP? The code reviews by the entire team at the end of each iteration helped only to some extent.

How did you tackle the above ISSUE?


By the way, I read the revised version of http://www.martinfowler.com/articles/mocksArentStubs.html

The article is helpful and thought provocative enough!

Thanks.

[Frank Carver]

1) Pair programming: We could not rotate team members each day among different pairs. Instead we changed pairs after each iteration (each iteration is one month).

Yikes!

Do you really mean that the same two developers sat together for a month? That sounds like a recipe for frustration and boredom, and certainly explains why you are not seeing the benefits of shared code ownership and team understanding.

Whenever I have done pair programming it's been more like: spend at most an hour or two with another developer to work on one problem. Then when the task has been checked in, go off to either do some individual work, meetings, study or whatever for a short while, or pair with someone else on another problem.

It sounds as if your tasks may be too big to suit this sort of pair programming, and this may have coloured your TDD results, too. Both work best when the development cycle:

choose a task

choose a partner

write a test

make the test pass

refactor to remove duplication

if overall task not complete, go back to 3

check in changes

fits comfortably within a normal working day.

Many XP folks suggest you should aim to split tasks up so that several can be accomplished in a day.

Have you looked at ways to split down your larger features/tasks/stories into small, "bite-sized" tasks which can be done much more quickly. Choosing small, short tasks has another big payoff, too. If a solution does not work within an hour or so, throw it away. Leave it for another pair (which may include either of the original two, or not) to tackle a different way.

XP, and TDD in particular, have a "ratchet" approach to development. Lots of small tasks done, tested and checked in continually. Each checkin advances the project and represents one "click" of the ratchet. Even if something goes really wrong and you have to revert the whole codebase, you only loose a small amount of work. The larger the tasks get, the more risk there is if something goes on during a task or if something happens to one of the team.

Most managers I have dealt with have really liked this aspect of agile development. One of the biggest headaches for a project manager is worrying that weeks (or even months) of work will be spent and it still won't be any closer to "done".

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:


A typo. I meant state based testing...

Oh! It was a serious question from my side. I hadn't heard of responsibility driven testing until I heard if from you guys. So I figured set based testing was something new Thanks for clarifying.

[Srinivas Ramgopal]

Originally posted by Frank Carver:
[qb]
Have you looked at ways to split down your larger features/tasks/stories into small, "bite-sized" tasks which can be done much more quickly.

This is what I understood from your reply and hope to know from you if I am wrong:

It looks like pair programming fits in more during the design and implementation phase??

I still cannot visualize 'breaking the tasks' like analysis and exploring new tools/reading documentation into smaller ones so that programmers can be rotated many times each day.

Also is a pair always needed for the analysis and exploring phases or is it more a judgement call?

Since our team is making a transition to agile mind set, it had no doubt been chaotic some times.
The management does not want to impose anything, instead wants everyone to get a feel by trail and error before doing the final evaluation.

Now if the 'pairs being rotated' style is introduced, though I want to see it happening, this leads to initial chaos and adjustment.
In other words, since the team is a mix of contractors and permanent employees, contractors (especially) still tend to have a grip and not share much of the knowledge with the fear of loosing the job (which again is aganist agile developement which says knowledge needs to be shared).

Gosh, as I am thinking about the transition, I feel that this complete transition in the mind set takes a while!? ...but we have been in the transition phase for 8 months already???

Also sometimes, I think it is easy for a transition without strong views/resistance in a team!?

Originally posted by Frank Carver:
[qb]
One of the biggest headaches for a project manager is worrying that weeks (or even months) of work will be spent and it still won't be any closer to "done".

Did you mean that the managers tend to become more of micro managing due to this fear?

Also what are your thoughts about meeting an iteration's deadline? Does the deadline always have to be met in XP world?


Your thoughts are highly appreciated.

I think javaranch is one of the best forums, as input from you guys was always helpful for me and thought provoking!

Thanks in advance.

[Lasse Koskela]

Originally posted by Srinivas Ramgopal:
It looks like pair programming fits in more during the design and implementation phase?

Whatever you mean by the design "phase" and implementation "phase", pair programming fits in for those moments when you program. Working in pairs, however, fits in for a lot of other stuff, too

Originally posted by Srinivas Ramgopal:
Also what are your thoughts about meeting an iteration's deadline? Does the deadline always have to be met in XP world?

Whether a deadline "has to be met" according to a process doesn't affect the reality. If you meet the deadline then you meet the deadline and if you don't, you don't. What XP helps you with is to get better at knowing in advance whether you're going to make a deadline or not.

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:
1) Pair programming: We could not rotate team members each day among different pairs. Instead we changed pairs after each iteration (each iteration is one month).

My experience with pairing with the same partner longer than a week is that it drives me crazy.

And as an aside, the recommended iteration length for XP teams is one to two weeks, *especially* for teams new to XP. Four weeks simply don't give enough feedback for the necessary learning.

The ISSUE being the fear that whatever the paired programmers researched or thought about (especially if in analysis phase) might be lost.

Why would that be the case?

One issue I have with long pairing episodes is that the partners stop to inspire each other. A new partner brings the benefits of fresh, new thoughts.

In other words, we felt there needs to be a some amount of knowledge transfer each time a programmer is rotated among pairs; this demands allocation of time, which is hard to find due to the tight deadline for the iteration.

In my experience, having to explain the current state of the task to a new partner helps a lot in clearing your own thoughts and getting new ideas. The benefits can easily make up for the "lost" time.

I also agree that you might benefit from breaking down your work into smaller tasks. Our team has made very good experience with user stories that are not bigger than two to three developer days.

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:
It looks like pair programming fits in more during the design and implementation phase??

What exactly do you mean by "phase"? What does the typical timeline for a feature look like for your team?

In other words, since the team is a mix of contractors and permanent employees, contractors (especially) still tend to have a grip and not share much of the knowledge with the fear of loosing the job (which again is aganist agile developement which says knowledge needs to be shared).

Well, this seems like a problem you will need to tackle first. Developers who fear that they might loose their job for being effective team members are unlikely to be effective team member, no matter what methodology you use.

Would it be feasible to strive for a corporate culture in which those contractors would trust that their cooperation and collaboration is *valued* by the company, and that acting that way will *secure* their job?

Gosh, as I am thinking about the transition, I feel that this complete transition in the mind set takes a while!? ...but we have been in the transition phase for 8 months already???

Well, I don't think that the transition ever ends.

But it sounds to me like your team could benefit from some training. Or perhaps you could get the help from an experienced coach for some time...

Also sometimes, I think it is easy for a transition without strong views/resistance in a team!?

In my experience, there always is resistance, and it's never easy. Doubly so if you have noone on site who has experience with Agile.

Also what are your thoughts about meeting an iteration's deadline? Does the deadline always have to be met in XP world?

Well, the whole idea of timeboxing as it is used in Agile approaches is that the deadline always is met by definition. What remains open is the exact scope that it realized...

[Lasse Koskela]

Regarding pair programming and rotating pairs, you might be interested in listening to Arlo Belshee's interview on promiscuous pairing from Agile 2005.

[Srinivas Ramgopal]

Hi

Sorry for the delayed response.

I did listen to the interesting and thought provoking 'Arlo Belshee's interview on promiscuous pairing from Agile 2005'.

That lead to few more questions in general.

From my experience as consultant in different companies/teams, I found that no two teams/projects are alike.
Especially, the energy in team is tied to the nature of the job. If the project is not that complicated, naturally team members are mostly on laid back side. Especially in such projects, I do not see much benefit of introducing pair programming concept, as it leads to initial chaos and lot of adjustment especially when rotating pairs. In other words, this demands lot of change in an indiviudal's attitude itself(especially if that person had been working in a laid back work atmosphere for a lot of years).

In such team enviornments, why not follow all prinicples of XP EXCEPT Pair Programming; Instead of pair programming, why not have extensive code reviews now and then during each iteration???

Also, I have been reading books about motivating teams to be more self organized etc.
But in real world, each team is made of different and sometimes difficult attitudes and different work styles which makes it real difficult to bring in a desired amount of change.
I really wonder at times, if bringing in a coach ALWAYS makes a big difference especially when the management is willing to see the changes only in a given period of time, since a coach is usually expensive???

Your thoughts are highly appreciated.


Thanks in advance for your valuable time and interest.

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:
From my experience as consultant in different companies/teams, I found that no two teams/projects are alike.

Yes. In fact I'd say that no two iterations are alike.

That's why heartbeat retrospectives are such a good idea.

Especially, the energy in team is tied to the nature of the job. If the project is not that complicated, naturally team members are mostly on laid back side. Especially in such projects, I do not see much benefit of introducing pair programming concept, as it leads to initial chaos and lot of adjustment especially when rotating pairs. In other words, this demands lot of change in an indiviudal's attitude itself(especially if that person had been working in a laid back work atmosphere for a lot of years).

I'm not sure why being laid back should be a problem. Couldn't you introduce Pair Programming in a laid back way, too? And are you suggesting that those teams *never* should try new things?

In such team enviornments, why not follow all prinicples of XP EXCEPT Pair Programming; Instead of pair programming, why not have extensive code reviews now and then during each iteration???

Well, in my experience, pair programming is much more fun than code reviews. But in the end, the team needs to decide for itself how to work.

Also, I have been reading books about motivating teams to be more self organized etc.

Which books did you read? I'm always searching for new reading fodder...

But in real world, each team is made of different and sometimes difficult attitudes and different work styles which makes it real difficult to bring in a desired amount of change.

The trick is to make the team members *want* to change. It's not easy - but then, if it was, everyone would do it...

I really wonder at times, if bringing in a coach ALWAYS makes a big difference especially when the management is willing to see the changes only in a given period of time, since a coach is usually expensive???

I'm not sure I'm getting your point here. Care to elaborate?

[Frank Carver]

Srinivas Ramgopal: From my experience as consultant in different companies/teams, I found that no two teams/projects are alike.

Ilja Preuss: Yes. In fact I'd say that no two iterations are alike.

You might find this article interesting.

[Srinivas Ramgopal]

Originally posted by Ilja Preuss:


Which books did you read? I'm always searching for new reading fodder...

I read mostly John C. Maxwell's books. I still have to read 'Fearless Change' recommended by you long time ago.

Do you mind recommending any more good books that you liked!?

Originally posted by Ilja Preuss:


I'm not sure I'm getting your point here. Care to elaborate?

First of all, I am not sure what changes a coach can bring in general, thus please excuse me for my ignorance.

What I noticed in teams in so far is that, each developer has his/her own personal style of working -->

A. Some team members do not plan anything but would never miss the deadlines.
B. Some team members are more self organized, have more sense of urgency, goal oriented and try to be productive atleast 7 hours a day. They always try to finish things early rather than dragging the pending work till the deadline.
C. Some team members are extroverts and some are introverts.

I heard frustrations especially when developers, each from A and B are paired together.

Though their frustrations that one is fast or one is slow are correct from their perspective, from a third person's observation there seem not to be a problem in either case since both types still meet the deadlines!

So will a coach be able to solve these kind of frustrations and get a balanced improvement in motivation and self organization in the team members?
To me, how much ever the coach tries, it all depends on the team members effort to motivate themselves for a new change and for sure it takes time!?

Your thoughts are highly appreciated.

Thanks in advance for your valuable input and time.

Originally posted by Frank Carver:
You might find this article interesting.[/QB]

Thank you! I will read it.

[Ilja Preuss]

Originally posted by Srinivas Ramgopal:
I read mostly John C. Maxwell's books.

Thanks for the hint, now my wishlist is two books bigger again...

I still have to read 'Fearless Change' recommended by you long time ago.

Do so, you won't regret it!

Do you mind recommending any more good books that you liked!?

Sure! I will concentrate on "self-organizing teams" here...

"Arful Making" is an interesting book - it won't give you concrete practices to apply, but new metaphors for thinking about this kind of problem.

"Maverick!" and "The Seven Day Weekend" are about a whole (*big*) company that puts a huge emphasis on self-organization. I've only read the latter yet, but have heard that the former gets more concrete.

"The Five Dysfunctions of a Team" gives you good insights on what typically holds a working group from becoming a true team, "Overcoming the Five Dysfunctions of a Team" naturally delves deeper into what to do about it.

Effective, collaborative meetings are very important for bigger teams. The "Facilitator's Guide to Participatory Decision Making" has great insights on what is so hard about difficult meetings and gives some tools at hand to help you facilitate them. "Collaboration Explained" contains even more advice on how to prepare different kinds of meetings, how to facilitate them etc. pp. The two books complement each other quite well.

Last but not least, one of the most important tools for self-organizing teams are regular retrospectives. "Agile Retrospectives" is a great book on the topic.

First of all, I am not sure what changes a coach can bring in general, thus please excuse me for my ignorance.

In my opinion, a coach has two important functions:

- he knows how things should look like if they are going well, and can identify where problems are coming from. So if you, for example, experience problems when pair programming, he can observe what you are doing differently from teams that had success with the practice, and can suggest things to try to do differently.

- he is an experienced change agent, that is, he knows how to talk to people so that he gets heared, he knows how a change process works in general and can correct expectations and smoothen the process, and he knows how to give your team tools at hand to manage their own change process.

Besides that, the whole presence of a coach communicates that the change is important to the sponsor, and thereby increases focus.

[Jeanne Boyarsky]

Originally posted by Srinivas Ramgopal:
A. Some team members do not plan anything but would never miss the deadlines.
B. Some team members are more self organized, have more sense of urgency, goal oriented and try to be productive atleast 7 hours a day. They always try to finish things early rather than dragging the pending work till the deadline.

I think this is less of an issue with pairing when the tasks are short. When we pair, it is typically for a short task - a couple of hours at most. When the "deadline" is a few hours away, these two viewpoints look quite similar.

[Ilja Preuss]

As an aside, our most introvert developer is the strongest pair programming proponent.

[Frank Carver]

Ilja wrote: our most introvert developer is the strongest pair programming proponent.

I've noticed this, too.

I guess this might be because it takes more effort to interrupt someone else with a question than it does to ask while you are already in conversation. While pair programming you are already in a conversation, and it's much easier to both ask and answer all the little queries and puzzles which crop up during software development.

For generally introverted people, the psychological barrier to interrupting someone else is much higher, so the benefits of continuous conversation are more appealing.

[Srinivas Ramgopal]

Thank you for the recommended books.

Y'day, I saw a video clip of Kent Beck about 'Ease at work' which was highly thought provoking and self analysing for me.

http://video.google.com/videoplay?docid=7830246530742207581

Best regards.

[Ilja Preuss]

Great video! Thanks for the link!