take no prisoners - jeff sutherlandjeffsutherland.com/scrum/takenoprisonersscrumday.pdf ·...

© Jeff Sutherland 1993-2009

TAKE NO PRISONERSHow a Venture Capital Group Does Scrum

With help from Google, Yahoo, Microsoft, IBM, Oracle, MySpace, Adobe, GE, Siemens, Disney Animation, BellSouth, Nortel, GSI Commerce, Ulticom, Palm, St. Jude Medical, DigiChart, RosettaStone, Healthwise, Sony/Ericsson, Accenture, Trifork, Systematic

Software Engineering, Exigen Services, SirsiDynix, Softhouse, Philips, Barclays Global Investors, Constant Contact, Wellogic, Inova Solutions, Medco, Saxo Bank, Xebia,

Insight.com, SolutionsIQ, Crisp, Johns Hopkins Applied Physics Laboratory, Unitarian Universalist Association, Motley Fool, Planon, FinnTech, OpenView Venture Partners,

Jyske Bank, BEC, Camp Scrum, DotWay AB, Ultimate Software, Scrum Training Institute, AtTask, Intronis, Version One, OpenView Labs, Central Desktop, Open-E, Zmags, eEye,

Reality Digital, DST, Booz Allen Hamilton, Scrum Alliance, Fortis, DIPS, Program UtVikling, Sulake, TietoEnator, Gilb.com, WebGuide Partner, Emergn, NSB (Norwegian Railway),

Danske Bank, Pegasystems

1Sunday, September 13, 2009


Jeff Sutherland, Ph.D.

Chairman, Scrum Training InstituteCEO Scrum, Inc. and Senior Advisor, OpenView Venture Partners

Igor Altman OpenView LabsOpenView Venture Partners, Boston, MA



Agenda

Introduction

Getting Started with Scrum: Trial by Fire

Scaling Up: Finding the Rhythm

Where we are in November, 2008

Key Lessons Learned



Changing the World of Work

Scrum is useful for improving productivity, quality, and life style of any team.

It can deliver twice as much for half the work

Siloed specialists become cross-functional team members

Working together and helping each other is more satisfying to team members and the customer

Extensive Scrum knowledge is available from thousands of IT teams, but little is known about how Scrum works outside of software development



Scrum for Organizational Transformation

The Agile Manifesto is more than software principles. It is about organizational transformation.Aggressively implementing Scrum with cause the organization to tune itself for high performanceOpenview Venture Partners strives to remove all impediments. This causes complete reorganization about every three months.Studying the venture group is like studying fruit flies in the laboratory. Cycle time of generations is very fast.



The Goal



Context

OpenView Venture Partners was founded in 2006 with an initial fund of $107M. A second fund was closed in 2009.OpenView mission:– Build great companies by providing hands-on strategic and

operational assistance to each and every portfolio company– Deliver top investment results



Rapid Growth

September, 2006 September, 2007 September, 2008

Employees: 9 Employees: 13 Employees: 22

Portfolio companies: 0





OpenView Labs

Created to provide strategic and operational assistance to portfolio companiesMission:– Gather, Create, Store, and Disseminate Best Practices and

Expertise for the benefit of OpenView prospects, portfolio companies, the OpenView team, and our community

– Provide high impact execution assistance to OpenView portfolio companies



• Product Development- Product Management- User Experience Development- Development (implementation)- Fulfillment Management

• Go-To-Market Development- Marketing - Direct sales- Channel (indirect sales)- Professional Services- Customer Service- Training

Organizational and Operational Development– Finance– Human Resource Development– Legal– IT– Administration– Senior and functional Management

Development– Team development– Management System Development– Business Development– Corporate Development– Board/Governance– Investor Relations– M&A/IPO

OpenView Execution Assistance



OpenView Labs Work

• Workshops / Forums- OpenView Development Forum on TTD and CI - October 9-10, 2008- OpenView Product Management Forum - January 21-23, 2009- OpenView Extraordinary Execution Workshop – May 13-14, 2009

• Onsite Work and other Best Practice Transfer- Sales Management Recruitment, Training, Coaching- Sales Forecast Development- CRM Implementation and Customization- Compensation Plan Creation- IT Infrastructure Implementation- Development process training and coaching- Product Management training and coaching- Financial team and process development

• Framework Development and Training- Customer Acquisition Framework- Channel Approach Framework- Product Management Framework



What Next?

How do we scale?

That is, how do we add MORE value to MORE portfolio companies with LESS management overhead?



OpenView Meets Scrum

By mid January, 2008, the entire OpenView team and OpenView’s portfolio are ScrumMaster Certified by Jeff Sutherland.



Getting Started with Scrum:

Trial by Fire



Scrum is a Simple Framework

Scrum

Meetings

Sprint Planning

Daily Meeting

Roles

Team

Product Owner

ScrumMasterArtifacts

Burndown Charts

Sprint Backlog

Product Backlog

Sprint Review



The Components of Scrum

RolesProduct Owner: Scott Maxwell, Managing Director and FounderScrumMaster: Igor AltmanTeam: Igor plus 3 specialists

MeetingsSprint Planning: Monday for half day. Team tends to preassign work before sprint planning.Daily Meeting: Daily Scrums last 45 minutesSprint Reviews: Retrospectives are held Monday morning and generate impediment lists.



The Components of Initial Scrum

Artifacts

Product & Sprint Backlogs: The Labs Product and Sprint Backlogs are housed in Central Desktop, an online collaboration platform. The stories are each Labs team member’s individual projects.Stories are vague, with no clear definition of done.A lot of back and forth with Product Owner is required during the sprint to clarify what is actually needed. Burndown Chart: There is no burndown chart



Measurement of Scrum

Sizing Stories are sized using ‘perfect hours’ using an approach similar to planning poker, with fingers on hands instead of cards.

A story’s size is defined as the amount of time it would take the average team member to complete the story assuming ideal conditions (100% focus, no interruptions).

A ‘perfect hour’ is only counted as done if the entire story is done.

‘Perfect hours’ are used instead of story points because: •They are easier for the team to understand conceptually•Many Labs stories are already time-based (meetings, calls, time-boxed research stories, etc.)•Many Labs stories, especially early on, are really smaller Tasks

This makes it impossible to track velocity properly.



Measurement of Scrum

Velocity (not possible to calculate in perfect hours)

Each team member pulls 20 perfect hours of stories each Monday, assuming a 50% focus factor on a 40 hour work week, for a total team commit of 80 perfect hours

Unplanned story points are counted separately, so that velocity only captures points against the committed stories, or those pulled forward from the product backlog

The team does not always complete the sprint successfully

Trying to improve, the team starts taking on more perfect hours, more stories, and fails sprints

Perfect hours completed stays flat at 80 or lower



Benefits of Scrum

The team starts to become more self-managing

Communication within the team rises drastically

Low value work is eliminated (30% of the original workload)

Impediments around lack of clarity, lack of communication, and poor requirements are surfaced and removed

Some collaboration begins to emerge

Individual stress is reduced



ChallengesTeam is still mainly a collection of individuals working side by side

Scrums and Planning meetings are lasting a long time

The team is working long, intense hours on too many projects and is failing sprints

There is bad communication between the team and the rest of the firm, especially those people who originate the stories

The impact of the stories is unclear

The entire team is not fully sold on Scrum, picking and choosing elements that fit them well and discarding the rest

Some people, especially one individual in particular, are feeling discomfort in response to the new team environment and the transparency and mutual accountability that goes with it.



A note on points versus ‘perfect hours’

The entire team is aware of the shortcomings of using ‘perfect hours’

It is impossible to improve velocity without improving the focus factor or number of hours worked

Productivity improvements that allow the team to complete the same stories with less effort go largely unnoticed in the velocity, since the perfect hours size is accordingly reduced

There is disagreement on how long something would take the “average” team member, since the team is diverse

Still, the team struggles with the story point concept, and finds that ‘perfect hours’ generally suit their needs

This issue comes up for debate several times through the course of over a year of Scrum, and the team continues to stick with perfect hours



A note on the long, intense hours

Within months of Scrum implementation, Scott Maxwell and his team recognize that Scrum creates a much more focused, intense, and ultimately productive work environment.

As such, working the same long hours the team was doing before Scrum no longer makes sense. It can get more done in less hours!

Scott draws the Maxwell Curve to drive his point home with the team, setting a new culture of working less than 50 hours per week, no weekend work, and shutting down during vacation.

Working late hours becomes a negative sign of working too much and being unfocused.



Scaling Up: Finding the Rhythm



The Components of ScrumRoles

Product Owner: Scott Maxwell, Managing Director and Founder

ScrumMasters: Igor Altman and Brian Zimmerman

Team: As the team grows from 4 to 6, to 9 members, it splits into two teams for easier self-organization.

Meetings

Sprint Planning: Sprint Planning now takes half as much time as before on Monday, even though the team now truly plans work as a team. It is also now done using post-its on a wall in the ‘Scrum Room’, rather than huddled around an online spreadsheet as before.

Daily Meeting: Daily Scrums now last 15 minutes

Sprint Reviews: Retrospectives are held every Monday morning, covering the previous sprint, and are used to generate impediment lists. There is now a tracked Impediment Backlog for impediments not immediately removed.



The Components of ScrumArtifactsProduct & Sprint Backlogs: The Product Backlogs are still housed in Central Desktop, but the Sprint Backlog now consists of post-its on a wall in the ‘Scrum Room’. Product Ownership is beginning to take more form:

Each portfolio company has a product backlog, owned by a Senior Point Person, the Product Owner for that company.Each functional area within OpenView Labs is designated as a Practice Development Area, has its own product backlog that is owned by a senior Practice Development head (or one in training).

Stories are now much clearer, and less communication is required during the sprint to get things done. The definition of done is clarified and standardized across every story

A story is done when its deliverable has been posted to Central Desktop, along with clear next steps, and the project stakeholders and backlog product owner have been notified.



The Measurements of Scrum

Sizing

Stories are still sized the same way, with sizes of many stories going down with improved productivity.

Velocity

The team now commits to the same number of ‘perfect hours’ it completed last week, less unplanned stories for a buffer, following yesterday’s weather, and lands almost every sprint.

Through trial and error, the team learns that the more it takes on the less it completes, and the less it takes on, the more it completes.



The Measurements of Scrum

Velocity While we do not have true velocity to measure improvement, we can estimate a significant improvement from the following data points:

Velocity went up from: 4 people completing 80 ‘perfect hours’ working 50-70 hours/week/person, to 9 people completing 190-200 perfect hours working 40-50/hours/week/person

Story sizes have on average been reduced, with some stories going from 1 perfect hour to 0, others from 5 to 1, and so on. We can conservatively assume a 20% decrease in story size. The definition of done increased the average story size by at least 10% This represents an approximate velocity improvement of 80-100% from January to October 2008.



Benefits of ScrumThe Chief Product Owner, Scott, feels that the value produced by Labs has increased by “150%, bare minimum”, and the team has higher morale as a result. There is transparency and accountability within the Labs team and between the Labs team and the portfolio company point people / product ownersEvery team member now knows exactly what they need to do and why at the beginning of every weekMore work is done in less hours. Late nights and weekend work are rare and frowned upon. Sustainable pace is the goal.The Labs team has gone from working with six portfolio companies to working with 10 without getting overwhelmed or drop-off in qualityNew team members are integrated into the team and workflow extremely quickly via ScrumTeam collaboration and cross-training increaseLess outside management is required



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 to work for OpenView outside the Scrum process.

While overall output quality and quantity are 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 story impact

While team collaboration has grown significantly, a good number of team members still work as individuals within the team on many projects

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 done in parallel



Where We Are in November 2008



35

As of November 2008

Two teams, 4 people each, with a combined “velocity” of approximately 180High moraleContinuous improvement22 full time employees10 portfolio companies10 practice development areas



36

Initiatives in November 2008 and

BeyondFocusing on higher impact Initiatives / Epics and 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 new team members

Each Friday, all the portfolio company point people / product owners attend a debriefing meeting with the Labs team, discuss results of the sprint’s stories, and get sharper on next sprint’s goals and stories

Implementation of the Scrum tool VersionOne (www.versionone.com) to meet the need for a more sophisticated backlog/sprint management.


http://www.versionone.com/

http://www.versionone.com/


Key Lessons Learned



FourKeyComponentsPart 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.

BALANCE

Direction

Speed

Quality

Sustainability/Predictability



39

FiveDysfunc4onsofaTeam

Trust – Team members must trust each other, allowing for open, transparent discussion of difficult issues and personal weaknesses without defensiveness.

Conflict – Team members must embrace conflict as a path to issue resolution

Commitment – Team members must commit to team and personal goals

Accountability – Team members must hold each other accountable for achieving goals

Results – Goals must drive toward measurable results, and ultimately that is what the team is accountable for

A Team’s Culture must have the following Elements to successfully implement Scrum:

See Patrick Lencioni’s ‘The Five Dysfunctions of a Team’



40

NotforEveryone

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.



41

RootCauseAnalysis

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.



Key Observations

Aggressive removal of impediments caused complete reorganization about every four monthsEach refactoring of the teams addressed growth issues and key impediments relevant to stage of maturityEach led to a more mature implementation of ScrumBy the end of 2009, Openview will have completely reorganized six timesTeams with poor performance are disbanded and members are moved to high performing teams



Take No Prisoners

This strategy will radically transform your organizationIt will move your teams from the minor leagues to the major leaguesNothing will ever be the same



Questions?

High Performing Teams



45

SpeakerContactInforma4onJeff Sutherland, Ph.D.Scrum Training Institute www.scrumtraininginstitute.comBoston, [email protected]

Igor AltmanOpenView Labs & OpenView Venture Partnerswww.openviewpartners.comBoston, [email protected]


mailto:[email protected]






http://www.openviewpartners.com/

http://www.openviewpartners.com/



take no prisoners - jeff sutherlandjeffsutherland.com/scrum/takenoprisonersscrumday.pdf ·...

Documents