Comments on: Take your time but hurry up! http://47hats.com/2010/01/take-your-time-but-hurry-up/ Bob Walsh Tue, 07 Feb 2012 15:41:38 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Jarie Bolander http://47hats.com/2010/01/take-your-time-but-hurry-up/comment-page-1/#comment-32060 Jarie Bolander Thu, 14 Jan 2010 15:19:12 +0000 http://www.47hats.com/?p=1934#comment-32060 Thanks for the excellent comments. I agree that changing requirements should be the number one thing to not do. Many a project has cratered because of the "sea of never ending changes." It also messes with the groups pace and grove. Thanks for the excellent comments. I agree that changing requirements should be the number one thing to not do. Many a project has cratered because of the “sea of never ending changes.” It also messes with the groups pace and grove.

]]> By: MicroISV Digest – 01/13/2010 http://47hats.com/2010/01/take-your-time-but-hurry-up/comment-page-1/#comment-32057 MicroISV Digest – 01/13/2010 Thu, 14 Jan 2010 04:25:43 +0000 http://www.47hats.com/?p=1934#comment-32057 [...] Take your time but hurry up! was a great guest post here by Jarie Bolander, author of Frustration Free Technical Management… [...] [...] Take your time but hurry up! was a great guest post here by Jarie Bolander, author of Frustration Free Technical Management… [...]

]]> By: Giammarco Schisani http://47hats.com/2010/01/take-your-time-but-hurry-up/comment-page-1/#comment-32050 Giammarco Schisani Tue, 12 Jan 2010 23:24:43 +0000 http://www.47hats.com/?p=1934#comment-32050 "Don't change requirements" should be number 1!! ;-) “Don’t change requirements” should be number 1!! ;-)

]]> By: Mark L. Smith http://47hats.com/2010/01/take-your-time-but-hurry-up/comment-page-1/#comment-32049 Mark L. Smith Tue, 12 Jan 2010 22:29:22 +0000 http://www.47hats.com/?p=1934#comment-32049 I've found #6 in Practical Pacing Techniques to be very critical -- changing requirements can kill a dev team. This can be a hard sell to management. My strategy has been that once a plan has buy in from everyone and is sent to the deve team, to go ahead and open up the first "change ticket" to collect all of the requirement changes that come in. The dev team should know about this "change ticket" but realize that it isn't an approved plan and continue with the original requirements. It's helpful because you are still capturing the changes, the developer's know about the changes (and can take them into account in the current design if that makes sense), but the developers don't feel knocked around on a sea of never ending changes. I’ve found #6 in Practical Pacing Techniques to be very critical — changing requirements can kill a dev team. This can be a hard sell to management.

My strategy has been that once a plan has buy in from everyone and is sent to the deve team, to go ahead and open up the first “change ticket” to collect all of the requirement changes that come in. The dev team should know about this “change ticket” but realize that it isn’t an approved plan and continue with the original requirements.

It’s helpful because you are still capturing the changes, the developer’s know about the changes (and can take them into account in the current design if that makes sense), but the developers don’t feel knocked around on a sea of never ending changes.

]]>