Scrum for Venture Capital Companies

 

As I mentioned in a previous post on the adoption of Scrum outside software development and into general business practices, I ran into this article from the IEEE about a venture capital firm called OpenView Venture Partners, which is a division of OpenView labs that incubates and funds startup software companies.

According to the article, adopting Scrum throughout their business processes allowed the group to double their productivity, while working fewer hours.  Scrum is used as a best practice framework for their project consulting services, sales, marketing, finance and customer support for their portfolio of companies.

As illustrated in the Maxwell Curve, coined by Scott Maxwell who is a principal founder, assuming a team member can take on approximately 20 perfect hours a sprint, the starting velocity for a full work week starts at 80, with the equivalent focus factor of 50% utilization for a 40 hour work week.  Unplanned stories are tracked seprately.

Due to this, the team at OpenView realized that using perfect hours instead of story points implied that the measured velocity can only increase if:

1. The team removes impediments that increase the focus factor on the stories (spend less on overhead and more on value add tasks)
2. The team works more hours

Additionally, continuous improvements and impediment removal can decrease the amount of time spent on individual stories by shrinking the story size while simultaneously increasing the output of work with no increase in the Sprint's velocity.  As time goes on and more iterations are completed, productivity increases which creates a culture of working less hours and no weekends.

For venture capital firms, investors will typically drive startup companies to work harder and longer to get a quicker ROI on their investments which leads most companies to work well beyond the 40 hour work week.  Scott found that due to Scrum's intensity, the peak of production waned after 50 hours, so he insisted the teams to work at a sustainable pace and avoid night and weekend work.  But from his analysis, he did expect that the production of work would double.

According to the article, this focus on higher velocity in perfect hours with less actual hours worked, compelled the teams to remove obstacles, overhead and communication gaps and to increase story clarity so as to increase the number of perfect hours completed.  This allowed them to acheive double productivity of work while working less hours.

This is not to say that they did not experience challenges.  Some of the most notable where:

• Aggresively removing impediments without doing root cause analysis lead to extra work
• Some critical impendiments required reorganizing the company to resolve them
• Estimating in hours made it impossible to know actual velocity and to access process improvements
• Scrum just did not work for some individuals, as some people were so individualistic that Scrum killed their productivity causing the productivity of the team to diminish in tandem

Though I can't verify the truth of their claims to Scrum's productivity increases, I have witnessed similar increases in Scrum projects (or projects using Scrum/Agile-like techniques) I've lead or been involved with and this was when I had the kind of organizational and upper management support that OpenView had articulated in the article.  It is interesting to see that Scrum is being adopted outside software development and getting the kinds of productivity gains it is famous for.