Questions you'd be crazy not to ask at the start of your next project

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.<p>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.<p>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 <i>problem</i>. 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.<p>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 <i>these problems</i> that "Inception" is really supposed to be fixing. Not just question-answering or game-playing.<p>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.

So, from this blog I learned that there's a "Agile Samurai" book. Which is somewhat ironic, considering that hyperbolic job descriptions like this are kinda driving me towards <i>seppuku</i>…

For reasonably sized projects, "Show the solution" is the most important step. It is the first time your wishlist meets real constraints. It's not as important as "release early and often," but all roads lead through your software architecture.<p>Draw your modules on a whiteboard, connect them, and specify the data that flows between the modules. A prototype may also work, but I've never tried. Convince yourself and the rest of your team that this covers all of your intended functionality. Redraw until it does. This shouldn't take long - if your work is small or well-specified, you may spend 10 minutes at the board. This exposes early misunderstandings between members of your team, acts as an Early Warning System for timesinks or fuzzy features, lets you partition early work, and lets you cheaply iterate on technical solutions.<p>If you don't do this, this will be done on an individual basis, and misunderstandings will be turned into code. Common mistakes, like merging modules that should be separated, will be harder to fix as the project goes on.

Managers are great at talking the talk, but it takes great developers to walk the walk. My current project is successful in spite of a similar list that was created at the inception. Over the course of 3 years, the why, the pitch, the NOT list, the Yes list, the priorities and what not have been changed and we keep afloat just because of two things : robust architecture and continues refactoring

<i>4. Create a NOT List</i><p>I love this one. Nothing irks me more than a vendor soliciting feature requests without fixing critical longstanding bugs. While I wouldn't expect a NOT list to be written in stone, the mere existence of one might help to keep priorities straight. Sometimes that means saying <i>no</i> to crazy feature requests.

Ok so the elevator pitch template in point 2 is exactly like the vision statement template from RUP, probably older than that. The in scope/ out of scope /unresolved table is also commonly sen in many standard templates. 5 and 6 7 and 8 are also oh so common. The whole list just look exactly like what you'd find in a vision or charter document in typical methodologies.<p>This doesn't mean its bad or wrong just that this is clearly geared at people who have never been through software projects using any methodology.

Very well written - this was one of those posts in which the graphics really added to the message.