GoRuCo Pace U. - Session 3

"Managing Ruby Teams" - Luke Melia

First thing's first: what makes rubyists different?
- lots of independent thinking
- all open source with no dominant conglomerate running frameworks, dev techniques, etc... (see C#, Java)
- rubyists constantly embrace change (for example, Rails has 1500 contributors and consistently breaks backward compatibility - and everyone seems cool with this).

The Key Principles:
- self-organizing team (core of XP practices); this extends to empowering the team to maximize its own effectiveness.
- personal growth: simply being successful on a team, for most developers, is not enough. So a manager's job is to make sure they grow as professionals while working on the team.
- hire well (Cyurs: check)
- servant leadership - Jess Hottenstein may actually know what he's talking about.
- inspirational leadership

Practices:
1) Sit with your team. Listen and observe, but think twice before interrupting. Let the team try to hash out their issue.
2) Management by coding around. Pair program with different people, walk around the team's area and observe information radiators. Observe the "key feedback loop."
3) Tools and workspace. Share editors (if possible), tools, scripts, etc... amongst the entire team. And, obviously, sit together in an open area.
4) A Policy for Policies. You will have to put some rules in place but try to put in as few as possible. Fit each policy to the frequency and severity of the target problem.
5) Retrospectives and Kaizen. Luke doesn't distinguish between the two, but I think both are separate and important activities.
6) Delegation. Identify discreet, repetitive tasks and automate them. When you can't automate, delegate. They should be shared amongst the team. (an example from my team is tracking and troubleshooting (if necessary) the twice-daily push to our staging server).
7) The Andon Cord. The stop-the-line cord. (This is from Toyota Production System). Give your team this power. (And definitely stop the line if the build breaks!)
8) Be patient. Be aware of the forming, storming, norming, performing cycle.
9) One-on-ones. Simply a meeting between the project lead and the team member. Make the time pre-planned to privately address concerns and questions. You can also take this time to give feedback.
10) Motivation. Understand what motivates each employee. It can vary widely. For rubyists, don't underestimate the "mastery" motivator.
11) Feedback. Learn how to deliver it effectively. On our project we are actively trying to become better at giving each other feedback. It's not easy, but it really promotes a healthy team.
12) Open Source. Use it; share your changes. Using git submodules is a great way to contribute to open source while still addressing the team's concerns.
13) Hiring. Do it like Cyrus does it (Note: This is not exactly what Luke said). But one interesting thing that we don't do is "get 100% of the team on board." This can be tricky; we don't always know where the new hire is going or what team they'll be on. But that doesn't mean it's not a good goal to shoot for.
14) The Us-Them Relationship. Fight hard against the "our team versus the company/other project teams" relationship. Cultivate it externally - carefully. This means looking into the community to find other teams or projects that your team can learn from.
15) Be honest. Don't lie to our team. Share your passion. This is the 15th bullet point, but Luke makes it sound like the most important one. "Destroy trust, and the whole thing comes tumbling down."

Check out the reading list at: http://bit.ly/gorucobooks for some more info. Also Manager Tools, Agile Executive, and Agile Toolkit are all podcasts that helped Luke become a better manager.
15)