"We don't really practice agile development nor CD" - Mint.com | Hacker News Reader

"We don't really practice agile development nor CD" - Mint.com

groups.google.com

145 pointsebloch39 comments

"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."

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.

Well put. I completely agree. This is something I've previously spent a good deal of time thinking about.

Unless you're re-segmenting the existing market.

This comment is undervalued, a lot of times people don't necessarily know what "if I just get 1% of the market" really means because they haven't gathered any data

I hate showing my ignorance, but what is "CD"?

Customer development :)

I think it could also be continuous deployment.

The author is a product person, and he specifically mentions "The Four Steps to the Epiphany" so I believe he's talking about Customer Development.

One of the previous items in the thread also mentions customer development:

Useful, sure, but for those of use way before those steps, there was nothing about customer development.

http://groups.google.com/group/lean-startup-circle/tree/brow...

Don't hate that. I like people who admit they don't know everything, I think many people like that.

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

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.

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

If they're making stuff people want in small timeboxes, they're being agile.

Agreed that agile has become too religious.

Now having said that, I'd argue that smaller timeboxes with a tighter feedback loop into "what people want" would make them even more successful.

The neat thing about real agile isn't that it's a religion (although it is for many) it's that it gives us context to talk about what works better or worse in iterative, incremental development.

We tend to follow a more traditional (waterfall) dev cycle, with patch releases roughly every 1-2 weeks and major releases every 2 months.

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.

It certainly doesn't sound like that's what he means. I expect "patch releases" means bug fixes and small tweaks.

In any case, the guy said they don't do agile. I am really loathe to try to go in and discover a way in which it could be interpreted as agile after the fact lest it feed into the whole consulting/book-selling/conference-organizing/koolaid circus that agile has already become.

On the other hand, it may be worth to try and get 'agile' redefined to something sane.

"In any case, the guy said they don't do agile. I am really loathe to try to go in and discover a way in which it could be interpreted as agile after the fact"

Amen!

Classifing any project with a practice passing resemblance to some "agile" practice as an "agile project " just leads to the twinned "all successful projects were really doing agile whether they knew it or not" and the "any failed agile project didn't do "proper" agile, even if they said they were" fallacies.

This is especially weird since "agile" really didn't invent anything (except maybe rigid TDD). It just packaged some "best practices" into one label. Short iterations was a known to be effective practice well before the advent of agile.

My thoughts exactly. If you're iterating this fast, you're pretty much doing agile, whether you follow SCRUM/XP/etc or not. As I understand it, the various agile practices are simply there to enable these quick iterations.

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.

I'm not so sure about that. Speaking as a one-man startup who has moved recently from pre-modern to modern development methodology, using modern techniques like continuous deployment and dvcs (git) pay off pretty quick. Having a one-command deployment, for example, it's a huge time/stress saver when makin bug fixes or small feature changes several times a day.

Yes, 1-click deploy ROCKS. I can't believe how I lived without it, FTP-ing files to a server, updating the code would take like an hour or more, now it's a matter of pressing 1 button and waiting a few minutes.

Oh we had 1 click deployment too. It was FTP. :) That said, Capistrano is an easy way to make deployment much easier/fun/dangerous. I wish we'd had SCM and a deployment tool back in the day, but back then we just... didn't. Instead we had to focus on getting it right the first time, because there was no going back.

On my side projects I use cap+deprec+svn, so I completely understand the appeal. My point is that you don't have to use a bunch of tools, have tests, and/or use modern methods to be successful. Sure, it makes the journey easier, but its certainly no requirement for having a great product.

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.

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".

EDIT: What if Twitter followed a customer development model? They probably would not have written a single line of code.

Regarding your edit, I don't think that the Cust. Dev. proponents say that it's the only way to develop products, but on average it will help you succeed. It also seems like Twitter used some concepts that CD also suggests. With such a simple product, they probably stayed at the MVP stage for a long time.

"For consumer applications, however, you can ask 1000 inidviduals and get a "No" while your product could still be helpful to 4 million others."

You are asking the wrong people then. CD just saved you a huge amount of heartache, by not trying to market to the wrong segment.

Le's say you are twitter founder pre-1st-line-of-code, who do you ask?

Whoever you have identified as fitting your hypothesis on early adopters. It's not rocket science.

So you ask the people who are most likely to give you the answer you want to hear.

That's the point. What are you missing?

If the people you think you are going to market to don't think your product idea is good, then you have nothing.

Just to be clear--with customer development, you don't ask customers for your vision. That's still the founders responsibility. So yes, I think @ev and @jack would have still written code. They would have then asked people (not laggards, but people they already think might be interested) if their MVP has legs.

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?

http://en.wikipedia.org/wiki/Agility

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...

Mintspeak: 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".

What we really mean: Don't need no stinkin' market research.

Mintspeak: 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.

What we really mean: We kicked ass.

Mintspeak: ...unlike most start-ups, we're dealing with people's financial information.

What we really mean: We run a serious business and you don't.

Mintspeak: ...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.

What we really mean: Our secret sauce has nothing to do with the trend du jour.

Mintspeak: ...a big part of Mint's success was being in the personal finance space when the economy melted down.

What we really mean: We're good, but we're lucky too.

#awesome

Mintspeak: 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. What we really mean: We kicked ass. No, it has says, we only had to do reasonably well because competition wasn't putting in many resources to the problem.

Sorry but what they say is clear and only slightly corporate but what you "translate" it to is less meaningful statements in snide "dudespeak".

  Mintspeak: ...unlike most start-ups, we're dealing with people's 
  financial information.
  What we really mean: We run a serious business and you don't.

I think that mean there are specific legal requirements that have to be adhered to.

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.

I think their main features were 'it's easy to use and pretty and it works well'. They cared a lot about those.

Continuous Deployment

That being said I think the smartest people generally don't care about asking a question when they don't know something. Cue feynmann.

Edit: oops meant to reply to someone here. iPhone failed me.

"neither do we give a shit if we put our product up in a state that is pretty much unusable".

Reply on news.ycombinator.com