Starting an Agile Team to become the A Team

Here are some recommendations to any team lead or development manager to have effective agile teams.

_{Note: these are just recommendations}

1. Get a white board for your Kanban or Scrum task and stick iteration tasks on the board publicly not in your office or cubicle
2. Get every developer 2 monitors, that includes the QA since they should be part of your team. For team lead get them 3. One for monitoring the build or Nabaztag build bunny. Hold people accountable for breaking daily builds (buy donuts, pay a dollar into the pool for pizza, etc)
3. Every developer machine should have 16G of ram or min 8G, anything less is unacceptable.
4. Use a source control, bug tracker, and continuous build/integration
5. Get a Powerful Build machine, install TeamCity or Hudson or CruiseControl or get TFS build agent running, or use the cloud to build.
6. Get tools like Reflector, Resharper or CodeRush, Test Driver .Net, Code Coverage (dotCover, NCover) and “teach, guide” them how to use it effectively, shortcuts etc
7. Get a wiki up and running for documentation of how to’s (local build, server build, etc )
8. Teach the team proper unit testing, whichever framework you choose (NUnit, MbUnit, etc etc)
9. Teach them mocking, whichever framework you choose (Rhino Mocks, Typemock Isolator, Moq, JustMock, etc) pick one and stick to it
10. Teach the entire team how to debug effectively, using your IDE, teach them what pdb files are and how to remote debug if in .NET world, if you are in Java teach them how to debug a JVM, in Ruby just have them write unit test 🙂
11. Have the entire team know about your build and document it on a wiki, don’t just have one person who is the build master due to the bus factor (If build master gets hit by a bus tomorrow who can take over the build?)
12. Have only max 15 minutes daily stand-ups with format of “What I worked on yesterday, What I am working on today, and are there any impediments.”, there should be no sitting or resting or leaning on an object/wall. If there are extra things that come up, have those people with the team lead meet after the stand-up to resolve those issues.
13. Provide an area for collaboration, pair programming
14. Have a code clean up iteration for the team don’t just keep pushing features out. Let the team clean up the mess they have created.
15. Use a runtime analyzer to see what features users are using, tools like Gibraltar or Runtime Intelligent Service definitely helps, or if you are cheap log things into a logging database with NLog or Log4Net.
16. Automated! Automated! Automated!, builds, unit test, regression testing, performance testing, everyday there should be reports on what has build, passed and failed.
17. Provide a learning atmosphere for the team have them showcase some technology, what they have learned, or create knowledge transfer brown bag lunches.
18. Last but not least make it a fun learning environment for everyone involved, celebrate whenever milestones are reached, take the team out to eat to build trust. (There is something about breaking bread with someone, it builds trust.)

By the end you will have an Agile team that looks like the A Team 🙂

(hidden link in image)