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

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

agilewarrior.wordpress.com

149 pointsrasmus420012 comments

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.

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.

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…

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.

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

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.

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 =)

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.

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

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

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.

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

Reply on news.ycombinator.com