InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Renowned Orchestra Embraces Scrum-like Practices

Posted by Chris Sims on Jul 21, 2008

Sections
Process & Practices,
Architecture & Design
Topics
Teamwork ,
Leadership ,
Agile ,
Collaboration ,
Stories & Case Studies
Tags
Management ,
Culture Change ,
Interpersonal Communication ,
Continuous Improvement

The traditional roles on a scrum team are: Product Owner, Developer, and Scrum Master. Noticeably absent is the role of Team Leader; the team is expected to self-organize. Similarly, Orpheus Chamber Orchestra has dispensed entirely with the role of conductor in favor of a process where leadership is shared and decisions are made by the team. The result has been to create one of the world's most renowned chamber orchestras. Along the way, they have learned lessons and ways of working together that any Scrum team can benefit from.

The most recent edition of the IEEE Engineering Management Review included an article titled "The Conductor-less Orchestra", which was previously published here in the Leader To Leader Journal.  The article discusses the success that the Orpheus Chamber Orchestra has achieved by replacing the traditional command-and-control leadership model with a more participatory model, called the Orpheus Process.  This process is based on eight principles.

Principle 1: Put power in the hands of the people doing the work

According to double-bass player Don Palma, a member since the group's founding in 1972, the difference between working in Orpheus and working in a traditional orchestra is dramatic. Says Palma, "I took one year off from Orpheus at the very beginning and went to the Los Angeles Philharmonic. I just hated it. I didn't like to be told what to do all the time, being treated like I wasn't really worth anything other than to be a good soldier and just sit there and do as I was told.  I felt powerless to affect things... Orpheus keeps me involved. I have some measure of participation in the direction the music is going to take. I think that's why a lot of us have stayed involved for so long."

Similarly, a member of a traditionally organized software organization may feel that they have almost no power to affect their team or product, and are only valued for their ability to create the code that they are assigned.  A member of a Scrum team is expected to collaborate and contribute in whatever way they can to the over-all success of their team and product.

Principle 2: Encourage individual responsibility for product quality

Because Orpheus has no conductor and therefore no single person to take responsibility for the quality of its performances, each member of the orchestra feels a very real and personal responsibility for the group's outcomes. Orpheus gives every individual the opportunity to lead, but it also creates an imperative that everyone pull together. Instead of focusing solely on perfecting their own approach to performance, each musician takes a personal interest in perfecting the performances of their colleagues and the overall sound of the orchestra.

On a Scrum team, quality is the responsibility of the whole team.  It does no good for one person's code to be bug-free, if problems in other parts of the code base make the product unusable.  Therefore, team members are encouraged to seek out and adopt quality-enhancing practices such as Behavior Driven Development, Pair Programming, Continuous Integration, and automated Acceptance Testing.  Furthermore, the Scrum practice of retrospectives helps teams to find areas where their practices can be improved.

Principle 3: Create clarity of roles

While there is no conductor in Orpheus, there are well-defined roles.  For each piece the orchestra will perform, a single member is elected as concertmaster.  Other well-defined roles are also filled.

On a Scrum team, there are 3 well-defined roles: Product Owner, Scrum Master, and Developer.  The Product Owner manages the product backlog, setting priorities and deciding which features (stories) will get worked on first and which will wait.  The Scrum Master looks out for the process and usually facilitates meetings and important team interactions.  Developers create the product.  The blanket term 'developers' may include people with specialties in testing and documentation, as well software developers.

Principle 4: Foster horizontal teamwork

Because no one person has all the answers to every question that may arise within the orchestra, Orpheus relies on horizontal teams -- both formal and informal -- to tap the expertise of all of its members. These teams are horizontal because members are not artificially limited to focusing their attention on only very narrow issues or opportunities; members of teams within Orpheus naturally reach across organizational boundaries to obtain input, act on opportunities, solve problems, or make decisions.

Scrum, and especially Scrum of Scrums, provides a framework in which this notion of horizontal teamwork could be applied to a software project.

Principle 5: Share and rotate leadership

Most orchestras have a single leader, the conductor.  Instrumentalists are expected to do as instructed, and generally not offer their own interpretations.  Orpheus intentionally rotates leadership on a piece-by-piece basis, choosing leaders based on their knowledge of, and passion for the particular piece.

On a Scrum team, the lack of a formal leader allows different individuals to contribute leadership at times when their knowledge and skills are the best fit for the team's current needs.  If a team's top priority is to fix a quality issue, a QA person may be leading the effort.  If the team is adjusting the design and architecture of the code by refactoring, a senior developer or software architect may take the lead.

Principle 6: Learn to listen, learn to talk

The members of Orpheus know the power of communication, and it is the lifeblood of the organization. Not only are members expected to listen to one another's views and opinions, and to respect what is said and the person who said it -- whether or not they agree with what is being said -- members are also expected to talk.

Clear and continuous communication is also the lifeblood of a software project.  Practices such as the daily standup meeting, retrospectives, and the involvement of the Scrum Master are designed to keep information and ideas flowing.

Principle 7: Seek consensus (and build creative systems that favor consensus)

The more important a decision is to the orchestra, the more people are involved in making it.  This stands in contrast to much of the business world, where the most important decisions are made by the few at the top of the org-chart.  It would be reasonable to fear that making creative decisions by consensus would lead to bland and uninteresting results, but Orpheus' results prove that this needn't be the case.  Orpheus is recognized internationally for it's excellence, regularly plays at Carnegie Hall, and has even won a Grammy Award.

In a traditional software organization, important decisions such as architecture and design are often made by anointed individuals then handed off to others to implement.  A Scrum team will tend to discuss such important matters with as many members as possible so that they arrive at a decision that the whole team understands and supports.

Principle 8: Dedicate passionately to your mission

It is a commonly held belief that employees that are passionate about what they do create the best products, teams, and companies.  The Orpheus Process is designed to remove impediments to participation and thus tap the passion of each member.

A measure of the passion that Orpheus's members feel for their organization is the fact that although the majority of them also play for other groups, including the New York Philharmonic and the Metropolitan Opera, and teach at schools such as Juilliard and the Manhattan School of Music, they consider playing for Orpheus to be their most fulfilling musical experience.

Scrum works in ways that are similar to the Orpheus Process to unleash the passion of each team member and encourage and empower them to create the best software product possible.

  • This article is part of a featured topic series on Agile
And the results are...? by Kurt Christensen Posted
Re: And the results are...? by Chris Sims Posted
Re: And the results are...? by Kurt Christensen Posted
  1. Back to top

    And the results are...?

    by Kurt Christensen

    Sounds fascinating! As an "agile" advocate, I wish them success, but it would be interesting to see down the road how the process has enabled them to fare (relative to similarly-sized groups in similarly-sized metropolitan areas) with regards to critical acclaim and fundraising efforts.

  2. Back to top

    Re: And the results are...?

    by Chris Sims

    They have been doing this since the early 70s!

  3. Back to top

    Re: And the results are...?

    by Kurt Christensen

    Wow, that's cool. I wonder then why this model hasn't been more widely adopted by artistic non-profits?

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.