Student Q&A: Working thru the Waterfall Hangover w/ Dave Prior

Successfully completing a CSM or CSPO class doesn't impact everyone the same way. For some, it is like a lightbulb went off and everything about Agile just makes sense. For others (like me), some of the ideas and values from waterfall persist for a time. Questioning agile and trying to reconcile this new way of thinking with the old way is part of the personal journey of moving from a traditional approach to an agile way of working. I tend to think of it as a hangover that occurred from drinking a little too much waterfall. In this week's podcast, I address 3 questions that were submitted by a student following a recent class. These were the same kinds of questions I was asking when I took my CSM training and was getting my head around agile. In the podcast I address not only the questions that were asked, but the bigger ones that may be more subtext - around, why do we need to work this way? The questions: 1. What are the factors that lead us to the decision to go Agile or Waterfall? The simple "Scrum is best suited for complex projects" (page 10 of the workbook) doesn't seem to be enough and there could be challenges against that statement. The more complex the issue is, the more effort we would want to spend upfront instead of down the road. Is earlier we detect the issues the less cost to fix it? 2. We know a perfect scrum team should be cross functional but in reality, we're far from that. The question is how to fix the velocity gap between the roles to maximize their efficiency? E.g. developers code faster than testers (usually when the system is huge and a single change would require a lot of regression testing). We know we can fix it by adjusting the ratio among the roles but the amount of work changes overtime, if we keep adjusting the ratio we will NOT have a stable scrum team. 3. As User Stories do NOT contain the requirement details, the requirement is actually conveyed through discussion between PO vs Dev team, how can we capture the product specification? The Product Specification is extremely important for many purposes including training of new team member, doing impact analysis, or for PO to know how the current system works so they can plan for future improvement. Should we spend effort to compose/update Product Specs? If we do, will that be a User Story or just count it as overhead ? This is a pretty short podcast (less than 15 minutes) so I have not broken it down into timed show notes. Contacting Dave LeadingAgile: http://www.leadingagile.com/guides/dave-prior/
 Twitter at http://twitter.com/mrsungo Personal site at: http://drunkenpm.net Feedback/Questions If you have comments on the podcast, or have questions for the LeadingAgile coaches that you’d like to have addressed in a future episode of LeadingAgile’s SoundNotes, you can reach Dave at [email protected]