BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Renowned Orchestra Embraces Scrum-like Practices

Renowned Orchestra Embraces Scrum-like Practices

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

BT