
Questions you'd be crazy not to ask at the start of your next project - rasmus4200
http://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
======
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.

------
mhd
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 _seppuku_ …

------
jakevoytko
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.

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.

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.

------
alexro
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

------
qjz
_4\. Create a NOT List_

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 _no_ to crazy feature
requests.

~~~
Feeble
I completely agree. Usually the client will say YES! to each and every new
feature idea that pops up during meetings. Forcing an explicit list of NOT-
features might be a good excercise... I have to try this next time =)

------
igrekel
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.

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.

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

~~~
billswift
You forgot the <sarcasm> tags. At least I hope this was intended
sarcastically.

~~~
ScottWhigham
No, I am serious. The graphics were not your standard clip/stock art I thought
they added to the message. If you don't, that's fine but there's no reason to
be rude or disrespectful about it.

~~~
alttab
The team must be so agile they didn't proof-read it.

