The current system for developing conceptual applications is broken. Many early stage entrepreneurs clamor to find developers that can build their product on a tight budget so they can get it in front of venture of angel funds for further development and proof of concept. These entrepreneurs consistently seek out a pool of developers that are few and far between: those that are willing to work exclusively for equity. This search typically results in two unsuccessful outcomes. The entrepreneur encounters an incompetent team that fails to develop a quality product, or the entrepreneur becomes frustrated and abandons the project entirely.

Why Does This Suck?

As a developer, I love new and innovative concepts. As an entrepreneur, I love disruptive ideas that can change the landscape of business as we know it. How many of these ideas meet with either of the two fates above? In today’s world of abundant talent and money, why do good ideas die without a fair chance to prove themselves?

I meet early stage entrepreneurs with cool ideas all the time. I want to help them, but they very often can’t allocate the budget to turn their ideas into reality. What results is a chicken or egg problem: the entrepreneur needs a product to pitch for funding, and the product developer needs funds to develop the product. What ultimately results is a dead idea that was never given the chance to get off the ground.

And Now…For Something Completely Different

What if a term sheet wasn’t in dollars and cents, but in developer time? What if VC’s wrote two checks – one to the entrepreneur and one to a recommended product development firm?

There are many intelligent individuals that are emphasizing the importance of building great products. In my opinion, the best people to build products are those that have done it before. If that’s the case, then, how many first-time entrepreneurs know how to build a product? It’s my claim that it is an investor’s fiscal responsibility to ensure the entrepreneur is connected with the right resources to develop their product.

Ideas like TechStars, YCombinator, and small, localized incubators and organizations have done a ton for the online startup community. Good luck getting into an esteemed mentorship program like TechStars without a developer on your team, though. All of the people around these ideas recognize the need for sound, technical talent, but rely on the entrepreneur to supply it! It is my belief that the investors can provide entrepreneurs with this talent as part of their investment. Whether they staff engineers permanently or furnish a recommended list of vendors, I believe the investors are more qualified to discern between developers that can deliver results and the unfortunate bozos that pervade our industry.

Why This Works for Investors

I consider the investors I know to be wonderfully connected and resourceful. They usually have a demonstrated track record of building successful products and companies. If I’m a first time entrepreneur, why not rely on my investors to connect me with a team of capable and efficient developers? As an investor, wouldn’t I want to be connected to developers that can make my portfolio truly shine?

If you’re connected to the best and battle-hardened developers, that creates a lot of value for your firm. Having engineers at your disposal to assess the complexity and costs of doing business during due diligence would allow for investigators to help discern between the money pits and the lean, money-making machines. Additionally, having an elite team that can get the job done right and fiscally efficient would allow you to cheaply evaluate business concepts.

Why This Works for the Entrepreneur

To say it matter of factly, entrepreneurs without software development backgrounds simply do not know how to hire solid, technical talent. If investors are helping to recruit and screen candidates, that really can increase the efficacy of such crucial hires. Not to mention, investors can train and mentor entrepreneurs on what to look for in a sound, technical hire to sustain future growth.

When entrepreneurs get funding and can make hires, do they really know how to evaluate a potential engineering employee or contractor? Potentially, a seasoned entrepreneur with a product development background may have a list of contacts to reach out to when they become flush with cash. How many first-time entrepreneurs, however, waste valuable time and money on incompetent people that don’t bear any fruit for their clients?

In early stages, most business-oriented founders want to focus on strategic partnerships and sales, anyhow. While there’s an increasing and encouraging awareness of how important your first technical hire is, it’s not something a first-time founder is really equipped to do.

Why This Works for the Development Community

There are a lot of bad developers out there that sustain themselves on unsuspecting, first time ventures. In a world where investors help to build a sound framework for screening candidates, these bad apples fall out of our industry. This effectively would raise the bar for everyone in the field, which would make the most meritorious developers more valuable and respected. Good developers would no longer have to tolerate those that didn’t carry their weight because they simply wouldn’t be found on the same team together. This would result in higher job satisfaction and retention, in addition to better output and creativity.

Additionally, developers love new projects and business problems to solve. If the investment community could provide a capable and elite team with a continuous supply of cool concepts, I bet you’d have a happy team of developers.

The Grass is Always Greener

I’m not necessarily knocking the present state of affairs. I can certainly understand why investors don’t want to manage the hiring process to this extent, and why certain entrepreneurs would view this type of involvement as intrusive. My intent here, is to raise the point that investors usually have the know-how to assist entrepreneurs with their product development efforts, and that they should use that know-how to the benefit the value of their portfolio and benefactors.

That being said, there’s also the issue of observing how a team stands on its own, which is probably the strongest case against this model. The development team sponsored by the investor won’t always be there, so it would be important to recruit and phase in a technical cofounder at some point in the product’s development. An investor might not want to finance this endeavor, and they generally want to invest in a full-strength team from the onset.

In the end, we’re in unfamiliar territory. Perhaps all we need is a better way to match good developers with promising teams and ideas. Brain power and attention are becoming the scarcest of resources, and my desire is to create the most efficient economy to maximize the outlay of these resources. The idea, the founder’s passion, the developer’s capability, and the investor’s money are all necessary to create successful products, so let’s all work together to optimize what results.

Update: Nick Plante tipped me off to a company trying something like this named SproutBox.

SCRUM is a great framework to adopt if you and your software development team wants to get things done. SCRUM works for us, so we encourage the people we work with to adopt it along with other Agile methods.

Here’s a few reasons why we like it:

• SCRUM can get you the highest business value in the shortest amount of time, assuming your priorities are right.
• It makes the release of your software less of a technical problem and more of a business decision
• It helps to project the amount of value your development team can deliver over a finite period of time
• It helps keep your development team and your product flexible so that it can change with the long-term needs of the business

We try to help all of our clients refine their product development process, so we’ve seen a few roadblocks that get in their way when adopting SCRUM. These are the top 5 ways to cause a SCRUM misfire:

1. Too Much, Too Soon

   Traditional development shops sometimes try to change their ways overnight. If you overwhelm developers with sweeping changes, it’s unlikely that everything will stick. There are many aspects to SCRUM and Agile, so why not take it one step at a time? First, you could start writing user stories. Second, you could start time-boxing your release plan. You can spread out the adoption and sell each facet of SCRUM on its own merit. Being a curmudgeon myself, I respond to change much better when it is spread out over time.

2. Being dogmatic and following the procedures to the letter

   SCRUM is a framework, not a dogma. It annoys me to no end when people criticize others for not having an “up to the letter” implementation of SCRUM. If you’re not changing your ways from iteration to iteration, you’re missing a lot of the benefit that SCRUM provides. During your retrospective, discuss what’s working and what isn’t. Change your ways for the next iteration, and see if things improve. Every company’s culture and operations are different, so why should you try to fit a round peg into a square hole? Bend SCRUM to your team’s will, and find what works for your organization.

   That being said, a lot of people think SCRUM is about having an open floor plan or rapidly changing requirements and development priorities without forethought. If you do only these things, you’re not practicing SCRUM or reaping any of its benefits.

3. No executive buy-in

   We’re getting warmer. It is so important to have C-level support for the long-term adoption of SCRUM and Agile methods. Take considerable time and effort with getting your executive team on board. When you miss your last few stories in a sprint (it will happen), your management team needs to understand the complexity and uncertainty around sprint planning, and how you already have a plan in place to address it.

4. A Bad Product Owner

   I’ve unfortunately seen this more times than I’d like to admit. Bad product owners mean bad user stories and priorities, which translates to sprints that miss the mark in terms of business value. Naturally, if stakeholders and board members aren’t seeing the results you’ve been promising, SCRUM will be forgotten as quickly as what they had for lunch two weeks ago. In the early stages of trying SCRUM out, work with your product owner intensively to make sure he or she is doing a good job of getting the right stories and priorities from stakeholders. If they can’t get make it work within a few sprints, you’ve got to respond quickly and find someone else to fulfill this important role.

5. Split Focus

   So you’ve got this great idea for implementing a framework where you can demonstrate predictable and reasonable estimates of what your team can do in a given slot of time. Your team members, though, are on about 4 different project teams and have their quarterly TPS reports due somewhere towards the end of the sprint. In my opinion, resources that are spread across multiple projects is the #1 cause of SCRUM death in an organization. Fight for your resources! If you can’t get a predictable and dedicated amount of time from your SCRUM team, how can you get can you accurately gauge velocity? If everyone has to work on multiple projects (which is a horrible idea), see if you can get them for dedicated times for every sprint. This will be really hard to do as the project priorities shift and fires need to be put out, so this should be a last resort. If you have some pull in the company, see if you can try restructuring project teams to be more dedicated. Nothing is more important for the successful adoption of SCRUM than protecting your team from distractions and the ever popular “Can you do me a favor?”. As a technical leader or someone that wants to see your product and SCRUM succeed, this is the battle you want to pick.

Are you struggling to get SCRUM working for you? What’s killing the adoption of SCRUM in your organization? We’d love to hear from you in the comments.

Happy Friday! This week’s enlightenment brought you by the lovely JavaScript framework JQuery. If you like unobtrusive and functional javascript utilities, you really have to check it out. A while ago, I converted from prototype and haven’t looked back. I even built a plugin to help with our development process called under_construction. Use it to overlay or hide elements of page that haven’t been implemented yet.

• Achieving Rounded Corners in Internet Explorer for jQuery UI with DD_roundies – this was an effective technique for getting rounded corners to be respected in Internet Explorer. I used the DD_roundies library in conjunction with the rounded corners plugin
• Tips for Writing Better JQuery Code – loaded with great tips on optimizing your javascript
• Write Desktop and Mobile Apps with Bowline – I played around with this a few days ago and I really like it. If you consider yourself well versed in Rails, HTML, and JQuery, I highly recommend you check this framework out. I’m hashing out a few OS X applications without a single reference to NSWindow – crazy!
• Have google load JQuery for you – this has made it into my upcoming Rails Template – save on bandwidth costs and get snappy delivery of your javascript libraries via Google’s Content Delivery Network

On an off topic note, I’ve been using RescueTime and Concentrate.app to help maintain productivity. A blog post on Concentrate.app is forthcoming

I’m going to regularly post links, discussions, and tips I’ve found helpful every Friday.

• Version 2.3.3 of Ruby On Rails is Released – includes improvements to JSON and a touch command that allows you to update the updated_at timestamp for associated objects
• Timecop – a really awesome gem that makes it easy to mock time related functions
• JQuery Rounded Corners – I might be a bit late to the party on this, but rounded corners are so Web 5.0. Seriously, though the browser support for this plugin is impressive. I also like the api.
• Giles on “Magic” Frameworks – I hear from a lot of programmers outside of the Rails community that it does too much “magic.” Giles’ thoughts are extremely poignant. I look at it this way: you drive a car every day. You put gas in it, get oil changes, etc. I don’t know everything there is to know about what’s under the hood, and chances are, neither do you. You have common interfaces with the automobile and all the smaller details have already been manufactured and put in place for you. A framework is definitely similar. Would a mechanic tell you that you cars run on “magic”? If you don’t understand something, that doesn’t make it magic.
• Huddle’s Thoughts on Bootstrapping the development of a web app – Although I have to disagree on the usage of Elance, Guru, or design contests, there’s some good tips here. I’ve rescued many projects for clients that attempted to use inexpensive resources like those found on Elance. There is a similar lapse in quality when you run design contests. Credible and reliable help in building your application is the best investment you can make for your online property.

Jon Follett and I did a lightning talk on swooping in to save projects from epic failure at Ignite Boston 5. It seems to be a topic that the audience had an interest in. We looked at our experiences and set out to provide some useful tips.

We had 5 minutes to get our points across. It was challenging but fun. It was a great event and there were lots of other great talks.

The slides are below.

To place further emphasis on the message – communication is a vital part of every project. We’ve inherited so many projects going wrong just because people aren’t being honest and open with each other. Communicate to educate, define norms, and demonstrate progress. These are not nice to haves in your projects – they’re requirements.

Do you have a project that needs rescuing? Contact us so that we can make your software idea a reality.