Comments on: 10 Ways To Insure Project Failure http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/ Articles on VB.NET and Software Development Team Leadership Wed, 20 Aug 2008 11:52:32 +0000 http://wordpress.org/?v=2.2.2 By: Tom http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-979 Tom Fri, 11 Jan 2008 22:59:19 +0000 http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-979 Daily scrums are not status meetings, they are short planning meetings as a gut check for the team. Anyone using Scrum properly will acknowledge and support that contention. Daily scrums are not status meetings, they are short planning meetings as a gut check for the team. Anyone using Scrum properly will acknowledge and support that contention.

]]> By: First you Scrum down, then you Scrum up and out | Lead, Follow, or Get Fired! http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-821 First you Scrum down, then you Scrum up and out | Lead, Follow, or Get Fired! Sun, 28 Oct 2007 06:27:04 +0000 http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-821 [...] his article, 10 Ways to Ensure Project Failure, J. Frank Carr addressed pains that my team once coped with routinely—pains Scrum eventually [...] […] his article, 10 Ways to Ensure Project Failure, J. Frank Carr addressed pains that my team once coped with routinely—pains Scrum eventually […]

]]> By: 【翻译】确保项目失败的十种途径 -- Some reminiscences, some memories http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-246 【翻译】确保项目失败的十种途径 -- Some reminiscences, some memories Wed, 12 Sep 2007 07:52:31 +0000 http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-246 [...] 原文：http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/ If you want your next software development project to fail, and not just a small way but in big, spectacular, way, here are some sure fire steps for you to follow: [...] […] 原文：http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/ If you want your next software development project to fail, and not just a small way but in big, spectacular, way, here are some sure fire steps for you to follow: […]

]]> By: mcwong http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-191 mcwong Sun, 09 Sep 2007 05:35:08 +0000 http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-191 The clarification on blindly applying methodologies for political cover helps. That is definitely dangerous. The daily status meetings have to be carefully defended. We've barred specific people from our daily meetings on occasion. We're fairly vigilant about breaking teams into smaller units when they get too big. The team is actually pretty vocal when they start getting too long and/or abused. I agree that's a (the?) controversial part, but the general consensus we have is that they're extremely useful when used properly. I think the biggest beneficiaries are doc and test folks... the developers sometimes overlook the (huge) benefit they get out of it, but appreciate it when they aren't slammed with providing doc content or re-explaining the approach to a tester at the end of the project. The clarification on blindly applying methodologies for political cover helps. That is definitely dangerous.

The daily status meetings have to be carefully defended. We’ve barred specific people from our daily meetings on occasion. We’re fairly vigilant about breaking teams into smaller units when they get too big. The team is actually pretty vocal when they start getting too long and/or abused.

I agree that’s a (the?) controversial part, but the general consensus we have is that they’re extremely useful when used properly. I think the biggest beneficiaries are doc and test folks… the developers sometimes overlook the (huge) benefit they get out of it, but appreciate it when they aren’t slammed with providing doc content or re-explaining the approach to a tester at the end of the project.

]]> By: jfrankcarr http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-178 jfrankcarr Sat, 08 Sep 2007 17:53:04 +0000 http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-178 Thanks for your comment. I was mainly noting how bad managers will seek to use the latest buzzwords to provide political cover for their mistakes. They might latch on to Agile and Scrum today while 10-20 years ago they might have been misusing classic SDLC methods. If I have one skepticism about Scrum it would be the daily status meeting part of it. I've seen status meetings so abused over the years that I'm wary of them being a key part of a methodology. How has that part of it worked out for you? Thanks for your comment.

I was mainly noting how bad managers will seek to use the latest buzzwords to provide political cover for their mistakes. They might latch on to Agile and Scrum today while 10-20 years ago they might have been misusing classic SDLC methods.

If I have one skepticism about Scrum it would be the daily status meeting part of it. I’ve seen status meetings so abused over the years that I’m wary of them being a key part of a methodology. How has that part of it worked out for you?

]]> By: mcwong http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-177 mcwong Sat, 08 Sep 2007 16:27:10 +0000 http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/#comment-177 The article was a good read until the very end. It's funny that you indict the agile methodologies, when they're built to tackle a good number of the issues you highlight. I'm most familiar with Scrum..., so I'll answer those particulars. Set unrealistic goals? Nope, get the goals from the team on a frequent basis. Management's job is to manage the feasibility of those goals with the stakeholders. The more documentation the better? Nope... working code over specs. Making up schedule slips later? Nope... be constantly aware of where the project is, and manage reality. Relax standards? Nope... have a firm definition of what done means, and hold people to that definition (coded, tested, documented, demonstrable) Micromanage? Nope... delegate as much as possible to the team. Daily status? Sure, this happens. For 15 minutes. Bring in more programmers? Nope... teams are frozen for sprints. Granted you can alter structure in between, but (at least in our case) this happens infrequently Set your plan in stone? Nope... review the plan frequently with stakeholders and manage to reality. The article was a good read until the very end. It’s funny that you indict the agile methodologies, when they’re built to tackle a good number of the issues you highlight. I’m most familiar with Scrum…, so I’ll answer those particulars.

Set unrealistic goals? Nope, get the goals from the team on a frequent basis. Management’s job is to manage the feasibility of those goals with the stakeholders.

The more documentation the better? Nope… working code over specs.

Making up schedule slips later? Nope… be constantly aware of where the project is, and manage reality.

Relax standards? Nope… have a firm definition of what done means, and hold people to that definition (coded, tested, documented, demonstrable)

Micromanage? Nope… delegate as much as possible to the team.

Daily status? Sure, this happens. For 15 minutes.

Bring in more programmers? Nope… teams are frozen for sprints. Granted you can alter structure in between, but (at least in our case) this happens infrequently

Set your plan in stone? Nope… review the plan frequently with stakeholders and manage to reality.

]]>