Async, textual, standups
Async knowledge sharing and gathering documentation before synchronous online meetings
Using and building tools which can greatly support you with your async and/or remote environment
Splitting bigger stories into smaller ones on the fly
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
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.
Hook: You finished a ticket
Action: Review someone's else code for 10 minutes
You can't do much in 10 minutes, but if you know the Kronos/Chairos time management technique, that we were promoting, you know how to use the time best.
If you feel, like there's still more you can learn about the new async team techniques, just grab our recent book - it's designed to safely refactor your team towards being more effective!