There is a very interesting and healthy debate going on in the Agile Development world about Minimum Viable Product (particularly in startups). Before I get into the topic I’d like to address today, I just want to do some positioning and say that in this debate, I currently (but am open to being convinced otherwise) side with writers like Andrew Chen (read his excellent post, Minimum Desirable Product) and Jason Cohen (read Releasing Early Is Not Always Good? Heresy!). The other side is represented by posts like this one by Jeff Atwood: Version 1 Sucks, But Ship It Anyway.
While the debate is still ongoing, I’d like to write about a very specific related aspect, namely product development process (and those of us who would like to argue for fairly strict compliance to it). Two recent blog posts address the topic of compliance directly, and I wanted to reference them and then write a quick response on why I think process is so important, especially in agile development.
The first is Seth Godin’s Dancing with entropy. His rant on compliance actually inadvertently includes a pretty good description of what Product Managers do:
People are often paid to enforce compliance. The job is to ensure that everything is in its place, that errors are zero, that things are delivered on time and as expected. The random event is a problem, something to be feared and extinguished.
His main point seems to be that you should embrace the unknown, and “dance with it”:
Most people, though, the ones with great jobs, are in the business of dancing with entropy, not creating it. Take what comes, sort it, leverage it, improvise and make something worthwhile out of it.
I’m assuming he refers here to the definition of entropy as “a measure of the disorder or randomness in a closed system.” This is a great sentiment and we should all be able to deal with the unknown, but in practice, creating Ordo ab Chao during development can only happen effectively with proper product process behind it. You can’t dance with entropy without bug tracking, if you catch my drift.
The second is a post by Aslam Khan entitled Forced compliance is an obstruction to discipline. I respect him a lot for his forceful call for self-discipline in development, and I don’t doubt his sincerity at all when he writes:
Surely, we have learned enough from spectacular failures that governance does not give people an opportunity to exercise self discipline. When you give a person a chance to develop personal discipline, then forced compliance is unnecessary. With forced compliance, we force people into ignoring their own discipline because the system will “sort” it out for you. It breeds an attitude of “the system failed me and it’s not my fault”.
This is an ideal situation, and I agree with Aslam that personal responsibility is an essential quality for any developer — and PM, and designer, and human being, for that matter. But personal responsibility is just not going to get you all the way there. And by there I mean a product that is successful in the eyes of the company and its users. I’m not arguing for the perfect product — there is no such thing. But there is such a thing as desirable products that work the way they are supposed to and meet customer needs. And for that, you need more than personal responsibility.
It is a mistake to think that process/compliance slows down development or inhibits innovation. Compliance puts boundaries around what is within scope, and allows you to know when the product you’re working on is ready to launch. Compliance also doesn’t mean that you don’t trust your team, or that you think people aren’t capable of working on their own. It’s not about keeping tabs on people, it’s about making sure the product doesn’t get out of control.
By compliance I don’t mean an inability to roll with the punches and remain agile, but that a certain degree of process is needed. In an earlier post on the software product development lifecycle I go into more detail on what I believe is a good process for product development. I also discuss three outcomes recommended by Pragmatic Marketing: Requirements, Functional Specifications, and Technical Specifications. I do believe we need this level of process, and compliance to it, to build great product. We should embrace it, not fight it. You know, dance with it.