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.
This book is about my own journey to excellence – I hope it helps you too!
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!