[DanielBMarkham]

I hate to rag on TW, and I know they're good folks, but I've had about six teams that went through their Agile Inception process, and I was less than impressed by the results.

Don't get me wrong -- I think these are great questions. I think you need to ask them. And the TW guys meant well. In fact, the teams really enjoyed the exercise. It just wasn't as helpful as it could be.

I think that this is not related to the questions per se as much as it was related to the focus on the Questions rather than the goals. In other words, people love checklists, and even a checklist of simple necessary questions can be abused. What I see over and over again -- even from experienced practitioners -- is the focus on the checklist rather than the problem. They'll get through an exercise with TW feeling great, having all the questions answered, even making some cute diagrams. But the whole project is fracked, and everybody knows it. The team is just happy that they're doing what they were told to do, and had a good time doing it. That's not what I consider a successful result.

Taking dozens of teams through kickoff, I've found that the initial week or two is the most critical time for the entire project. Many times I've had managers ask for a schedule or agenda for each piece of the kickoff -- couldn't I provide just a list of questions we'd be going over? Looks like this list might do that. I always refused, however, because once I started asking these questions, we'd almost immediately run into business organizational issues: the customer wasn't present, nobody could make a decision, conflicting demands that couldn't be met, etc. And it was these problems that "Inception" is really supposed to be fixing. Not just question-answering or game-playing.

Of course, that's in an environment where the problem is fixed by the business and the teams are supposed to solve it. In a startup, it's much more experimental-based and there is no set problem. Still, asking questions like this can be very useful. Just be careful to keep addressing risks, not just answering questions. That's the whole purpose of the questions, right? To find risks so you can get to work.

[jerryr]

I agree with your checklist point. I've witnessed smart, creative people abandon thought and agility to complete a checklist. I've personally struggled with this issue in our business development process. When we're meeting with a new client, I get so excited about their project, that I dive into technical details and forget to ask fundamental questions about milestones, schedule, resources, etc. But when I have a checklist in front of me to ensure I ask these questions, I'm too focused on the list and miss important details specific to the project. We've found that a decent compromise is to have at least two people from our side at every meeting. One is dedicated to scenario-specific quick thinking and the other more mechanically ensures we've covered the fundamentals. It's still not perfect for some of the other reasons you mention, but having only one person in charge of the checklist and having others be checklist-free seems to allow for a good mix of agility while ensuring the critical parts of our process are followed.