View of The Product Team As A Rock Band

By -
This thought came to my mind as I was reading a review of Tom Petty's biography on the cover by Stephen Dubner:
"This amazing book is a Tom Petty biography (and it's great on that account) but it's far more than that. It's an X-ray of the most fragile, most volatile, and most sublime social unit ever invented: the rock-and-roll band. The alliances, the distortions, the deep bruises and the absurd elations that can never be explained to an outsider. Sure, Petty is a book about a rock band but it's really a book about being human - how we meet and collaborate, break up and make up, learn to trust (or not) and, once in a lucky while, sing as loud as we can. It's a masterpiece.”

If the rock-and-roll band is "the most fragile, most volatile, and most sublime social unit every invented" the software development product team is somewhere in the top 10 of that category.

I've never been part of a rock band, but I have worked with many software development teams.  Software developers come in all shapes and sizes, so I'll not try to apply a general classification to the team members, but many of them are bright, creative, individualistic people who take pride in their craft and enjoy doing what they do.  This description would seem to apply to many band members as well.

I imagine a successful rock band has accomplished some of the same things as a successful software development team, including:
  • Learning to collaborate and cooperate as a unit more than as a collection of individuals
  • Balancing the desire for innovation and unbridled creativity with the imperative to produce something
  • Finding the right place for each member of the team in the social unit of the team
  • Deciding at a point in time that the team's creation is good enough to release, and that delaying the release to make further refinements is not warranted
  • Maintaining a healthy sense of self-worth while absorbing pointed, often unjustified criticism
  • Trusting each other enough to put ideas out there to the group for discussion and debate
  • Recognizing that what has been released is good but can be improved upon, and that what will be released in the future will be different
And what about the Product Owner and Scrum Master role? Could they be like the producer and manager of the band?  They appreciate the value and brilliance of what the band is capable, but also recognize that without their participation, there is a real risk that the creative genius and technical excellence of the band members doesn't realize its full potential.

Update on July 31: I've finally finished the book.  Here's one of many choice quotes:
From Elliot Roberts, one of the band's managers over their lifespan, about making it clear to the band in their early days that Tom's vision was preeminent: "It was Tom's vision I was concerned with, not their vision.  I don't believe in equal opinion, I believe in best opinion."

Comments

Post a Comment

Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

By -
Defects and Risks are often dealt with in a subjective, emotional way.  That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue.  The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Read more

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

By -
Image
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization.  I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization.  Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
Read more

Chatbot Code of Ethics

By -
A  NYTimes article  describes efforts by a consortium of the largest technology companies to create ethical standards for AI. A related article in MIT Technology Review is titled  AI Wants to Be Your Bro, Not Your Foe . Artificial Intelligence has reached a level of sophistication, and is on the brink of being so pervasive, that we can have these serious conversations. In my work developing AI-powered chatbots to assist with learning, I work within the bounds of these 7 precepts: Right View - our chatbots honor humanity, human dignity, and the human quest for knowledge, understanding and technological innovation Right Intention - our chatbots promote human progress in the areas of intellectual pursuits and personal ethical development Right Speech - our chatbots use encouraging, prudent, and situationally appropriate language Right Action - our chatbots perform with integrity toward the aforementioned right view and intention Right Live
Read more