"2) Market. We're in an existing market where the pain is pretty acute and the problem domain well defined. Additionally, the incumbent competitors had basically neglected the market as unattractive."<p>Cust. Dev. is not as important when competing in an existing market, as opposed to building a new market - there's less uncertainty about the needs of customers.
imo if they do major "waterfall" releases every two months, they are probably doing it right and getting most of the benefits of "agile" development<p>Unfortunately, "agile" has become religion for a lot of people and sometimes, it is also an excuse for poor planning. Similarly the "waterfall" approach is sometimes used as an excuse for not making any decisions.<p>Ultimately, what matters is basic good development principles. "Agile" development has a lot of good practices and the so-called "waterfall" approach also has its benefits and the right approach is to use the most appropriate methods for the team. Getting hung up in terminology isn't going to help
<i>We tend to follow a more traditional (waterfall)
dev cycle, with patch releases roughly every 1-2 weeks and major
releases every 2 months. </i><p>If you release every two weeks, with a define-design-develop-deploy cycle in those weeks, then you may very well be doing agile development. In my current project we're employing Scrum (but I really don't think that matters; might as well name it Lean, Kanban, XP, RUP or whatever) and we're doing just that. It's working pretty darn well, I may add, primarily because of the near-continuous customer feedback.
The most successful start ups and products I've ever had the pleasure of building or working on were complete and utter nightmares as far as modern development methodology is concerned. Heck, I remember when we wrote MyBlogLog we didn't even have source control. The key is to get the product to market as fast as you can. You can fix your process later, you know, when you have more than one employee.
Customer Development is probably best for Enterprise level applications where you can speak with the head of a 100-person team and get an answer for everyone else.<p>For consumer applications, however, you can ask 1000 inidviduals and get a "No" while your product could still be helpful to 4 million others. For example when I ask my friends to switch from Yahoo Mail to Gmail they usually answer "What does Gmail do that Yahoo doesn't?" or "This is fine for me".<p>EDIT: What if Twitter followed a customer development model? They probably would not have written a single line of code.
Am I the only one here who doesn't want to take software-engineering advice from a UI company? When it comes to engineering, I want to hear from Yodlee and what they're doing to solve problems.
What's agility after all?<p><a href="http://en.wikipedia.org/wiki/Agility" rel="nofollow">http://en.wikipedia.org/wiki/Agility</a><p>For me being agile is adapting to a changing environment. Animals are being agile to survive in their natural environment and we are agile to survive in our environment. If your "agile" mind tells you to slow down to get to something you do that. So if "waterfall" is the key for the next few releases then what's the problem? The "agile law" would have to draw up all the scenarios in the world to be word for word otherwise what agile means is: do whatever you want just get it done and I can share you this and that from my experience. It is basically passing on responsibility and judgment to the executioner after a bit of coaching ideally from past experiences. Think of a coach-football player relationship.
This is how I see it and I hate this branding of it and of putting labels everywhere when it should be: "stop being an idiot and take it from there" - common sense
Well written and informative but dangerously close to corporatese...<p>Mintspeak: <i>We've hired a bunch of great product folks and engineers, and all of them are Mint users, so we're typically "scratching our own itch".</i><p>What we really mean: Don't need no stinkin' market research.<p>Mintspeak: <i>We're in an existing market where the pain is pretty acute and the problem domain well defined. Additionally, the incumbent competitors had basically neglected the market as unattractive.</i><p>What we really mean: We kicked ass.<p>Mintspeak: <i>...unlike most start-ups, we're dealing with people's financial information.</i><p>What we really mean: We run a serious business and you don't.<p>Mintspeak: <i>...we have a number of quality control and security processes that rival most financial institutions, and which would would be difficult to incorporate into an agile dev cycle.</i><p>What we really mean: Our secret sauce has nothing to do with the trend du jour.<p>Mintspeak: <i>...a big part of Mint's success was being in the personal finance space when the economy melted down.</i><p>What we really mean: We're good, but we're lucky too.
It seems to me that their plan was to build the product and than sell it, to someone big, to integrate with something else. It's like they don't care a lot about adding new features or things like that, like they don't care about modern or old techniques. Just build it.
Continuous Deployment<p>That being said I think the smartest people generally don't care about asking a question when they don't know something. Cue feynmann.<p>Edit: oops meant to reply to someone here. iPhone failed me.