|
|
Do you have a topic you'd like Thorkil to write about? Click
here to send a request. |
|
|
|
Thorkil was unable to contribute
his regular article this month due to a nasty storm which
caused flooding in his home. We wish Thorkil & his family
best wishes as he works to clean up what Mother Nature has
dealt him.
In the place of Thorkil's article, we offer a tech note on
one of the products that has had some recent increased
interest, the TADS Ada Static Dumper. |
 |
TADS Ada Static Dumper
The TADS Ada Static Dumper is a tool which
provides developers with information about the variables, constants,
packages, tasks, and subprograms that comprise a linked Ada program.
This tool reads the AdaScope debug directives for a particular
program and reports the locations of the objects which reside in
constant (i.e., static) places in memory throughout the program's
execution.
This information is most useful for connecting
TADS products to proprietary development systems using local
hardware debug support. It is also quite useful for developers
writing independent testing and analysis tools.
The static dumper produces a text file as its
output. All names used in the output file are fully qualified Ada
names. The format is designed to be easily read by users or parsed
by programs. The output file may be printed on a wide (120 column)
printer or in landscape mode on printers which support it.
Variables which are global to library level
packages (whether exported or private) are reported. These variables
are always be stored at a fixed memory address. However, variables
which are local to subprograms are not reported because they are
relative to the frame pointer, and may be stored anywhere in memory.
Parameters and function return values are also
listed. These values are usually in registers or relative to the
frame pointer. Even so, this information should be used with care.
The TADS Ada Compiler often uses copies of these values in the
course of optimization.
Subprograms and other pieces of Ada code are
listed if they have been linked into the program. In this case, the
static dumper lists the addresses. These addresses include the first
and last address in the code entity as well as the beginning and end
of the Ada body code.
All constants and enumerated types in the program
are listed in both their symbolic and actual value notations.
Similarly, both notations are used for any arrays which are indexed
by an enumerated type.
Finally, the locations of all constants which
could not be efficiently implemented by placing them in the code
stream are indicated.
[
Back to Top ]
Self-Organizing Teams
By Linda Rising
risingl@acm.org
www.lindarising.org
The concert at Carnegie Hall is about to begin. The musicians
take their places on the stage, making final adjustments. The
audience becomes quiet. For those who have never enjoyed a concert
by this particular ensemble, it quickly becomes obvious that there’s
something unusual, something unique about it. There is no conductor.
I’ve written several articles about agile
development. Even though I’ve used agile development
methods and I consult with companies who want to use it, there are
many things I don’t understand about it. One of these things will
be the topic of this article. It’s called
"self-organization." The goal in agile approaches is to
have self-organizing teams—yep, exactly what it sounds like—teams
that take care of themselves. Does this mean there is no need for
management? The answer is—of course not! However, management does
involve new roles and new tasks.
I read an article some time ago in Fast Company [1], one
of my favorite business magazines, about the Orpheus Chamber
Ensemble. Since I’m an amateur musician and self-appointed leader
of our little recorder consort, I was interested to read about the
"world’s only conductorless orchestra." I later found an
article about the process the orchestra follows [2] and then,
finally, on a business trip last week, I found some airline reading
time to tackle a book [3] about this unusual group. When I arrived
home, I was able to track down one of their CDs. It was glorious.
Now, maybe you’re not interested in classical music. That’s
OK. What you are interested in, I’m guessing, is any organization
that’s found an innovative way of producing high-quality products
and/or services. That’s what this article is about.
Let’s start with some data for all you detail-oriented readers.
The Orpheus Chamber Orchestra comprises 27 seasoned professional
musicians. Many in the group record for the television and motion
picture industry, play in other musical groups, and teach at leading
institutions: Julliard, the New England Conservatory, the Manhattan
School of Music. Carnegie Hall, one of the world’s most
prestigious performance venues, is Orpheus’ home base, a
distinction shared by only one other orchestra.
The group was founded in 1972 as a self-governing organization.
Orpheus isn’t just a musical oddity—and the subject of study by
business educators and leaders—but one of the finest chamber
orchestras in the world. The group’s recorded catalog has more
than 60 titles, and the orchestra is in demand internationally each
season, having won numerous awards for its performances and
recordings.
OK, OK, enough. It’s a great group. You’re probably thinking,
"Yeah, yeah, a collection of musical geniuses who don’t need
a conductor. What’s that got to do with me and my group? They’re
hard working and bright, but maybe not geniuses. Is there any of
this I can use?"
First, stop and think about it. Genius musicians collaborating.
Does it sound like an oxymoron? Geniuses almost by definition are
opinionated—especially musicians. How do they ever agree on
anything? Talk about trying to herd cats! That’s why conductors
are so fierce. They have to pummel these hardheaded, single-minded
folks into signing up for the vision they see for each composition.
Here’s an interesting statistic. As talented and hard working
as these folks are, orchestral musicians are a surprisingly unhappy
class of employees. When Harvard Business School professor J.
Richard Hackman studied job attitudes among people working in 13
different job groups, he discovered that symphony orchestra
musicians ranked below prison guards in job satisfaction.
When I read this, I was very surprised. These folks earn good
money doing work they love, traveling to exciting venues, soaking up
the applause of appreciative audiences all over the world. The
surprises continue. When asked about their satisfaction with
opportunities for career growth, symphony orchestra musicians fared
even worse, ranking 9th out of the 13 surveyed job categories.
Although the product or service of an orchestra can be exceptionally
uplifting for those who are on the receiving end, for the producers,
it seems it’s not especially rewarding.
The problem lies with the organizational structure that forces
them into subservient roles that lead to frustration and job
dissatisfaction. Many "knowledge workers" suffer the same
ills. Research by Carnegie Mellon business professor Robert Kelley
shows that 40% of those surveyed believed that their bosses had
questionable leadership abilities.
We can see two problems. One: organizations fail to take
advantage of the skills and talents of every worker and pay a high
opportunity cost. Two: disenfranchised employees grow frustrated and
cynical about the select few in leadership roles.
I hope I’ve convinced you that this story is worth hearing—that
musicians have an important message for those of us in product
development, in fact—for anyone in any organization in today’s
chaotic business environment.
In most orchestras, the conductor not only decides what music
will be played but how it will be played. There is little
room for the opinions or suggestions of the musicians themselves;
such input is rarely solicited and even less often welcomed. Like
workers reporting to an autocratic manager, orchestral musicians are
expected to unquestioningly follow the direction of the conductor.
In contrast, each member of Orpheus takes a turn at leadership
positions: leading the group in rehearsal and performance as
concertmaster or leading one of the orchestra's many formal or
informal teams. Musicians move in and out of positions of leadership
to allow the orchestra to quickly adapt to changing conditions in
the marketplace or within the group itself.
This system encourages all the members of the orchestra to give
their personal best performance. Cellist Eric Bartlett says,
"When there's an important concert, everybody feels it, and
everybody goes into it doing their absolute best work, giving it
their utmost concentration, playing off each other, and making
sparks fly. For the most part, in a conducted orchestra, you play a
more passive role. Not only is less expected of you, but less
is expected from you. You have to play extremely well, but
you're not playing off your colleagues -- you're playing off the one
person in front of the orchestra holding the baton. I don't see that
people in regular orchestras are emotionally involved in the same
way. Everybody plays well; they do a very good job, but the level of
individual emotional involvement isn't there."
That sounds like something I would say to describe a team that
successfully uses Scrum!!
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 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, particularly when they were
not going well. I felt frustrated, and there was nothing I could do
to help make things better. 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."
Here’s a brief description of the Orpheus Process. It comprises
five key elements.
1. Choosing Leaders. For each piece of music, a committee
of musicians chosen by orchestra members selects a concertmaster.
The orchestra members also select a leadership team of five to seven
players, called the core. The concertmaster anchors the core, leads
performances, and works closely with all the musicians to develop a
unified vision for the music. The concertmaster is selected on the
basis of the skills and knowledge he or she brings to the piece. An
expert in baroque music will be selected to lead a Handel selection.
Someone who is particularly knowledgeable about 20th
century composers will take on a Stravinsky piece. In this way,
leadership is shared and rotated among the different members of the
group, and the group benefits from the strengths of individual
members.
One of the important pieces of agile methodology is pair
programming. You can read
a couple of articles I wrote on that topic here. Pairing
assignments are made in exactly the same way as leadership choices
are made for a particular composition. You pair with Fred because
you need some database expertise and Fred knows all about the
database. You pair with Karl when you need an Ada guru. In the
pairing experience, you not only tap the expert’s knowledge, but
you learn more about the subject and you share your expertise.
2. Developing Strategies. Before a piece of music is taken
to the full orchestra, the core decides how it will be played. The
goal is to develop an overall interpretive approach to the music.
The core group’s concept is crucial to setting the stage but it
isn’t the final word. The core accomplishes this goal through
rehearsals where different approaches can be suggested. Says
violinist Ronnie Bauch, "The core groups formulate one
interpretation of a piece. It’s not necessarily the final
interpretation. It’s just a starting point."
This is exactly how agile teams work. An initial starting point
and a clear vision are necessary, but the implementation details
can change along the way, as long as there is close communication,
not only within the team, but with the customer, project manager,
and product manager.
3. Developing the Product. After the core is satisfied
with its approach to the piece, it is taken to the full orchestra to
be rehearsed and refined. Musicians in all sections of the orchestra
make suggestions to improve the piece and critique the playing of
their colleagues. When disagreements arise, as they do in any
organization, the members work to reach consensus. If consensus
cannot be reached within a reasonable period of time, then a vote is
taken and the issue is settled.
As I read this, I was reminded of a retrospective I facilitated
recently, where during the multi-year project two
"chief" architects arose with two "visions" of
the product. Wars were fought by teams pretty much determined by
the aisle where their cubicles were located. Consensus was never
reached, in fact, no one really communicated with anyone so that
anyone really understood the issues. The project was finally
cancelled. It produced nothing useful. What a waste. If only there
had been regular Scrum meetings. If only there had been regular,
short retrospectives, a more successful outcome would have
resulted.
It’s not always easy to reach consensus. A group that is used
to following a process realizes that at some points "we agree
to disagree" and move on. By agreeing to take a path and
learn along the way, the group avoids getting stuck and battling
forever. Many times, even after consensus has been reached, the
group remains agile and continues to learn and finds that a
completely new approach is the one the group ultimately takes.
4. Perfecting the Product. Immediately before every
concert, one or two members of the orchestra are selected to go out
into the hall and listen to the performance as the audience will
hear it. These musicians report back to the entire group and suggest
final adjustments and refinements based on the actual sound of the
full orchestra.
I love this! On an agile team, this step corresponds to showing
the stakeholders what you have along the way. "Hey! Look at
this! Are we meeting your expectations? Are there any tweaks that
would improve it?" Instead of waiting for months or years
before getting any feedback, wouldn’t it be better to stay in
touch?
5. Delivering the Product. The final step is the
performance, the ultimate result of the Orpheus Process, but it does
not end here. After every concert, participants informally discuss
their impressions of the performance and make suggestions for
further adjustments and refinements -- all with an eye to improving
subsequent performances of the piece.
As you might guess, I really like step 5. I would say that
Orpheus takes time for reflection or that it does retrospectives.
Without this last, very important piece of the process, learning
would not happen. We all want to believe that learning is
automatic, but research has shown that experience provides data
and that we must consciously take time to process this data in
order to learn.
If I’ve piqued your interest in agile processes, you can have a
look at some articles I’ve written about this development
approach. The Fast Company article is on-line for more
information about the conductorless orchestra. And I’m always here
to exchange e-mail about these ideas. I always enjoy hearing from
you!
References
1. Lieber, R., "Decisions Are in the Details," Fast
Company, May 2000, 296 http://www.fastcompany.com/magazine/34/orpheus3.html
2. Seifter, H. The Conductor-less Orchestra, Leader to Leader,
No. 21 Summer 2001.
3. Seifter, H. and P. Economy, Leadership Ensemble: Lessons in
Collaborative Management from the World’s Only Conductorless
Orchestra, Times Books, 2001.
 |
About the Author
http://www.lindarising.org
risingl@acm.org
Linda Rising has a Ph.D. from Arizona
State University in the area of object-based design metrics.
Her background includes university teaching as well as work
in industry in telecommunications, avionics, and strategic
weapons systems. She is the author of numerous articles and
has published three books: Design Patterns in
Communications, The Pattern Almanac 2000, and A Patterns
Handbook. She is currently writing a book with Mary Lynn
Manns: Fearless: Introducing New Ideas into Organizations, to appear in September 2004. |
[
Back to Top ]
|
