Summary of a summary on Great Teams

Mike Polen has made a good summary of an hour talk of James Shore on what separates the great teams from the average agile teams.

Note, I recommend listen to James Shores’ own talk. He’s pointed out to me and commented here that there are many misunderstandings. In addition, I both recommend an RSS feed to his blog and reading the book The Art of Agile Development he’s co-editing. However, I will leave the list be (the cause of the “troubles”). It’s up to the reader to reflect on what’s put in it. You try and fail, reflect and learn. There are no universal rule of what a Great Team is, or how to form one, we should all know that by now! See this article on cargo cult agile if you feel like taking the list for a fact.

Summary of the summary (I claim my rights to misunderstand his potential misunderstandings):

Great teams they :

• take time to become great (many months). “Forming-storming-norming-performing”
• sit together. They adapt more of the XP values, especially pair programming. Scrum values as self-organizing teams should also be adapted.
• have no long lived code branches
• focus on preventing defects through TDD and refactoring the code to its intended simplicity.
• deliver features that are truly done, that is, “Done-Done”.
• get real-time feedback on features and priorities.
• avoid technical stories (taking time off to refactor).
• need someone who is passionate about quality and pays attention. This person doesn’t need to be senior but needs courage to speak up when things are going wrong.
• uses agile engineering practices as TDD, continuous design, rigor & mindfulness.
• don’t require A-team members, ordinary people makes great teams with agile engineering.
• deliver often (daily/weekly), short feedback cycles.

maybe… ;)

Note to self: Don’t try more summaries on summaries.