Category: Agile

Why Entrepreneurs, VC’s and CIO’s Love Agile & Prototyping for New Products

Last Friday we had two great meetings that have confirmed that Agile development practices and product prototyping are going to be web entrepreneur’s most valuable tools in the coming years. The release early, release often methodologies of Agile and Scrum combined with the velocity that you can create work with prototypes is totally disrupting new product development cycles. What we heard in these meetings was pleasantly surprising.

The first meeting we had on Friday was with Jo Tango, founder of Kepha Partners, and self-proclaimed “business builder”. Jo and his team manage a $100 million fund which is aimed at very early stage ventures across several markets. What was surprising for us to hear from Jo is that he’s looking for entrepreneurs that are spending more time working on a prototype than they are on their presentation decks. “We’ve invested in teams that have a 2-page PowerPoint and an awesome demo”, Jo told us. We too have heard too often from VC’s and investors that an entrepreneur’s deck and pitch can make or break their chances of getting funded. Jo disagrees with that approach and focuses on what startup founders have already created, whether it’s perfect or not. His team is looking for iterative traction from a demo or beta release not a fancy PowerPoint.

The meeting that followed was a short but fruitful conference call with Medtronic CIO, Mike Hedges, and his application development team. We’re currently designing an app for Medtronic that will be disruptive to their primary market of pacemaker sales and support. We’re using our hybrid of Agile and prototyping to get this big project done in digestible bite-size pieces. As we talked about using this approach for several upcoming projects, Mike reminded us, “no need to talk about Agile and prototypes. You’re preaching to the converted”. Old habits are hard to break. Until recently we felt as if preaching about Agile and prototyping was falling on deaf ears.

The alternative to this approach is what most tech teams are used to: a long series of meeting to decide what to do, impossibly trying to predict obstacles, writing bible-length tech specs, working with frustrating offshore resources, endless QA cycles and launch delays. Traditionally large companies, like Medtronic, have relied on other larger companies, like IBM and Sapient, to deliver end-to-end technology solutions. Now it seems those companies move too slow for them. Application development teams are looking for small, nimble partners that can iterate and update prototypes on an almost daily schedule.

In the real world, the landscape and markets are always changing. By the time you have completed the first round of development, you’re already behind the changes the market is absorbing. That leaves you with obsolete features and dissatisfied end users. In Agile development, you build small pieces, test them and let the feedback guide you to the next small piece. By ensuring units are kept small Agile development can help mitigate many of the issues that case large unmanageable applications to emerge.

So if you are an entrepreneur and you’re trying to launch a web project what should you be thinking about?

  • Team work: Every project we do has two or more UI experts working on the same designs so we can double check our own work. Never have one person doing the thinking in a vacuum. A designer sitting in a corner trying to figure out the complex user iterations for each story is a disaster waiting to happen. Small nimble teams with open spaces work better than overly funded all-star teams. You’ll be surprised by what Agile and prototyping can accomplish. Our team recently prototyped an entire 50-plus page application in 2.5 days.
  • Keeping everything small: By keeping the design and development teams small and by breaking big problems into small problems we eat the elephant much quicker. Trying to solve big problems by having big meetings with lots of senior level people only slows things down. In one recent case we were able to double the pace of delivery by reducing the client team to four people from the initial ten. Informal and small teams make the process much more flexible and agile (with a small ‘a’). Changes can be made quickly without breaking related elements or upsetting the course of action.
  • Tracking and accountability: We use Basecamp as a management tool. I’m not a big fan of complex project management tools. Basecamp is super simple and doesn’t encourage you to add unnecessary complexity. If you can’t break down the project into small stories and tasks there is no system on the planet that will help you track your daily work. Basecamp to-do’s allow us to immediately assign responsibility for each task and to follow up each morning during our Universal Backlog reports. Constant feedback on where we are on the overall task lists make it  easier to make higher level decisions maintain focus on the product vision or mission.

Hybrid Development Insights from Janeiro

Justin Bingham is one of those guys that never disappoints with his insight into development. In a series of posts on his new blog he clearly outlines the advantages and pitfalls of hybrid development practices. What I really like about the detailed descriptions he offers is that he combines both the technical and the psychological aspects of managing and delivering a successful project. It’s easy to follow a step by step methodology. On the other hand being empathetic to client and team needs while still being alert to bullshit gives you serious advantage over just following process alone. This except hits at the core of Justin’s point…

Respect your Bullsh*t Meter. Some people will say just about anything to get your money.  You can ask all the right questions, and still get fleeced if you don’t listen carefully to the answers.  Look for any elements of inconsistency.  If someone tells you that they adhere to agile development practices, ask them later on in the conversation how long they usually spend putting together their technical specification document before they start coding.  This is a lot like being at a party and having someone tell you how much they love the movie that you were just talking about, and then later dropping an obvious reference and watching it sail over their head.  Steer clear of these people, and steer clear of these firms.  They’ll say anything to get you to like them.  Don’t be afraid to tune your meter if you’re having trouble identifying them.

Twitter Updates

Latest from the Blog

Get in touch

We'd love to hear from you - let's talk about the possibilities for your project and how we can help you get the results you need.