Organizational Transformation with Scrum: How a Venture Capital Group Gets Twice as Much Done with Half the Work

Transcription

1 Organizational Transformation with Scrum: How a Venture Capital Group Gets Twice as Much Done with Half the Work Jeff Sutherland, Ph.D. Scrum Training Institute jeff@scruminc.com Igor Altman OpenView Labs ialtman@openviewpartners.com Abstract OpenView Venture Partners is a venture capital fund that uses Scrum as best practice in software development and for project management in all other parts of the organization. OpenView is the first highperformance non-software Scrums that has documented twice as much value produced in fewer working hours. The model at OpenView provides a working manual on how to do Scrum outside of software development. Their aggressive removal of impediments (take no prisoners!) distinguishes them from Scrum implementations that are captive of their institutionalized waste. The founder of OpenView saw that maximum productivity in Scrum occurs at a sustainable pace with less hours of work per week than without Scrum. He set the goal of reducing hours of work while doubling production and the Scrum teams exceeded his expectations. Focus on removal of impediments led to reorganization of the teams several times a year and showed how to capitalize on Scrum as a powerful organizational transformation tool. 1. Introduction We introduce a successful model for implementing Scrum throughout at organization. At OpenView Labs, a division of OpenView Venture Partners, we support a growing number of portfolio companies using Scrum for all our work. Our teams support more than software development. They use Scrum as best practice for consulting projects in management, sales, marketing, finance, and customer support for portfolio companies. Their Scrum implementation is repeatable, proven across many projects, and recommended for teams in all areas of business. Previous work on organizational Scrum was documented for a professional services firm [1]. Using a Type C Scrum model developed by the author [2], new responsibilities, teams, and interactions settled into patterns of self-organized (and mostly self-optimized) behavior. Customer alignment improved, teams were empowered, innovation and creative energy were released and focused to the betterment of customers projects. Most important, project results improved, quality issues were identified internally before customers were impacted. Dramatic scaling of the organization occurred without negatively impacting the benefits accruing from the model. This model was so effective administrative and operational support departments also adopted Scrum. One year later, the professional services firm underwent dramatic reorganization and reported Scrum was driving innovation and leaning out the organization [3]. Lean initiatives were more effectively implemented by Scrum than traditional approaches. The CEO had daily standup meetings and the services organization introduced organizational Scrum to client companies. More recently, a Senior Minister reported on implemention of Scrum in churches in four regions of the United States [4]. Benefits were increased transparency, siloed specialists beginning to work as a team, clarity and focus, iterations and continuous improvement. However, the most significant impact of Scrum was its use as a tool for organizational change. The theme of organizational transformation is dominant in Scrum implementation outside of software development. Here we report on what happens when a team of highly organized institutional development experts in a venture capital firm implements Scrum. They include every employee in the venture group, aggressively eliminate all known impediments, and drive Scrum into all portfolio companies. Their rate of institutional transformation accelerates dramatically. A complete reorganization of OpenView Labs occurred 4 times since Scrum implementation began in January of 2008, with corresponding improvements in velocity and quality of production The Context OpenView Venture Partners was founded in 2006 with nine team members and an initial $107M investment fund. A second fund was closed in A new kind of venture capital fund, OpenView provides hands-on operational value to each portfolio company in addition to investing in the best software companies and taking seats on their Boards.

2 By third quarter of 2007, the OpenView Venture Partners core team grew to thirteen professionals, and an investment portfolio of six software companies. The new portfolio companies brought high demands for value-add projects from the operational experts. Long work hours that extended into late nights and weekends became common. The combination of new value-add projects, unprecedented deal activity, and new team members resulted in OpenViews s founder, Scott Maxwell, having to spend increasing amounts of time managing individuals and their projects within a flat hierarchy. OpenView decided to shift a team member from the investment effort to create a new organization, OpenView Labs, focused entirely on value-added projects with portfolio companies and due diligence on new investments. This helped, but the answer to scaling OpenView over the next 12 months while reducing the time Scott needed to devote to managing people and increasing the value added to each portfolio company remained elusive OpenView Meets Scrum OpenView first encountered Agile Development when we invested in VersionOne, an Agile Project Management tool company ( Most OpenView team members thought Agile relevant only to software development and never considered it for internal consumption. This perception changed after Jeff Sutherland [5] met with Scott Maxwell. In Scrum, Scott saw simple principles and ideas that could be applied to make OpenView more productive and selfmanaged. A few months after the meeting, a Scrum Master Certification course for everyone completed the introduction of Scrum into OpenView Venture Partners. Here we describe two phases of Scrum adoption by OpenView during 2008: Phase I Getting Started with Scrum Phase II - Scaling up Scrum Phase III was implemented at the time of writing of this paper and caused a reorganization of Scrum teams. High team velocities caused the Product Owner function to be a bottleneck and forced restructuring. Phase IV has begun while finalizing this paper. A less organized team was disbanded and members put on self-organized Scrum teams. The rate of change resembles the speed of refactoring seen on high performance software teams. Phase III and IV will be topics for a future paper. 2. Getting Started with Scrum: Trial by Fire Phase I of our Scrum implementation started with a one week sprint in January Team structure Two Scrum Teams were formed, the OpenView Labs value-add team and the deal team that searches worldwide for new company investments. (NOTE: The rest of this case study will focus only on the OpenView Labs team) Four people formed the Labs team and three people were on the Deal team. Each team had its own ScrumMaster, though in both cases the ScrumMaster is a key member of the team and is in the critical path working on Sprint Backlog. Sprints were established at one week lengths, from Monday through Friday Product Ownership & Backlog Scott Maxwell, the founding partner, is Chief Product Owner, although the OpenView Labs Scrum team is effectively a Product Owner Scrum Team as well as an implementation Scrum team and generates the majority of the stories, with the Chief Product Owner adding a minority of the stories and prioritizing the entire backlog. The Labs team originally had a story backlog in an online spreadsheet in Central Desktop ( a hosted collaboration tool and an OpenView portfolio company. The backlog is a collection of each team member s individual projects in progress. The OpenView Labs Scrum team focused on three objectives: Execute operational value-add projects for OpenView s portfolio companies. These projects are coordinated by OpenView senior point people who also sit on the companies Boards and are outside of OpenView Labs. Execute due diligence on OpenView prospect portfolio companies. These projects are coordinated by the deal team. Execute projects to institutionalize and build out OpenView s value-add capabilities. These projects are coordinated directly by the Chief Product Owner. Value-add projects for each portfolio company are discussed at the Monday morning Investment Committee meeting that includes all the portfolio company OpenView senior point people and Labs senior team members. Labs team members both add projects and receive them Stories Stories were vague and unclear in this early phase of Scrum adoption. Definition of done was different for every story and typically unclear.

3 Understanding the specifications of each story took a lot of back-and-forth discussion during the week between the Labs team members, portfolio companies, the senior point people, and Scott Maxwell, our Chief Product Owner Sizing and Planning The Labs team has a Sizing meeting every Monday where stories for the next sprint are sized and unclear stories are sent back to the product owners. Sizing is done in perfect hours. This is the amount of hours it should take an average team member to complete the story under ideal conditions with no interruptions. A perfect hour is only counted as done if the entire story is done. Perfect hours are used instead of points because: They are conceptually easier for the team to understand A significant number of Labs stories are timebased, like meetings, calls, and time-boxed research stories This measurement creates an ongoing problem in determining velocity as there are no standard reference stories that are stable in size. Sizing is done in a fashion similar to planning poker. On a count of three, each team members indicates using their hands how many perfect hours they think a story is, and differences are discussed. No story should be more than two days of work. After sizing, Scott prioritizes the stories, and the Labs team indicates which stories it plans to get done this sprint. The Labs team then plans the stories, breaking them down into tasks, identifying dependencies and impediments, and team members decide which stories they will do Daily Scrums Each team has a daily Scrum. In the meeting, the Scrum Master asks each member: What did you do yesterday? What will you do today? What are your impediments? Everything is run off of the online spreadsheets in Central Desktop Retrospective A retrospective is held every Monday morning to review last week s sprint. The team discusses what went right, what went wrong, and determines what the team can do better Velocity Initial velocity is estimated by assuming that each team member can take on approximately 20 perfect hours per sprint, giving Labs a starting velocity of 80. Thus, velocity is really equivalent to a focus factor of 50% for a 40 hour work week [6]. Unplanned stories are tracked separately. Figure 1. Scrum gets more done with less work Velocity stays relatively flat at around 80 from sprint to sprint. The Labs team takes on too many stories and does not complete all tasks in Sprints successfully. The team and Scott recognize that using perfect hours instead of story points means that the measured velocity can only increase if: The team removes impediments that increase its focus factor on the stories (i.e. spend less time on overhead and more time getting high impact work done) The team works more hours Furthermore, improvements and impediment removal that decreases the amount of time spent on individual stories simply shrink the story size and increase the amount of work the team can do in the same amount of time without increasing the velocity. Yet the team is comfortable with these issues and continues to use perfect hours. Within months, as the team s productivity improves and more gets done in less time, Scott initiates a culture of working fewer hours and no weekends. Within a few months, our founding partner had discovered that Scrum can double output by working less. He introduced the concept of the Maxwell Curve (note: The numbers on the curve do not represent actual data, but are there to help explain the concept). Investors typically drive companies to work hard and long as the peak of production in a traditional company requires more than a 40 hour week. Our teams were typically working well over 50 hours a week, working

4 late and on weekends. But Scott noticed that Scrum is intense. The peak of production is probably less than hours a week. So he instructed the teams to work at a sustainable pace and avoid night and weekend work. At the same time, he set the expectation that production would double. Ultimately, the focus on higher velocity in perfect hours with less actual hours worked drives the team to remove overhead, communication gaps, and increase story clarity to increase the number of perfect hours completed Benefits While the Scrum implementation is far from perfect, benefits emerge immediately. The team is now selfmanaging, and Scott s time dedicated to managing individual Labs team members and projects drops. Communication within the Labs team goes from virtually zero to a significant level. Communication saturation is a key indicator of productivity [7] on teams and a strong feature of Scrum. Once each team member s projects become transparent to the team, about 30% of projects are seen as low value and eliminated, making more room for high value projects. Many impediments emerge and are removed. Early on, each impediment is easy to remove and removal has a high impact on improving the productivity and quality of life of the team members. Common impediments include lack of clarity, lack of communication, and low value work. A common issue is that a given project is producing lots of outputs that no one cares about and is not producing the few outputs that people do care about. This issue is resolved by the Scrum team clarifying each project, and the ScrumMaster scheduling calls with stake holders of each project and zeroing in on its exact requirements. While team members are still working as individuals, they start helping each other, and some collaboration develops. Team members who were overwhelmed with working projects simultaneously see a reduction in stress because the projects are now broken up into smaller stories with an online Scrum board, making things easier to manage, and low value projects go away 2.9. Challenges Labs team members are still working mainly as individuals. Team members are specialized and lacking cross-training. Specialized experts chose stories for themselves at the beginning of the sprint crippling selforganization. There were stories that could only be done by one person. This further prevents self-organization and causes bottlenecks reducing throughput. The daily Scrums are taking up to 45 minutes for a four member team. It is increasingly difficult for a four member team to both be product owners and executers. The work days are intense, and long hours start to become exhausting. Communication between the Scrum team and its project stakeholders the portfolio companies and the OpenView senior point people who manage those portfolio companies and sit on their Boards is poor. It is unclear how the stories for any given portfolio company fit together. The Scrum team is unsure of the true impact of the stories. While all team members were thrilled with help on their projects and other Scrum benefits early on, some are starting to show discomfort with functioning as members of a team rather than as individuals. Transparency and management by the team, as well as the existence of a Scrum Master, start to become sources of conflict, especially for one team member. Several team members are still unsure that Scrum, which was designed for software development, makes sense for the work at OpenView Labs. They embrace some aspects of Scrum but reject others and prefer to stop the implementation where it is at that time. The ability to take large projects and make them manageable by breaking them up into smaller stories creates the temptation to take on many projects. While early on the Labs team takes on 80 points and completes sprints successfully, as the team tries to push itself it stops landing the sprint. It falls into a habit of taking on stretch goals and not landing, and velocity remains flat sprint to sprint. An ongoing impediment is that the team cannot define reference stories and estimate stories in story points rather than perfect hours. Going from 100 to 120 perfect hours completed might simply mean that focus factor had increased from 50% to 60%. However, it was also observed that the team was focused on improving the quality of stories entering the sprint in order to reduce the cycling back and forth to the point person and portfolio company during the sprint to clarify the story. Recent research has shown that reducing the calendar time to complete a story (increasing story process efficiency) actually reduces the amount of work needed to complete a story [8]. Doubling the process efficiency actually doubles team velocity. Some of that was going on here, but it was impossible to quantify this because of the impediment of estimating in perfect hours. The Product Owner was also the manager and there was pressure on the system. It was difficult for the ScrumMaster to push back and protect the team. Another issue was that the team was aggressively trying to remove waste but not doing adequate root cause analysis. They discovered that eliminating

5 impediments without eliminating the root cause resulted in impediments coming back in another form. It was like swatting mosquitos. For every one they killed, more came back. From a lean point of view, muri (smoothing out the flow), mura (eliminating pressure points), and mudah (removing waste) are the key principles. There were disruptions in flow because of specialization and pressure on the system because of the product owner/manager. Fortunately, the product owner/manager was carefully studying the lean literature and becoming a student of Taichi Ohno, inventor of the Toyota Production System [9]. Books on Toyota were recommended reading for the senior management of portfolio companies and the OpenView staff. While this did not immediately lead to strong root cause analysis, it set the stage for it later on Retrospective Retrospectives are held every Monday, and team members discuss their sprints. While impediments are surfaced, documented, and typically removed, there was no formal closed loop for removing the impediments in Phase I. 3. Scaling up: Finding the Rhythm Once most of the basics of Scrum were in place, the Labs team started to experiment with different components. Team velocity was higher and put pressure on the Product Owner role to produce more and higher quality stories Team Structure As the team grew from four to six and ultimately nine members, it became too large to be efficient. All meetings, from the Sizing to the Daily Scrums, took too long. It is increasingly difficult for any team member to be heard in a large group The team split into two and the team was allowed to decide how it will split. Members organized into two teams whereby more functionally specialized team members are on one team and the newer team members are on another. A new Scrum Master is appointed to the more specialized team Sprint Length After experimenting with two-week sprints, the Labs team and Investment Committee settled back on oneweek sprints. In two-week sprints, the Scrum team found it more difficult to stay focused on the key goals and the number of unplanned stories grew Product Ownership & Backlog Scott Maxwell is the Chief Product Owner across the firm. Product ownership for portfolio value-add projects shifted out of the Labs Scrum team and is formalized as the role of OpenView senior point people. Each portfolio company now had its own backlog, housed in an online spreadsheet in Central Desktop. Each backlog was discussed in the Investment Committee meeting where priorities were reviewed and stories clarified. The Labs Scrum team still provides feedback into the backlogs but now every story and any changes must go through the senior point person. Projects to institutionalize and build out OpenView s value-add capabilities are formalized. OpenView s value-add capabilities are organized around Practice Development Areas, by function (i.e. Sales, Marketing, Customer Service, R&D, etc.) Each Practice Development Area has a point person, or product owner, in the Labs team and its own backlog. Every Monday, Scott holds a meeting where every Practice Development backlog is reviewed, prioritized, and clarified. Labs team members now wear their Product Owner hats when preparing the Practice Development backlogs, speaking with the senior point people about the Portfolio company backlogs, and in the Monday Practice Development and Investment Committee meetings. They wear their Scrum team hats the rest of the sprint Stories Story clarity improved. Less communication during the sprint is required between the Labs team and the portfolio companies and the senior point people / product owners. Definition of DONE is now specified and the same for every story. The story is DONE when the deliverable (whether an analysis or notes from a call or meeting) is posted to Central Desktop and all the stakeholders (the point people/product owners) are notified. Next steps are specified. This definition of DONE was created in response to the Labs team completing stories but not communicating effectively back to the point people what had been done and what remained to be done in the initiative. Note that this change, which increases the amount of work for every story, is not incorporated into sizing, and does not show up as increased velocity Sizing and Planning Sizing and Planning was now done in the Scrum Room, whose walls have been turned into product

6 backlogs and a Scrum board. While all stories start in an online spreadsheet on Central Desktop, they re written on post-it notes and end up on the walls. As part of planning, the ScrumMaster and team surface all dependencies and possible impediments, and the ScrumMaster works to remove all of them by mid sprint, and ideally by end of Monday. Figure 2. OpenView Labs Scrum Board After experimenting with having a Sizing meeting on Thursdays, the Labs team settles back on a Sizing meeting every Monday primarily because the backlog changed too much between Thursday and Monday. Sizing continues to be done in the same fashion as before, using fingers on hands instead of planning cards. For a period of time, the Labs team tries to transition to sizing stories in Story Points rather than perfect hours. After a while the meaning of a Story Point becomes unclear, and it seems like they are just another time for perfect hours. The team goes back to using perfect hours. In discussions with Jeff Sutherland, the reasons behind the confusion become clear: Many Labs stories are small enough to be Tasks, which in Scrum are sized in hours. Many stories are time-based. For example, A one hour call with Jim to discuss marketing plan. Many research type stories are also time boxed. As a result, it s difficult to size a large part of the backlog in hours while sizing another part in relative story points. No changes are made to the way prioritization and planning are done Daily Scrums Daily Scrums now last only 15 minutes, with the same three questions asked Retrospective Plenty of impediments still surface in the weekly Retrospective. There is now an mpediment backlog if the impediment cannot be removed immediately Velocity Velocity for a sprint is set by the team s velocity for the previous sprint. After many failed sprints, the team is now landing almost every sprint. Through trial and error, the Labs team has discovered that the more it takes on beyond the previous sprint s velocity, the less it actually gets done during the current sprint and velocity falls. When the team takes on less, it gets more done and pulls forward. While calculating velocity in perfect hours instead of story points makes it difficult to use velocity as a gauge of improved output productivity, combining perfect hours with other metrics and a few conservative assumptions demonstrates significant productivity improvement in comparison to early Velocity in perfect hours has risen from approximately 80 for four team members each working hours per week in January of 2008 to approximately for nine team members each working hours per week in October of 2008, representing a 40-70% increase. This is primarily an improved focus factor. If standard reference stories were used to calculate story points a much bigger improvement in velocity could be demonstrated. On the chief Product Owner s request, the Scrum team does not hold sizes of the same stories constant over time but reduces the size as the team has gotten faster at doing certain stories or has automated their execution. Some stories go from a size of 1 story point to 0. Others go from 5 to 1, and so on. The new definition of done is also generally not accounted for in the story sizing. If one assumes that reducing the sizes of the same stories over time due to process improvements has had an impact of at least 20%, and the definition of DONE has increased the actual size of stories by at least 10%, one can assume a conservative productivity improvement of approximately % from late January to October of This does not account for the total business value generated by the Scrum teams. The Chief Product Owner feels this has gone up significantly due to the elimination of low priority storiess and focus on high priority ones. Scott Maxwell sayss output in terms of value has gone up by 150%, bare minimum. The Scrum teams believe they are doing much higher value work as well, and morale is higher.

7 3.9. Benefits Now that the team is utilizing Scrum to surface and remove impediments, there is more transparency within the Labs team and between the Labs team and the portfolio company point people / product owners. Every team member now knows exactly what to do at the beginning of every week, allowing everyone to focus on execution. Team members are now getting more done working less hours. Late nights and weekend work are now frowned upon. Sustainable pace is the goal. The Labs team has gone from working with six portfolio companies to working with ten without getting overwhelmed or drop-off in quality. Improving OpenView s value-add capabilities is now receiving significant attention, and there are now ten practice development backlogs. New team members are integrated into the team and workflow extremely quickly via Scrum. They carry a full workload within three weeks of starting without extensive training. Team collaboration and crosstraining increase. Labs Scrum team is executing more stories across more portfolio companies and practice development areas while working less, producing higher quality, more value, and requiring less outside management Challenges At the beginning of this phase, the Labs ScrumMaster was concerned about two issues : 1. The team is working a normal work week and concerned that the team has not doubled velocity. 2. The team member that is stressed because of Scrum s transparency and competitive nature of the team members is complaining about the ScrumMaster. The ScrumMaster asked Jeff Sutherland to do an independent retrospective with the team. He discovered that team velocity had gone from 100 points with current staffing (up from 80 points) to 120 points. In addition the team has discovered about 30% of their stories were delivered little or no added value to the portfolio companies. They were no longer doing these stories. So the 100 points they were delivering had 30% low value stories and only 66 points of high value were delivered. Now they were delivering 120 points of high value. The Chief Product Owner confirmed that he was getting at least twice as much value out of the team. As described in the Velocity section, this trend continued as the team grew and its velocity went up to The one Labs team member who is stressed by transparency and other aspects of team work could not work within the team. He was a strong individualist and prefers answering to one clear manager rather than a team of peers. After experimenting with different ScrumMasters and team organizations, he ultimately leaves the Labs team and works for OpenView outside the Scrum process. As this phase of implementation comes to a close, the overall product quality is higher, but the Labs team oscillates between focusing on velocity and focusing on quality, with spikes in velocity leading to reduced quality and focus on quality leading to reduced velocity. While the impact of most stories is now clear, the big picture context is still lacking for some team members. Some team members become too focused on getting perfect hours done and driving velocity rather than on the ultimate impact of the story. While team collaboration has grown significantly, a good number of team members still work as individuals within the team. Insufficient cross-training among the Scrum team members is still a bottleneck, especially with three brand new team members. Long-term projects drag out over long periods of time because too many projects are being worked on simultaneously. 4. Where we are in November 2008 OpenView has twenty-two full-time employees, actively works with ten portfolio companies, and is working on ten practice development areas. The Labs consists of two Scrum teams, both with four people, with a velocity of approximately 180. The Labs Scrum teams have high morale and have embraced continuous improvement. The current main initiatives include better focus and more team collaboration and cross-training: Focusing on higher impact stories rather than tasks. Focusing on FEWER goals and long-term projects at a given time and working to complete them more quickly. Weekly lunch-and-learn sessions allow senior team members to educate the newer ones on topics chosen by the new team members. Each Friday, all the portfolio company point people / product owners attend a debriefing meeting with the Labs teams, discuss the results of the sprint s stories, and get sharper on next sprint s goals and stories. This helps remove impediments resulting from lack of clarity between the point people and the Labs Scrum teams. OpenView implemented the Scrum tool VersionOne ( to meet the need for a more sophisticated backlog/sprint management vehicle instead of using Central Desktop online spreadsheets. The firm still uses Central Desktop for online content management, collaboration, and for organizing meetings.

8 4.1. Retrospective As the Scrum teams start to establish a pace and increase velocity it puts pressure on the Product Owner role. This causes a reorganization of Labs as the initial version of this paper is finalized. 5. Key Lessons Learned From an external point of view the OpenView labs teams have clarified several important points for the Scrum community by developing a high velocity sprint that aggressively removes impediments: 1. Dependencies between tasks need to be tagged on the Scrum board and removed by mid-sprint or the story will fail. 2. Increasing the definition of DONE improves quality which increases velocity by eliminating low value stories or features never used by the customer. 3. Estimating in hours will make it impossible to know actual velocity and difficult to assess process improvements. 4. Improving readiness of the product backlog will improve story process efficiency, reduce the amount of work required, and increase velocity. 5. Some critical impediments require reorganizing the company to resolve. 6. Take No Prisoners Scrum will radically change the organization on a regular basis. 7. Realizing that there are four key components that need focus in Scrum. a) Direction (the backlog) b) Speed c) Quality d) Sustainability/Predictability 8. Major challenges emerged when the team focused on just a single area. 9. For Scrum to work, you must have trust, openness to conflict, commitment, accountability, and attention to results on a team [10]. 10. Scrum is very good at revealing areas in which a team needs to improve. The self-organized team nature of Scrum immediately surfaces negative outcomes from lack of trust, fear of conflict, lack of commitment and accountability, and inattention to results. The Scrum Master must identify and clarify these impediments and then work with the team and Management to remove them. 11. Aggressive removal of impediments without doing root cause analysis leads to extra work. Impediments come back in the same or modified form until root cause is eliminated. Study of the Shewhart/Deming cycle and implementation of the Toyota A3 Process will be used to solve this problem [11]. 12. Scrum is not for everyone. Some very capable people are so individualistic that Scrum kills their productivity and causes them to hurt the productivity of the Scrum team. If they cannot change, it is best to remove them from the Scrum team. Experiences at OpenView Labs are generalizable to portfolio company development groups and other parts of the organizations senior management, marketing, sales, support, and finance. We have Scrum teams in many different departments in many companies that have already benefited from the OpenView experience. 6. Conclusions Repeatedly and systematically removing impediments leads to refactoring of the organization. This paper has reviewed an initial and transformed implementation of Scrum at OpenView Venture Partners. The Phase II implementation of Scrum has recently been radically transformed into a Phase III Scrum organization that will be the topic of future study. OpenView has gone through a classical Scrum pattern. The Phase I implementation surfaced problems with the definition of DONE. This was fixed by the Phase II implementation and velocity doubled. Increased velocity puts pressure on the Product Owner to create more and better stories. A key feature of the new Phase III organization is creation of a Product Owner team with more rigorous attention to story formation, prioritization, and READY state of user stories before allowing them into a sprint. There are already indications that the team is on their way to the second doubling of productivity using this strategy. This Scrum pattern of repeated doubling of productivity has been carefully researched at Systematic Software Engineering [8] for software projects. Here we see the same phenomenon in non-software Scrum. It is possible to utilize Scrum for non-software project management and execution and to achieve significant productivity gains. This approach has gained traction with OpenView portfolio companies and at least three have begun to implement variations of Scrum to run multiple functions outside of Software Development. One is emulating OpenView Venture Partners by implementing Scrum in every area of the business. 7. About OpenView Labs OpenView Labs' mission is to gather, create, store, and disseminate best practices and expertise for the benefit of OpenView Venture Partners, its prospects, portfolio companies, and its community and provide high impact execution assistance to the portfolio companies. They execute their mission through a combination of best practice documents, online and inperson forums, and on-site consulting engagements using both full time operational staff and a growing

9 network of functional experts. Their goal is to achieve significantly higher investment returns using industry best practices. Scrum is a valuable tool for them to improve organizational efficiency and production, to enhance customer satisfaction, and to create a rewarding work environment for employees. 8. References [1] B. Barton and E. Campbell, "Implementing a Professional Services Organization Using Type C Scrum," in 40th Hawaii Intrnational Conference on System Sciences, Hawaii, [2] J. Sutherland, "Future of Scrum: Parallel Pipelining of Sprints in Complex Projects," in AGILE 2005 Conference Denver, CO: IEEE, [3] B. Barton, "All Out Organizational Scrum," in 42nd Hawaii International Conference on System Sciences, Waikaloa, Hawaii, [4] A. Sutherland, J. Sutherland, and C. Hegarty, "Scrum in Church: Saving the World One Team at a Time," in Agile 2009, Chicago, [5] J. Sutherland and K. Schwaber, The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method. Boston: Scrum, Inc., [6] M. Cohn, Agile Estimation and Planning: Addison- Wesley, [7] J. O. Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity," in 5th Annual Borland International Conference, Orlando, FL, [8] C. Jakobsen and J. Sutherland, "Scrum and CMMI Going from Good to Great: are you ready-ready to be done-done?," in Agile 2009, Chicago, [9] T. Ohno, Toyota Production System: Beyond Large Scale Production: Productivity Press, [10] P. M. Lencioni, The Five Dysfunctions of a Team: A Leadership Fable: Jossey-Bass, [11] D. K. Sobek and A. Smalley, Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System: CRC Press, 2008.