4 ms·
What’s Your Start-up’s “Bus Count”? Myths of Entrepreneurship and Programming
- msie 15y agoI don't like Agile. Does that make me a dinosaur?
- DanielRibeiro 15y agoI really like Eric Ries approach to suggestions: test them and see if they help you build-measure-learn faster/better. This is because for every suggestion there is an example of startup that did/didn't do it and it worked fine/didn't work at all (all 4 possibilities happen). However, if this very suggestion sounds too agile for you, then I don't know if I can help you.
- msie 15y agoWell, I bristled when they use the word "myth" freely throughout the article, as if you're doing things wrong if it's not pair-programming, shared-ownership and you're employing specialists as opposed to generalists. It would be nice to have a bunch of generalists working in your startup who all have good knowledge of all parts of the system, but it didn't work out for me. It's hard to find full-stack programmers and I lose some sense of pride when I don't get ownership of a part of a system. It doesn't feel good to be replaceable. Don't try to do agile without coaching that's for sure.
- DanielRibeiro 15y agoCouldn't agree more. All agile practices can pay off, but people underestimate the effort and the required culture for it to work. This is one of the reasons "Agile’s Second Chasm (and how we fell in)" http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
- notJim 15y agoI find the religion of capital-A Agile annoying, but agile as a process that you adapt to your practical needs can be very effective.
- kristianp 15y agoHere is the explanation for Bus Count from the article. "“bus count” (how many people in your team have to get hit by a bus before you’re all dead in the water) is a critical indicator of risk for the software start-up."
- Todd 15y agoThere are some interesting ideas here, but it's a little heavy on opinion. Rob's obviously an agile zealot. These myths he's refuting are not universal, though. For example, pair programming doesn't work for everyone, nor does the open office + headphones arrangement. Some people are extremely productive working alone uninterrupted. While I agree that the "full-stack" generalist is good, sometimes you do need people who can specialize, deep dive, and "own code"--even if others play in that part of the code base. Some technologies actually do require hard thinking and deep understanding of 10's of thousands of lines of code. I'm afraid he's painting with a pretty broad brush.