Agile in Practice: What Is Actually Going On Out There?
Scott Ambler talks about actual data resulting from surveys made during 2006-2008, showing how Agile is perceived and implemented within organizations.
Tracking change and innovation in the enterprise software development community
Posted by Chris Sims on Jul 21, 2008 09:42 AM
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.
Gamma's Jazz platform's first implementation: Rational Team Concert (Trial Download)
The Agile Business Analyst: Skills and Techniques needed for Agile
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
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.
They have been doing this since the early 70s!
Wow, that's cool. I wonder then why this model hasn't been more widely adopted by artistic non-profits?
Scott Ambler talks about actual data resulting from surveys made during 2006-2008, showing how Agile is perceived and implemented within organizations.
From QCon 2008, Daniel Moth presents on using Visual Studio 2008 and .NET 3.5 to create compelling rich Windows applications.
Joshua Kerievsky, founder of Industrial Logic, talks about Industrial Extreme Programming which extends XP by including practices dealing with management, customers and developers.
Amazon Web Services (AWS) Evangelist Jeff Barr discusses SimpleDB, S3, EC2, SQS, cloud computing, how different Amazon services interact, origins of AWS, AWS globalization and the March AWS outage.
Cloud services have helped bring virtualization to the forefront. Its full power however, also includes other benefits such as high availability, disaster recovery, and rapid provisioning.
John Lam talks about his path to dynamic languages, some of the problems of making IronRuby run fast, and how the DLR helps with implementing languages.
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.
3 comments
Reply