Historical errata for Agile in a Flash

Card Back

- Tracker is not mentioned on the back
- Tracker could be rotated around team or dedicated person for multiple teams.
-Running Tested Features is one metric worth tracking.
—Either track RTF manually or automatically (e.g. # of passing Cucumber features)

Card Back - Somewhere (this card or another), you should discuss trade offs between INVEST values(e.g. when adding a security feature to legacy SW with existing technical debt, it may not be possible to create a story that is both valuable AND small. Yes there are techniques [Card #20] to break large stories, but those don’t always work to create stories that are small AND valuable).

Card Back - Confirmation - You should note that the “acceptance test” should be automated where ever possible (e.g. usability isn’t), because it is not obvious to everyone. Could make a good transition to BDD or ATDD and how Cucumber, etc. makes automated tests understandable to customers.

The critical importance of automation needs explaining, because it’s part of Scrum, where so many “agile” folks originate. So please state:
1) Why manually executed test scripts are abuse,
2) Why why automated tests as documentation don’t become stale and
3) Why run tests in a near production environment.

Card Back - My typo, not yours. Meant to say that Automated testing, etc. ISN’T part of Scrum.

Card Back - Abstract - Recommend Cucumber or similar tool.
Free of Duplication - Great as long as the tests are still readable. Readability is even more important than DRY. I’ve seen DRY abused in automated tests and code, so the tests and code are unreadable.

Card Back - The concept of a WIP Limit is implied, but not stated on this card.
Assuming a simple XP style card wall, the In Process formula I use is (# of developers / 2) + 1 . That encourages pairing, collaboration and swarming on work, while providing a very small amount of wiggle room in case something becomes stuck beyond the dev team’s control.

Card Back - Multiple teams working on a single project need ways to communicate between them. Kanban can scale to a large team by walking the card wall together, then breaking into smaller standups afterwords. Scrum of Scrums can also work, if all teams are new development teams. Both large Kanban and Scrum of Scrums need to meet daily. If using Scrum of Scrums, where there is only a single rep from smaller team, then you need to ask additional questions like: 1) What is my team doing that will impact your team? and 2) What does my team need from your team?

Card Back - Team size & Retros - DON’t start retros for the first time with a large team or multiple teams together. DO start holding retros with small teams or sub teams of larger team and hold each separately. When you have a retrospective culture and teams are used to focusing on improving themselves instead of finger pointed, then you may want to hold larger retros with either the large group together or representatives of each group. Project timeline retros could be appropriate for a large group. - Expect large group retros to take longer and be more painful.

Is there a web site with links to starting coding standards for different languages and platforms? - If so, reference it. -If not, start one on the XP Wiki or someplace. Then reference it.

Card Back - Might want to reference “Pair Programming Illuminated”. Or finish your book on pairing and reference that.

Card Back- Monitor Coverage - Dynamic languages really need coverage higher than 90%. Mind you TDD will get you there.