Scrum in Sales
How to improve account management and sales processes
Rini van Solingen
iSense Prowareness and Delft University of Technology r.vansolingen@prowareness.nl
Jeff Sutherland ScrumInc Boston, USA
Denny de Waard iSense Prowareness The Netherlands
Abstract— Like most client service units, the sales and account management teams at iSense accepted that sales are a random, reactive process. After all, customers, not sales managers, decide whether or not to buy. Then, after deciding to learn more about a certain offering, Scrum training, the teams found a way to take more control over this process. In the fall of 2010, the iSense sales and account management teams decided to adopt Scrum internally as their best practice.
Keywords: Scrum, Sales, Account Management, Scrum Board
INTRODUCTION
Scrum is increasingly used outside of software development. In fact, the first use of Scrum in product development, that was observed and named by Takeuchi and Nonaka, was primarily in manufacturing [1]. More recently, Scrum has been adopted by a venture capital group for all its investment search, support, and administrative processes in addition to multi-department use in over a dozen portfolio companies [2]. Scrum has even been adopted as a radical management strategy in some organizations, working at the level of the senior management [3].
Early adoption of Scrum in sales and marketing has been seen in several companies in the U.S. and Europe. However, this paper provides the first documented insights into how Scrum can improve predictability in the sales process leading directly to increased revenue.
As a follow-up to the ‘Scrumification’ of its software development processes, iSense ICT professionals and iSense Prowareness rolled out Scrum in all its departments. It started with the software development teams, and now also includes the account and sales teams.
In this paper we will share:
the reasons the sales teams adopted Scrum,
the sales environment prior to adopting Scrum,
the initial changes the teams implemented and the subsequent changes used to improve,
the current Scrum processes in sales,
lessons learned, major achievements and next steps.
MOTIVATION TO ADOPT SCRUM
From the experience of developing software for European customers, the iSense Indian software teams learned the power of short iterations, test-driven development and delivering market-ready product. By contract with European customers, these Agile practices were implemented top-down as a risk prevention strategy imposed on the teams. While they had some positive effects, these ‘a la carte’ techniques provided neither a clear structure for the software development process itself, nor a structure to the customer. The Indian teams performed some research and expressed interest in Agile processes, Scrum in particular.
The iSense office in the Netherlands independently was investigating Scrum as an additional line of service to provide training and consulting in Scrum to Dutch customers. Considering the potential benefits of software delivery and Scrum consultancy, and the iSense management’s vision that Agility is a necessary strategy to succeed, Scrum was adopted within both the Indian software teams and the Dutch sales teams. Management sought key Scrum coaches to advise the company on successful Scrum adoption.
The teams selling Agile services and the offshore services decided to ‘eat their own dog food’, or you may say ‘drink their own champagne’. They believed that selling Scrum consulting and software projects required first-hand experience in and a thorough understanding of Scrum. As such, they decided to adopt Scrum for their sales processes to gain direct experience and improve their ability in selling it. Hence, the initial interest to adopt Scrum in sales came forward from an intrinsic motivation to understand Scrum. Improving anything else would have been seen as a bonus at this stage.
SITUATION BEFORE THE DEPLOYMENT OF SCRUM Before diving into our interventions, we would like to first
give you a brief idea of how the sales teams worked and their
accepted beliefs about the sales process.
Focus on individual work and progress
Account managers were responsible for their own work, tasks and outcomes. There was no communications between account managers about goals and sales methods. The account teams use a CRM system to store detailed information on clients, and account managers seldom accessed accounts of one another’s clients. This created a black box of individual processes of which only the outcome would be shared: deals made and the size of the deals. As such there was only one main performance indicator: the number of deals closed. At the beginning of every week, account managers shared their sales forecast; at the end of the week they reported the actual sales numbers.
Belief that sales is inherently random
In addition to the limited insight into the progress of individual’s tasks, there was no cohesive sales process in place. Account managers focused on individual accounts and sales figures, without consideration of the overall result of the entire sales unit. When first discussing the opportunity to apply Scrum for sales, most account managers were skeptical. They felt that software development was radically different from sales, because sales were much more unpredictable. According to the account managers, software developers can predict results simply from the input. In the sales process, they felt that only the customer had control over the outcome, so the same prediction simply could not apply. At this stage, the initial focus was on the feasibility of using Scrum in sales.
Only insight in outputs (final sales numbers)
The only measure of success in the sales teams was the number of deals closed. There was no known system to predict how processes affect end results. There was an attempt to track the number of phone calls made per day. However, to what extent these resulted in actual sales were unknown. Management could only steer the account teams on the output indicators. The final decision of a client determines whether an account manager did a good job or not. This led to large fluctuations in results and huge impact on the morale of the sales teams. If management could only steer the teams by increasing (or decreasing) sales targets, the adjustment of sales targets has limited impact. No matter what the sales targets are, account managers would have put in the same time and effort in a hope to close deals. In this environment, even management could not affect the sales output.
Unpredicatable cause and effect in the sales process
There was no known relationship between specific tasks and final sales results. The only way to improve sales results was to work harder; the more calls you make, the more deals you close. Without knowing how sales processes affect the sales results, it was simply impossible to find a way to “work smarter”. Generally, account managers contacted (potential) customers, identified their needs and when they could provide a service for an acceptable price, they made a deal.
No reflection or improvement on sales activities
The sales teams were focusing only on their daily routine and did not realize a need for frequent reflection and improvement each cycle. When there were success stories, sales teams did try to learn from it in order to improve their results. However, such activities occurred on an ad-hoc basis, so it did not allow the sales teams regular opportunities to learn to “work smarter” together.
INTERVENTION
Deciding to Scrum the sales teams
The first Scrum team (the team selling Scrum to European clients) decided to ‘eat their own dog food’ and adopt Scrum in their sales process. This decision was initiated by two of the company’s Scrum consultants participating in a sales meeting. At the meeting, the consultants tried to teach the account managers about Scrum in order to help them apply Scrum in sales. Agility is a common term which is easy to understand but hard to apply. This led to a lot of questions on how certain aspects of Scrum can be applied to both the typical software development environments and the sales processes. It appeared to be quite difficult to understand Agility and Scrum fully and even more difficult to convince potential customers with no prior knowledge of Scrum. Understanding Scrum terminology alone had not been sufficient for sales managers to convince skeptical customers of Scrum on the phone.
The Scrum consultants encouraged the sales team to use Scrum themselves in order to gain better understanding of the product. Believing Scrum would only work on predictable processes like software development, the sales managers were reluctant to as they believed that Scrum was repeatable in sales. The consultants confronted the managers’ misconception by explaining the unpredictable character of technology and technological solutions.
Figure 1. Initial Sales Scrum Board
The first team appointed a sales managers as the ScrumMaster to lead daily stand-ups. Their director was appointed Product Owner, who decided to work with weekly sprints but continue to maintain a quarterly sales target and cycle. Finally, they developed a Scrum board (see figure 1 for the initial version) to align tasks and task progress. On the left of the board, the individual tasks for their respective services were listed. On the
right, a burn-up was drawn and some individual indicators were listed.
Just do it
The team took a ‘just do it’ approach and simply started with:
Weekly sprints on Monday with a retrospective and sprint planning on the same day,
Quarterly focus on sales target (13 sprints till ‘release’),
Weekly inspection and adaptation: learn the way to do it by doing it, and receiving advice from the internal Scrum consultants/coaches,
A Scrum board with burn-up for order intake (because over-target sales should not be expressed in negative numbers),
Daily stand-up at 9:30am in front of the Scrum board.
During the first weeks, the approach of doing Scrum in sales evolved rapidly. The usage of the Scrum board was continuously adapted. The sales team was not self-motivated and lacked discipline in the Scrum rules at the beginning. The appointed ScrumMaster was often out of the office, and the team did not initiate their daily stand-up. When the ScrumMaster was in the office, they neither started on time nor time-boxed at 15 minutes.
Realizing their mistake, the team made a fresh start with Scrum, reflecting on how to better adapt their processes and continue to learn through Scrum.
A major change happened when one of the consultants proposed to organize Agile Awareness Events. These events were organized for customers with an interest in Scrum. Each half-day event was free of charge and was led by a consultant at the iSense European office. The initial objective of the event was for the consultant to promote Scrum knowledge to potential clients. However, the events also had a major impact on the sales team. In the past, it was difficult to get the clients to open up about their needs via cold calling. Through the invitation to the free events, sales managers had an opportunity to develop a rapport with the potential clients. From the organization of these events and setting targets for the number of participants, the sales team was also filling their own sales pipeline. Instead of rushing a potential client towards a deal, sales managers are now taking it slow and one step at a time.
Roll-out
The management was enthusiastic to see the positive impact of the adoption of Scrum within the first sales team and the increased transparency of sales process. All other sales teams therefore adopted Scrum. At first, the management used Scrum to guide underperforming sales teams to help them get their sales processes under control. This management bias led to Scrum being perceived as a tool for underperforming teams only. This misconception was subsequently corrected, and Scrum has been implemented within all sales teams.
LESSONS LEARNED
Three important lessons have emerged from implementing Scrum in sales. First, sales is much more predictable than expected. Cause and effects surface when using Scrum. When such links are known it becomes possible to control order intake for the iSense sales teams. For the Scrum consultancy unit, the current process includes: inviting clients to free Scrum awareness events via cold calling, attending the events to meet potential customers and generate warm leads, contacting warm leads to discuss collaboration, turning them into hot leads, closing hot leads into deals, and delivering services to the customer. Eventually it became clear how many cold calls will lead to how many awareness event participants and then how many warm leads and so on. This process facilitates prediction about the average number of cold calls required to make a deal. While inspecting data on close rates, the teams found that only 1 out of 10 event participants will lead to a deal. The sales managers feel that more can be done with the remaining 9 event participants who did not become clients. After all, these potential customers did not come to a free event just for the coffee. Through the transparency and communication Scrum encourages, account managers realized that the gap between event participation and negotiating collaboration is still too big. In light of this, they proposed to create an intermediate step to close the gap. The sales teams approach event participants with a proposal to organize a workshop at their company. This is another step closer to deal negotiation and is well-received by the potential clients because the approach is not too aggressive. As a result, the hit-rate rises to 2 out of 10, and even these on- site workshops create some revenue.
Second, sales alone are not sufficient, and total value delivery is crucial. Scrum as the sales best practice allows the sales teams transparency into the full sales process and helps them realize the impact of sales on other company divisions. When the account management teams brought in more clients from the on-site workshops, there were not enough consultants available to deliver the service. In order to ensure a smooth and complete sales cycle, the account managers realized they needed to help the recruiters and take an active role in the recruitment process when the number of available consultants could not support any the new accounts. The account managers started to look for professional contractors who could provide service on a temporary basis as a short term solution, in order to allow recruiters more time to look for consultants. Taking this a step further, the account managers are even promoting cross-functional teams comprised of a member from sales, recruitment, marketing and consulting. After all, delivering value to clients from start to finish is much more than just closing deals. It is exciting to see the sales teams overcoming the “sales stereotype” by assisting other divisions in a non-sales capacity.
Lastly, Scrum showed how relationship maintenance and referrals are vital in sales. Future business opportunities emerge from existing accounts, reiterating that the sales teams should not only focus on creating new business but also continue to work maintaining good relationships with existing clients. When the client is satisfied, they promote the service to their acquaintances and help to bring in word-of-mouth business. Such insights arise from the self-reflection cycle
within the sales teams as they tried to identify ways to achieve department goals. This Scrum in sales experience confirmed the importance of retrospectives. In fact, because of the short sprints of a single week, weekly retrospectives mainly focused on the nuts and bolts of the sprint. Monthly (or bi-weekly) retrospectives proved to be more effective as a way to reflect in more detail about how to improve the process itself.
MAJOR ACHIEVEMENTS
Since the introduction of Scrum to the sales teams, the company revenue doubled. It is fair to say that the increased revenue was not solely caused by using Scrum, but the iSense director highlighted that at least 50% of the revenue increase should be attributed to its adoption. Using Scrum was a major change to the company culture as sales teams are now more self-motivated, and they reflect on the effectiveness of their sales process by utilizing a frequent inspect and adapt cycle.
The sales teams are more focused because they learned how their processes work and how they can control them. This results in continuous prioritization and reprioritization with primary focus on activities that return the highest value. The emergence of early indicators of sales fluctuations also avoids the panic of a low revenue cycle because account managers can easily identify action items to raise sales figures.
The sales teams changed their misconceptions about the unpredictability of sales, and learned the causality between what they do and the order intake. They now understand that they have control. Trying to close a deal is like giving a demo. As a team you are not a 100% sure that the client got what they needed, but a great Scrum team will come close every time. A great sales Scrum team will hit its targets most of the time, if not all the time.
Figure 2. Sales Scrum Board
In the last few months the teams clearly learned that business is much more predictable than ever thought possible. They are able to streamline the sales pipeline better and better every week. Increases or drops in sales can be detected in advance. The company uses this information to adjust behavior. For example, HR can use sales indicators to decide whether to increase or decrease recruitment efforts.
It is really remarkable to see that sales people deployed a learning process they did not know could be deployed; they learned to learn, so to speak. Running weekly cycles showed
teams that sales are predictable when defining the stages potential clients follow and can be manipulated when helping them continue to the next stage (or not). This notion is reflected in the current Scrum board (figure 2). In the initial board (figure 1) the team only planned tasks. In the current Scrum board, the sales pipeline is included. Every week, the teams review the status of each lead in the cycle and agree on the actions required to bring every potential customer a step closer to the collaboration negotiation stage. Availability of consultants and burn-down charts for participants to the initial events are also shown on the board. The output is reflected in a single burn-up chart showing order intake compared to the quarterly target.
Looking back, the sales team worked without any indication that their daily tasks lead to results. Doing Scrum has empowered teams to impact potential customers’ decision- making process. As more data is collected, the sales teams are increasingly able to accurately predict when to take actions. The Scrum board helps to transpire the evolution of the understanding of the sales process.
WHAT TO DO DIFFERENTLY
Although the teams are remarkably enthusiastic about the use of Scrum in sales, not everything went smoothly during the roll-out phase. In the early stages of deployment the team did not fully commitment to the Scrum meetings and roles. The daily stand-up was not held at the same time each day because team members were out of the office, travelling or meeting clients. When the ScrumMaster was not present there was no daily stand-up. Furthermore, time-boxed planning was not done regularly, and retrospectives were not effective. This jeopardized the adoption as Scrum in sales started to slowly deteriorate after its initial introduction. The two internal consultants continuously challenged the team, which ultimately helped to overcome the obstacles to adoption.
Initially there was no real improvement cycle. The first sales team reviewed each week what did not work well but did not critically reflect and alter their way of working. Most impediments identified at the weekly review were beyond the team’s control, so the account managers were never to blame for the poor results.
This attitude changed drastically when the team used the A3-process [4] during a quarterly retrospective meeting. The team identified their biggest impediment and together performed a root-cause analysis. The realized that they had been calling the wrong management levels when contacting potential customers. Additionally, the first sales team defined many small improvements during the retrospectives, but these were not fixed in following sprints. One external consultant advised the team to prioritize impediments and select only the most important from a retrospective. The team would eliminate it by defining concrete actions and list them as normal tasks (with the highest priority) on the backlog for the next sprint. The sales teams now define one major improvement per week and assign it the highest priority of all tasks. After all, that one improvement area will make the sprint better than the previous one. The account management teams realized that nothing has a greater impact on future sales than continuously improving the sales process with the highest value improvement first.
CONCLUSION
Although Scrum was initially designed for software development, there is no reason why it cannot work in other disciplines. After all, value prioritization, self-steering, teams, joint task definition and continuous improvement are invaluable to any disciplines. At Toyota, for example, management teams believe that organizational routines for improvement and adaptation, not quantitative or financial targets, define the pathway to long-term success [5].
The experiences described in this paper illustrate how the adoption of Scrum can be beneficial in any disciplines. Scrum can lead to increased revenue and a sustainable competitive advantage when implemented in parts of an organization outside of IT [2, 6].
ACKNOWLEDGMENT
The authors would like to thank the sales management team members at iSense ICT professionals and iSense Prowareness for sharing their experiences and enthusiasm in using Scrum for Sales. Additional thanks to Anna Leung with her support in the paper writing process.
REFERENCES
H. Takeuchi and I. Nonaka, "The New New Product Development Game," Harvard Business Review, 1986.
J. Sutherland and I. Altman, "Take No Prisoners: How a Venture Capital Group Does Scrum," in Agile 2009, Chicago, 2009.
S. Denning, The Leader's Guide to Radical Management: Reinventing the workplace in the 21st Century: Jossey-Bass, 2010.
D. K. Sobek and A. Smalley, Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System: CRC Press, 2008.
M. Rother, Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results: McGraw Hill, 2010.
A. Sutherland, J. Sutherland, and C. Hegarty, "Scrum in Church: Saving the World One Team at a Time," in Agile 2009, Chicago, 2009.
How a Venture Capital Group Does Scrum
Jeff Sutherland, Ph.D. Scrum Training Institute Boston, USA jeff@scruminc.com
Igor Altman OpenView Labs Boston, USA
Keywords-agile, scrum, venture capital
INTRODUCTION
This paper introduces a successful model for implementing Scrum in OpenView Labs, a division of OpenView Venture Partners that supports a growing number of portfolio companies for a venture capital group. The teams do not do software development. They help implement best practices in management, sales, marketing, finance, development and customer support for portfolio companies. Their Scrum implementation is repeatable, proven across many projects, and recommended for teams in all areas of business.
The Context
OpenView Venture Partners was founded in the Fall of 2006 with nine team members and an initial $107M investment fund. 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.
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-add and due diligence. 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-add to each portfolio company remained elusive.
OpenView Meets Scrum
OpenView was familiar with Agile Development since its investment in VersionOne (www.versionone.com), 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
met with Scott Maxwell. In Scrum, Scott saw simple principles and ideas that could be applied to make OpenView more productive and self-managed. 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:
Phase I – Getting Started with Scrum
Phase II - Scaling up Scrum
Phase III is being implemented at the time of writing of this paper and radically reorganized the Scrum teams. High team velocities caused the Product Owner function to be a bottleneck and this will be a topic of a future paper.
GETTING STARTED WITH SCRUM: TRIAL BY FIRE Phase I of our Scrum implementation started during one
week in January 2007.
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 Scrum Master 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 for OpenView and the Labs Product Owner, although the Scrum team is effectively a Product Owner 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 has a story backlog housed in an online spreadsheet in Central Desktop (www.centraldesktop.com), 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 focuses on three overarching 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 are vague and unclear in this early phase of Scrum adoption. Definition of done is different for every story and is typically unclear.
Understanding the specifications of each story takes a lot of back-and-forth 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 time-based, 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 determine 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 [2]. 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 removals that decrease 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.
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 over 50 hours a week, working late and on weekends. But Scott noticed that Scrum is intense. The peak of production is less than 40 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
Benefits of the Scrum implementation, though far from perfect, emerge immediately. The team is now self- managing, 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 [3] 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 Scrum Master 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 10-20 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
Challenges
Labs team members are still working mainly as individuals. Team members are specialized and lacking
cross-training. 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 lands, 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.
SCALING UP: FINDING THE RHYTHM
Once most of the basics of Scrum are in place, the Labs team experiments with the different components.
Team Structure
As the team grows from four to six and ultimately nine members, it becomes too large to be efficient. All meetings, from the Sizing to the Daily Scrums, are taking too long. It is increasingly difficult for any team member to be heard in a large group
The team splits into two and the team is allowed to decide how it will split. Members organize 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 settle back on one-week 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 is the Chief Product Owner across the firm. Product ownership for portfolio value-add projects is shifted out of the Labs Scrum team and is formalized as the role of OpenView senior point people.
Each portfolio company now has its own backlog, housed in an online spreadsheet in Central Desktop. Each backlog is discussed in the Investment Committee meeting where priorities are 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, housed in an online spreadsheet in Central Desktop. 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
Stories are now relatively clear. 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.
Sizing and Planning
Sizing and Planning is now done in the Scrum Room, whose walls have been turned into product 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.
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 impediment backlog if the impediment cannot be removed immediately.
Velocity
Velocity for a sprint is now 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 the sole gauge of improved output productivity, combining perfect hours with other metrics and a few conservative assumptions demonstrates significant productivity improvement in comparison to early 2008.
Velocity in perfect hours has risen from approximately 80 for four team members each working 50-70 hours per week in January of 2008 to approximately 190-200 for nine team members each working 40-50 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 productivity improvement of approximately 80-100% from late January to October of 2008.
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 stories and focus on high priority ones. Scott
Maxwell says 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.
Benefits
Now that the team is utilizing Scrum to surface and remove impediments, their 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 they need to do and why 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 cross-training 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
One Labs team member cannot work within the team. He is a strong individualist and prefers answering to one clear manager rather than a team of peers. He leaves the Labs team and now works for OpenView outside the Scrum process.
While overall product quality is higher, 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 clearer, 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.
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 (www.versionone.com) 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.
V. KEY LESSONS LEARNED
Part of successfully implementing Scrum is realizing that there are four key components that need focus.
Direction (the backlog)
Speed
Quality
Sustainability/Predictability
Major challenges emerged when the team focused on just a single area.
For Scrum to work, you must have trust, openness to conflict, commitment, accountability, and attention to results on a team [4].
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.
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 [5].
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.
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.
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 [6] 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.
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 in-person forums, and on-site consulting engagements using both full time operational staff and a growing network of functional experts. Their goal is to achieve significantly higher investment returns using industry best practices.
REFERENCES
J. Sutherland and K. Schwaber, The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method. Boston: Scrum, Inc., 2007.
M. Cohn, Agile Estimation and Planning: Addison- Wesley, 2005.
J. O. Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity," in 5th Annual Borland International Conference, Orlando, FL, 1994.
P. M. Lencioni, The Five Dysfunctions of a Team: A Leadership Fable: Jossey-Bass, 2002.
D. K. Sobek and A. Smalley, Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System: CRC Press, 2008.
C. Jakobsen and J. Sutherland, "Scrum and CMMI
