SocialStartups.com

Disclaimer: I have no idea if this works. I thought of this last week as I was walking around with my friend Bre and decided to post it here to get feedback. There are many people who have had far more software development management experience than I have, and I’m very interested to know if they think this idea could work at all.

Summary

Prototype Driven Development (PDD) is a software development methodology that believes that by continuously creating, improving, and interacting with prototypes, software will be launched faster, with higher quality, and with a stronger focus on the customer. This is accomplished by using cross-functional teams to continually iterate on prototypes of gradually increasing fidelity while constantly absorbing input from the team and others.

Waterfall and Scrum

What is Waterfall?

The waterfall method of software development is a monolithic system created at a time when building and testing software was costly – punch cards had to be made or hardware had to be redesigned, so it was critical to figure everything out early in the process because any feedback could be gathered.

The waterfall process looks like this:

At each step, if a problem is discovered or the context of the project has changed, control of the project is routed back to the top of the waterfall.

See http://en.wikipedia.org/wiki/Waterfall_model for a more in-depth discussion.

The traditional waterfall process of software development doesn’t work because it:

1. is very slow and heavy weight (months to complete projects)
2. silos creativity between product, design, and development
3. expects impossible levels of foresight from product (and at times, design) to avoid going backwards and revising all of the documentation
4. creates lots of documentation that never gets read once the project is complete since maintenance fixes end up changing or adding to the requirements and design
5. does not provide sufficient progress visibility for senior management.

What is Scrum?

Scrum is the idea that by squeezing the development cycle down from 2-4 months to 2-4 weeks, the development process is less prone to estimation errors and more likely to ship higher quality code faster. The team works off of a backlog of features, with each feature small enough to be accomplished in a matter of days or hours. By reducing the size of a feature, Scrum teams can more quickly react to changes in prioritization and provide more visibility for management into what is done vs. not yet finished. The team has a daily standup, where each person outlines what they did yesterday, what they are doing now, and what blockers they might have. Each person also updates a document describing how much effort is remaining for each of the tasks assigned to them.

The Scrum process looks like this:

See http://en.wikipedia.org/wiki/Scrum_(development) for a more in-depth discussion.

Agile methodologies like Scrum don’t work because they end up like waterfall, just on a smaller scale. Instead of 2 months each of requirements, design, development, and testing, you have 2 weeks of each. This is because there is typically a “cycle zero”, where product and design do a fair amount of planning before launching into the first sprint. This cycle zero is basically the first two steps of the waterfall method. Agile does, however, address some of the problems of waterfall:

1. is very slow and heavy weight (months to complete projects) Medium weight as the team can react from sprint to sprint (2-4 week cycles)
2. silos creativity between product, design, and development Product, design, and development meet for a scrum standup every day, so there is frequent communication. Requirements are still created upfront by product and design, outside the Scrum process.
3. expects impossible levels of foresight from product (and at times, design) to avoid going backwards and revising all of the documentation Foresight is still expected from product / design, but at least the cycles are shorter (2-4 weeks) instead of months.
4. creates lots of documentation that never gets read once the project is complete since maintenance fixes end up changing or adding to the requirements and design No documentation is needed because of frequent communication. The time and effort spent writing documentation is funneled into making better product
5. does not provide sufficient progress visibility for senior management. Senior management, at the end of every sprint, theoretically can see a demo of what was worked on. “Potentially shippable code” is the phrase Scrum uses.

Prototype Driven Development

PPD puts usability and adaptability first. By constantly iterating off of a prototype and folding in input from the team, internal users, and usability tests, a product can be created quickly and with high quality.

With PDD, 1-3 engineers meet with a product manager and a designer to kick off a project. The team sits down and discusses the general problem and spends some time (no more than two hours) coming up with the general framework of a solution. It doesn’t matter that the solution isn’t optimal and most details haven’t been figured out. Often times this vague idea comes along with a pencil / whiteboard sketch of the UI.

The team disperses. The developers go and implement the most barebones prototype of the idea – black and white, fake data, no CSS, stubbed code, just enough to start a conversation. The product manager and designer start working on prioritized user stories, interaction design, etc.

The next day, the team meets and presents their work to each other. The devs show off their crude prototype. The product manager presents what she think are the most important activities the product needs to support. The designer lays out his ideas for layouts, user flows, etc. Each idea is vetted by the group and consensus is established. Maybe the product changes direction or maybe one particular use case becomes more important. The team then goes back and iterates again, improving the prototype or design or requirements.

This meeting happens every day at the same time. Each day, there is more clarity than the previous day because the crude prototype continually evolves into a more mature product. Each day, the team is interacting with each other and with the prototype, adjusting course as necessary. Each day, senior management can come in and interact with the prototype and react to it. At any point, the call can be made to lock down the feature set and drive towards launch.

The key point here is that prototype driven development forces everyone involved to focus on the primary activity being modeled by the feature. There isn’t time at the beginning to fuss about colors or CSS since there is only one day to make the prototype a bit more accurate. Each day, the team is evaluating the usability of the prototype, trying it out or asking others to evaluate it. Only when the key activities have been fleshed out will attention turn to the details.

To follow up on the five failures described above, here’s how PDD scores:

1. is very slow and heavy weight (months to complete projects) Medium weight as the team can react from sprint to sprint (2-4 week cycles) Super lightweight process that can adapt daily
2. silos creativity between product, design, and development Product, design, and development meet for a scrum standup every day, so there is frequent communication. Requirements are still created upfront by product and design, outside the Scrum process. No silos because everyone is contributing to the creative process every day.
3. expects impossible levels of foresight from product (and at times, design) to avoid going backwards and revising all of the documentation Foresight is still expected from product / design, but at least the cycles are shorter (2-4 weeks) instead of months. The team is course correcting every single day, so the cost of trying something is very low and philosophical arguments are minimized.
4. creates lots of documentation that never gets read once the project is complete since maintenance fixes end up changing or adding to the requirements and design No documentation is needed because of frequent communication. The time and effort spent writing documentation is funneled into making better product No documentation, other than an interactive prototype that is available immediately.
5. does not provide sufficient progress visibility for senior management. Senior management, at the end of every sprint, theoretically can see a demo of what was worked on. “Potentially shippable code” is the phrase Scrum uses. Senior Management immediately has a prototype to evaluate and react to.

Discussion

PDD requires great people. The product manager has to have a relentless focus on the primary goals of the product to avoid feature creep. The designer must be available every single day and be willing to create and throw away many iterations of their work. The designer must be able to work quickly, in low fidelity, and in an environment with ambiguous requirements. The developer must have high levels of comfort with prototyping code, stubbing out code / faking data, and a willingness to edit and throw out lots of code. PDD is like collaborating to write a comic book – there will be lots of editing of the storyline, the graphics, and the words themselves.

Prioritization is outside the scope of PDD. It is assumed that prioritization has occurred, and the team is being tasked with executing on a prioritized project.

Where is QA? I’m not sure. Flickr doesn’t have QA. I think QA can sit side-by-side with the developer and do some variant of Test Driven Development – http://en.wikipedia.org/wiki/Test_driven_development. In this situation, the QA engineer is writing test cases for the specific feature of the prototype the SDE is currently implementing. Since requirements can adjust day to day, the QA engineer needs to be as flexible as the rest of the team in editing their work daily.

Customer forums are always interesting, particularly for e-commerce sites. There is something about staying at home and being bored that ultimately leads people to “window shop” online, which leads them to socializing with other people who are doing the exact same thing. The range of personalities is wild and wildly interesting.

Four hundred and twenty eight posts ago, I started a thread on the Etsy forums. The thread was intended to have two purposes. One was to simply get a sense of the community and introduce myself to them. Second, I wanted to get some better intuition as to how sophisticated Etsy sellers (the majority of forum posters) are about running their business and the e-commerce business generally. So I asked a basic prioritization question – would you rather us make search better or fix a bug that would occasionally reset the page views counter on your item listing pages? (For those curious, the views system is stored entirely in a cache, and when the cache gets full and a record gets evicted, the page view number resets to 0. Clearly, the system was not engineered to be used in this manner.) My follow up was, if fixing the view system is not a priority, would you rather we get rid of it entirely or keep it broken.

The danger is to get lulled into an urgency to please. When hundreds of users are demanding a feature, you may feel compelled to acquiesce and build the requested feature. Before you do that, stop and consider Henry Ford: “If I did what people said they wanted, I would have built a faster horse.” (or something like that.) Customers are excellent gauges as when something is wrong, but can be extremely misleading about both what exactly is wrong and how it should be fixed. Furthermore, customers do not (or should not) have better visibility than you do into strategic goals, key business metrics, engineering resources, etc. They don’t have your long-term vision nor your understanding of complex dependencies. So don’t jump the gun. Listen, follow the comments to the source, and solve the root of the problem.

While on the subway heading back to Brooklyn – I had gone to see Iron Man at Union Square, it was great – I was thinking about Microsoft. I was trying to imagine what exactly Microsoft could do that 1) doesn’t have an entrenched player, and 2) they might be able to be successful at. Search the Google way, in my opinion, does not satisfy either requirement, even if they bought Yahoo. So what else?

I considered Tim O’Reilly’s suggestion of investing in pieces of an “Internet Operating System”, which could be the answer although they’d have to fight Amazon, Google, Cisco and others for the bragging rights. Requirement (1) no, (2) yes.

I considered gaming, hardware, healthcare, social networking, and others…. but Microsoft is always involved there with mixed success. Is there anything left?

I’ve got a crazy suggestion. And yes, your own personal blog is the perfect place for crazy suggestions. So here it is – Microsoft should work to be the #1 destination site for vertical searching of the “organic web” (I just made that phrase up). The organic web would be defined as information that is continually changing. One example is airline ticket prices. Another is real estate, and another is classifieds. Microsoft should go out and develop / acquire any company who currently has the following properties: (1) The relevant data changes continuously, (2) The site is a leading player in their vertical, and (3) search is the main user activity on the site. Examples I can think of are Farecast (they bought this one), Craigslist (good luck there), and Redfin. With insider access to the data, Microsoft could provide superior search experiences to Google. Microsoft could then create a search portal that would be the first place everyone would go to search for data in these areas. Google’s crawlers can only go so fast – if Microsoft could provide a “real-time” search engine customized to a particular vertical, they could differentiate themselves in a very powerful way.

That’s it, keeping it short tonight since I’ve got a meeting in 10 hours with the CEO, COO, a few others.

How Thinking Costs You – washingtonpost.com

Found this via Paul Kedrosky’s Weekend Reading post.

Really interesting stuff – given that people are really bad at making correct stock market predictions, the more information they know, the worse they perform.

Behavioral economics studies these phenomena, and firms are counting on it.

I wonder if this is true in other areas as well, like deciding on how to price items for sale on Etsy.

Tags: behavioraleconomics, pricing

Google’s Response to Facebook: “Maka-Maka”

Amazing, I was just writing up something like this yesterday. I said:

For good measure, you could also add in GPhone data – who is in my address book, what I’m saying over SMS and phone conversation (transcribed into text via a service like Jott), and my location. The only part (and I admit it’s a crucial part) that I don’t understand is how Google will benefit by “out-opening” Facebook. My guess is that more data = googly goodness. Google will know more about you if you take Google with you, or bring the places you visit to Google.

Blogged with Flock

Tags: Google, social networks, platform