Agile Otter Blog

State of Practice: Scrum I participate in a number of forums where I am happy to help people understand agile methods and practices. I see dozens of question s every week asked (and often answered!) by people who are operating in a system they simply don't understand. For instance, one very well-intended manager called a meeting with HR and consultants and leaders of teams to decide what a scrum master's duties are, and what a PO's duties are. Only the consultant had ever read t he scrum guide ; the rest were going to invent roles to match their current job titles. Not understanding that people can rotate roles (and roles can even evaporate), the HR wanted to make the roles have specific meaning benefit-wise and hire specifically for some of those roles. In an online forum, a manager asked "since release schedules are fixed, how do you make up for slippages in sprints." This belies that the project plan was a big-project plan (BDUF-style) divided into sprint...

The basics are well-known: Everyone knows the basic cycle of TDD. You should also know the improved Industrial Logic version of the TDD cycle . You have heard Uncle Bob's three rules . But there is so much more to know. I have been gathering little sound bites for you which may help you build your skills and knowledge. Please feel free to drop additional factoids or questions. I'm happy to explain any of these at length if you like. Here is my list: Your code has two parts: the part you have covered with TDD, and the part that requires you to use a debugger. Microtests are F.I.R.S.T.   (you cannot TDD after writing the code) Only microtests are appropriate for TDD; other tests are useful, but not for TDD. Microtests are not all your tests - you need other levels of test still.  TDD does not validate your system; it only speeds development and improves quality. TDD without a pair programming partner is like programming while wearing only one shoe. ...