Preface: Great Big Agile
I wasn’t always a technologist. In fact, I was the furthest thing from it.
My childhood was a little different than most of
my friends. By eight years old, I was
touring in our family’s music group, joining my parents and three siblings as the
bassist for the Dalton Family Singers, a traditional American Folk Music group
that performed up and down the North American eastern seaboard from 1968 to
well into the 1980s. It was so “normal”
for me that I used to ask my friends where their family was touring this summer! The “Singers” was my father’s brainchild, who
reasoned that a family music group was the perfect incubator for his musical
children, and also an opportunity to practice and demonstrate to us the
entrepreneurship required to run a successful entertainment franchise in a
crowded market. Before the internet and
Twitter there was my Dad with his Typewriter, press releases and corded phone.
Following those years I attended formal music
school, first at the internationally recognized Interlochen Arts Academy, and
then the Peabody Conservatory of Music in Baltimore (now part of Johns Hopkins
University). I cut my studies short at
Peabody to spend the next decade honing my craft as a concert double bassist
with orchestras in Spain, Mexico, and the United States.
What did I learn during those years? Craftsmanship. Discipline.
Collaboration. Transparency. Perfection.
Persistaece. Ceremony. Value.
And also how to self-subscribe and commit to excellence while working
together with over one-hundred other artist under the direction of a conductor
to create some of the most sublime music known to mankind. It’s a pretty good model for agility.
The other important thing I learned was the art of the
retrospective. Notthe standard retrospective we usually see in the typical agile
teams, one of “what went well, what didn’t, and what could we do better” with
some people participating, and some grumbling a few perfunctory comments, but a
comprehensive and sometimes brutal process that kept many music students up at
night – known as “Juries.” A CEO friend of mine, who also happens to be a
musician and a visual artist himself, told me a story about his juries while
attending art school in Pittsburgh. I
recollect it went something like this:
“Juries in Art school
are brutal! They start right away during your freshman year don’t stop until
you’re done. Both your teachers and
fellow students critique your work in public, and most of them don’t hold back! Those were tough times, but their real value
is that you get used to the criticism, and your aversion to being evaluated
melts away before long, letting you really focus on what’s important – getting
better! You also make sure that your
next jury is as perfect as it can be!”
In the art world, where most of us aren’t Mozart or Salvatore
Dali, we know that the capability to be creative and innovative only comes
after the hard work has been done. Not
until the scales have been perfected, the arpeggios have been practiced until the
fingers bleed, the concertos have been memorized, the music theory classes have
been completed, and the performances have exceed the pre-requisite ten-thousand
hours, can we break the rules, experiment, innovate at a world class level. Only after we stop thinking about the process can we create something new,
innovative, and exciting. Agile isn’t
any different. In many ways embracing
agile requires the same commitment as a career in music or art – where rigor
and discipline are paramount, not just coding.
If this sounds like a systemic program to build a solid
foundation for quality and early defect detection, while embracing a culture of
excellence for continued high performance, it’s because that’s exactly what it
is In fact, trained musicians, artists,
and dancers entering the technology workforce have a significant advantage over
new engineers and software developers who don’t have this experience,– and it’s
the reason we often here that “musicians make good coders.” It’s not because “music is math,” by the way,
it’s the culture.
The first development team I ever led was building solutions
for the international retail market, and we were creating world’s first
touch-screen point-of-sale system. My second official act, after helping the
team to establish much needed discipline around coding standards, was to implement “juries:” public,
collaborative, and transparent code reviews with the code projected larger than
life on a ten-foot screen with the entire team in attendance. Team members were asked to present, and
defend, their design and coding decisions.
At first the team resisted with all their might – and who wouldn’t? It was nerve wracking, uncomfortable, and
stressful. But by the second month of
doing weekly reviews, the code quality went up dramatically and the team went
from combative and defensive individuals to an innovative, transparent, and
collaborative team. This was 1994 –
long before “agile” and values were in the headlines.
My journey from musician, to software engineer, to CEO has
been one of many twists and turns, but the most important concept I’ve learned
to harness along the way was “innovation lies on the far side of rigor.” While we all believe ourselves to be
innovative and creative, few of us are able to commit to the discipline to make
ourselves world class performers. But
the proven lessons from music can help us get there.
This idea of foundational craftsmanship and relentless
improvement found in the music industry can and should extend to the parallel
universe of software development, where adoption of agile values and frameworks
are akin to music theory and were designed specifically to foster innovation,
experimentation, and continuous learning. So far this level of performance has
mostly eluded very large organizations in the government and private sector who
want to “go agile,” but adoption of agile values along with an operating system
for agile leadership can help.
But all is not well in the Land of Agile either. Many large
adopters are struggling to achieve the results they expected, team members are
often uncomfortable with the ambiguity inherent in agile projects, line
managers don’t know how to lead in a high-trust self-organizing teams, and business
customers complain that they have to spend too much time working on the project
without getting the return on investment they were promised. In some cases, CIO’s are finding it so
complicated that they are now forbidding the use of Agile altogether! But, in every leading magazine, from Harvard
Business Review to the Cutter IT Business Journal to CIO, and in every major
survey, including Version One’s “State of Agile Survey,” we learn that the
responsibly of these, and other issues related to limited success with
large-scale agile adoption, rests squarely on the shoulders of leadership. My own observations from over two-hundred
agile assessments confirm this. While
leaders are telling their teams to “be agile,” they are not themselves
adopting, practicing, and projecting agile values. This creates an organizational type mismatch where leaders are practicing their
hard-earned command-and-control
techniques, and teams are trying to self-organize in what is inevitably a low-trust environment. If you were a leader who spent their entire
career learning to navigate in a low-trust environment, would you give it up
that easily? This leads to chaos.
I am lucky enough in my work to collaborate with some of the
greatest agile organizations in the world in my role as Chief Evangelist for
AgileCxO.org, a research and development organization who’s focus is on
performance models and assessment methods for large agile organizations. Through that work I have observed that:
Agile ceremonies often devolve into
“water-scrum-fall” with scrum masters tasking team
members, sprint durations
changing based on workload, team members moving in and out
of teams, and story
points being normalized between teams as hours.
- Leaders continue to resist high-trust, self-organizing values
- Product Owners are often “IT surrogates,” negating the value of the business owning the risk and ROI of the product.
- Retrospectives are rarely conducted beyond the individual agile team community
- Team members and leaders are not sufficiently trained in the rigor and discipline of agile ceremonies
- Traditional, often punitive metics are still being used, adding little value to the organization.
I was inspired to write this book while thinking of my
experience as a professional musician, and how it informed and affected my own
performance and thirty-year technology journey that started as software
developer, and then rapidly moved to project manager, architect, Chief
Technology Officer, Director of Product Development, VP of Global Consulting,
CIO, and finally CEO of two of my own technology companies.
I wanted to provide agile leaders with those lessons in an
illustrated guide that defines objectives, outcomes, and actions needed to
successfully lead large-scale agile organizations. The resulting model, the
Agile Performance Holarchy, is an implementation guide to bring solid
Craftsmanship, Discipline, Collaboration, Transparency, Perfection, Persistence,
Ceremony, and Value to your organization.
So join me in reviewing the scales, arpeggios, and concertos,
and building a foundation of discipline and rigor in order to establish a
sustainable and high performing agile organization.
You've been reading a sample from Great Big Agile by Jeff Dalton. If you like what you read, you can purchase Great Big Agile: An OS for Agile Leaders on Amazon, Barnes and Noble, or directly from the publisher at Apress.com.
Thank you for reading!
Thank you for reading!
