By applying those lessons, you can make your team more effective. It doesn't matter if you do Rails, Python or Java. The team techniques and problems remain the same.

I'm sure, you've noticed that it's not as easy to switch the team habits to the new ones.

Why do the people forget to work on small stories only?
Why it's so hard to introduce async standups instead of the sync, voice-based ones, that everyone loves?
Why are people not reviewing each other code changes?

The thing is, it's hard to eliminate habits (ask any smoker!).

There are two rules for introducing new habits:

Know what's your goal, what are the new habits to introduce. Luckily, you know the techniques we suggested in our email course and in our book.

It's easier to change existing habits than to eliminate them

The second point is crucial (and that's the secret!):Habits are based on hooks (think Aspect Oriented Programming, but in real life).

What are the current habits in your team? Is it that everyone prepares at 9.50am, because at 10am the standup starts? Don't try to eliminate it (yet), just turn it into something different. Do the text-based standup instead, even if it's at the same time with everybody. Just share your statuses in the communication tools or in the Google Doc or Hackpad. That's a smaller step and probably more likely to be adopted. Heck, you can even do it, while all are on Skype, if you prefer even smaller steps.

There's a cool concept of Tiny Habits, that can help your team change more easily. This concept is directed towards single people and their habits, but the mechanisms stay the same for the team - try it and apply it for your team (it's free!):http://tinyhabits.com/

A good experiment is to identify your team "hooks". Some example ones may include:

a new commit pushed to the repo

new build failure

standup time

weekly meeting time

start of the day of work

end of the day of work

lunch time

new deployment

Once you identify your hooks, try to replace the actions that happen before/after the hook happens. Make it as simple as possible!

Let's say, that one of your goals is to increase the knowledge transfer in your team and you decided that the 'foreman' technique is the way to go. The simplest form of 'foreman' is to review someone's else code. You can gradually introduce it as a technique in your team, that whenever anyone finishes a ticker ("after finish ticket" - hook), they look at some of the recent commits (action!) in the repo and comment on them (even if it's a simple "+1"). At the beginning, you can make it just 10 minutes. It's enough to at least look at some code.