Roy Osherove: Code Leaders and Beautiful teams

Combining technical practices and leadership

What makes Teams great
- Automation - in all levels. Personal level, team level.

Examples
of "do not use the mouse"
if you do something twice, create a script for it

Get to know your tools/Master your tools

Make people commit to improvement in productivity

TooTips: FinalBuilder
Avoids the unmaintainable mess of MSBuilds, Ant tasks etc.

Test and buy the right tools
Throw out the wrong tools (ClearCase is mentioned as a god example...)

Get quick, continuous feedback
- Does my code work?
- Did I build the right thing? (clarify with customer - every iteration)
- Am I doing things right?
Stand up meetings
Pair programming
Code reviews
Test reviews
Just-in time design decisions

Communicate when you have problems
Create a culture where bringing up issues is a natural thing.
The team (lead) should know it within a day if a developer has problems

Show progress visually and big
This does NOT mean MS Project plans..

TeamLevel: Use whiteboard with notes in columns
- To-Do
- In Process
- Done

This will visualize for everyone the issue of to many items "In progress" at the same time, and productivity is hindered by context switching issues.

http://leansoftwareengineering.com/ksse/scrum-ban/

Limit the amount of tasks assigned to a person at the time (max 2?)

Communicate without "meetings"
Daily standups
Pair programming (research show 120% effort in building, much better quality and communication, less bugs)
Peer code review
Same room
Big visual progress

Create a drawing to visualise the state of the solution - seems strange but have huge impact on common understanding. What are we working on now.

Grow people with integrity
Are the people in my team better this month than he month before? What can I do to challenge and help them?
Make proposals for change and ask people for commitment to change.

Remove obstacles for your team

Daily/weekly questions (from Roys blog)

Whole team

1. What can we automate?
2. where are we "Reinventing the wheel"?
3. what are the tools that slow us down?
4. what tools can we use better?
5. are there bugs that I could have found earlier? how do I make sure I find them earlier?
6. when do we find out we built the right thing?
7. when do we find out our code\design sucks? how can we make that earlier?
8. How do we show progress at the team level? at the management level?
9. How many meetings does each dev have every week? how can we remove them?
10. Are we building by feature or by layer?
11. can we make all our team sit in the same place?

Team Lead

1. daily: what bottlenecks exist in the team? what have I solved?
2. will my devs be better in a month or two than they were before? if not, how do I make that happen?
3. what prevents my devs from working? what am I doing about this?

The talk ended with Roy singing a song (with guitar) on "Knocking on the clients door". Hilarious :-)