Questions you'd be crazy not to ask at the start of your next project
agilewarrior.wordpress.com
Questions you'd be crazy not to ask at the start of your next project
1–10 of 14 posts
Re: Questions you'd be crazy not to ask at the start of your next project
#2Very well written - this was one of those posts in which the graphics really added to the message.
Re: Questions you'd be crazy not to ask at the start of your next project
#3So, 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…
Re: Questions you'd be crazy not to ask at the start of your next project
#4Ok 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.
Re: Questions you'd be crazy not to ask at the start of your next project
#54. 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.
Re: Questions you'd be crazy not to ask at the start of your next project
#6Very well written - this was one of those posts in which the graphics really added to the message.
You forgot the tags. At least I hope this was intended sarcastically.
Re: Questions you'd be crazy not to ask at the start of your next project
#7For 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.
Re: Questions you'd be crazy not to ask at the start of your next project
#84. 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 =)
Re: Questions you'd be crazy not to ask at the start of your next project
#9Very well written - this was one of those posts in which the graphics really added to the message.
You forgot the 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.
Re: Questions you'd be crazy not to ask at the start of your next project
#10I 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.