131–137 of 137 posts
The idea of Scrum terrifies me, especially the Daily Scrum, because I've a very cycling productivity. In averaging the days, I get enough done. But if I would have to justify my less productive days, it would be very stressful for me, and it would be quite hard to explain why I couldn't get done more today.
Earlier quoted context omitted.
That sounds like an assumption that everyone's in the business of selling software. I'm certainly not.
Are you in the business of writing software that never gets used? I have, and I hated it. Quick feedback means quickly finding out if you're building the right thing.
I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
Earlier quoted context omitted.
If there is no way to tell, does it matter? It's easy to see the flaw in many failed implementations: they don't manage their schedules, they don't have successful iterations, they don't manage their technical investments, and the only thing they don't do that agile suggests isn't usually worth doing is writing lots of specifications and documentation beforehand.
It's easy to see the flaw in many failed implementations Is it also also easy to correct the flaw? I don't mean to blame Agile practices. It could be the case that Agile is a bad fit to some "corporate cultures" or certain project type and the result of someone pushing hard its adoption is to have some practices really used and other only in appearance. This could be what people hates. OK. that would not be "True Agi…
Not at all. If everyone involved in the project (everyone with a stake in the success of the project) agrees to give an agile process an honest chance, great. If not, you'll have trouble. A similar rule applies for coding standards, for test coverage, for security and logging, for transactional safety, for dieting, and for getting out of debt.
Earlier quoted context omitted.
Agile does not require perfect implementation. I have yet to see an "unsuccessful" project using agile, as in the customer and team was not happy with the conclusion (I've been involved with > 10). Usually things change before that point is reached. If the team cannot change when things start sucking, then things will continue to suck, regardless of methodology or lack of. Most teams can adjust (at least the ones I w…
I have yet to see an "unsuccessful" project using agile The question I was responding to was if all the problems were caused by Agile or by deficiencies in its implementation. If all you've seen is succesful projects, you can only guess why failed ones fail.
True. The project I have been a part of do have problems though. Sometimes the problems get resolved quickly and sometimes it takes a while or never happens.
Failure comes in many forms. I'm not pretending to have encyclopedic knowledge over the various ways projects fail. I do know that issues arise on the team and good communication often helps resolve these issues.
Also, having a good attitude is important. It's easy to be negative to your teammates (I have this problem), but it's also harmful and inappropriate at times.
In my experience, the biggest issues (or the largest cause of my stress) were often issues within the team.
The idea of Scrum terrifies me, especially the Daily Scrum, because I've a very cycling productivity. In averaging the days, I get enough done. But if I would have to justify my less productive days, it would be very stressful for me, and it would be quite hard to explain why I couldn't get done more today.
That doesn't mean every team handles the daily scrum well or that the purpose is never hijacked. But it does mean that if the scrum starts to feel like a tribunal, it's probably a process smell that should be raised in the sprint retrospective.
Regardless of the Agile theme (that I know little of to comment) this sentence applies to almost all the business books (specially the biography type).
I've read a lot of them and they are basically a collection of feel-good stories with some themes. Selection bias. A typical book will have a chapter like "Never give up" describing some story where the author insisted upon something far-fetched and finally got it (never mind the time he spent on other objectives he didn't get and never mentioned). Same with a lot of other typical themes.
A more objective book like "Founders at work" shows that all of them (from what I remember) got lucky not once but at least twice to have their break. Of course insert here the usual disclaimers that you cannot rely on luck only, you have to work hard etc to be ready when opportunity strikes.