“This is so cool, bro! This is exactly what I’ve been wanting to do!” one eagerly exclaimed as another was nervously writing down every detail. One girl was already analyzing the next thing to work on while two others were pairing to figure out the configuration. The goal was to come together and produce a somewhat tolerable outcome and I sat back and watched unorganized chaos ensue.

The Team

Varied skills/abilities, existing/new relationships, uneasiness, motivated

This is not a software team that I’m describing but my co-workers attempting to produce music together for the first time. We have the less talented yet driven and overly excited electric guitar player, who simply wants to smoke, drink, have fun and jam. There’s the professional singer with the right tools consisting of cell phone with lyrics, wireless microphone, mixer, and PA speakers who knows exactly what she has only rehearsed. We have the methodical classical pianist who is not an active player but asked to play improvisation, dynamically learn the song at play, and reach out of her comfort zone. Two acoustic guitar players who frequently play together, socialize together, and know tons of songs but are focused on each other only. Another is the no-show who actually sparked the interest to organize the event in the first place but got caught up at work. Then there’s the veteran drummer, guitar player, and singer/song writer who can lead, record, learn anything, and has spent most of the time improvising and playing in situations like these. That one is me.

We often find this in our software delivery teams. The range of skills from problem solving, code fluency, autonomy, resoluteness, empathy, communication, to testing, algorithms, business analysis, infrastructure, database, back-end, front-end, architecture, and design varies within the team. On my team we have some brilliant developers that can’t quite grasp those soft skills. Or the developer that just wants everything specified and to start coding. There’s also the loner that doesn’t quite want to use the framework in place.

Mixing these types together is analogous to the kitchen sink. Aside from all of the differences if we follow the disorderly path we as a team still produce an outcome. It’s understanding one another that helps us navigate to the end goal.

Emergent Leadership

Lack of a leader leads to initial inefficiency, emergent leadership and eventual consistency

My normal band members that I played with would get together to instantly, confidently, and fluently express music that uniquely identified our traits, skills, and ideas. However, my co-workers had never played with each other and needed to understand one another for the very first time. As I watched the chaos I desperately wanted to string everyone together, guide them with songs I knew or simple ideas that could get everyone playing in unison. After all, I was a team leader at work and now having revelations about how leadership could influence the group. Instead I sat back and watched everyone explore music in their own way.

Those who knew songs attempted to teach others, but lacked the ability to keep the group focused on that very one song. The overly excited guitar player wasn’t even playing guitar but chatting and distracting, the pianist had to stop everyone to document the chords before being able to play them, and the singer was face-down reading the lyrics. Eventually a song came together without someone specifically conducting. Can the same be done in software development?

Leadership means control, even if you use the 7th level of delegation as described by Jurgen Appelo to leave the decision to that person. You are leading by telling others to do something even if they have complete ownership of it. This creates at a minimum some conformity and had I started to lead the entire night it would have been in a direction that I felt it should go. This contrasts greatly from letting group interaction be the leadership. In Agile software teams this may be the beloved or hated flat hierarchy.

I find that leadership can bootstrap the process and make a team focused on delivery with the trade-off of organic growth, creativity, and complacency. Those less-skilled need to follow so they can learn. Some team members may disagree with a certain approach or decision yet go along with it because everyone is following the leader. In my software team this happened when our leader left the company and suddenly barriers were removed, thoughts were flowing, and decisions were collaborative.

The co-worker music group had no goals but to make music, which is very broadly defined, and each person had different intentions of what kind of music to play. Leadership may be important here so that the majority of the time was not spent figuring out the goals, expectations are set before arriving, and you don’t end up with a slow start, lots of opinions and directions. But emergent leadership provided us with a continuous improvement path with some saying “I will bring songs next time,” or “I just want to jam instead of learn songs.” Everyone can get what they want but at a sacrifice of figuring it out for the first time.

Job Titles

Creative/learning worker is the only title

In software teams we may have a Scrum Master, Product Owner, Agile Coach, Team Leader, Project Manager, CTO, Architect, Business Analyst, Software Engineer, and the list goes on. Some of these roles may even demonstrate leadership. But what if we all just had “Creative Worker” titles? In a musical band we may have Lead Guitarist, Producer, First Chair, Band Manager, Composer, Tour Manager, and the list goes on. However, both teams whether it be a band or software delivery team are creative workers. The outcome of the product is directly related to experimentation, rehearsal, and continuous improvement of the skills at hand.

When a band member is the “lead guitarist” he or she often focuses on melodic single notes that get featured within a song. Designating that role means every song needs that lead guitar, and the songs will eventually all sound similar as you must make use of the lead guitar player’s skills. This greatly identifies with Conway’s Law and specializations we find in software teams. Front-end developer, back-end developer, or database administrator specializations come to mind. With this mindset in producing software team members may stay comfortable in their functional silo and grow inward instead of outward.

I have seen skills defined as branching within letters; I-shaped (very narrow/linear skill set), T-shaped (specialist who can generalize in other skills), and E-shaped (experienced in many skills). In bands we may have the guitarist who plays drums for a song or sings back-up vocals. It is quite common to see E-shaped and T-shaped individuals in bands and I think this is because of the collaborative and high trust environment involved in creating music. It breaks down barriers to learning new skills. Similarly, full-stack developers, DevOps, SecDevOps, and I will coin the term BADevs (Business Analyst Developer) exist to break down the functional silo and merge roles.

Organization of work

There is an inverse relationship between organizing work and creativity

I love the Kanban method and practice Personal Kanban at home using boards I bought from Kanbanfor1 by Nomad8. In the office we use JIRA Kanban boards. My software delivery team manages the flow of work by visualizing the items on the board, limiting the work in progress (WIP), and self-managing using policies we’ve defined around pulling work into our value stream. Measuring cycle times of each step within the process mapped on a Kanban board can provide the visibility needed to discover bottlenecks and improve the flow. Can this work with a band’s set of tasks?

My ambitious band, Palm Tree Lumberjacks, wanted to gig, record a demo, develop marketing materials and logos, and promote our events. I thought Kanban would be the best approach for limiting the WIP to focus on one or two things. After all, how can we be recording, rehearsing for an upcoming gig, and do marketing when we are still trying to build up a repertoire. Introducing Kanban would for sure help us organize the work but it did the opposite. It turned fun, creativity, and openness in to mundane tasks needing to be accomplished. If one night the band wanted to just relax and improvise there was the sticky note for “recording” staring us down and me reminding everyone we need to stay on track.

With SOC-1 and other regulatory compliance work is typically audited so we know exactly who is doing what through a change management process. The overhead of creating tickets, ensuring the right documentation exists in the work item, and introducing more segregation of duties slows down the creative process. Like a free-flowing thought easily written down with pen and paper, it is morphed in to unlocking your phone or turning on your computer, opening the notes app, and typing incorrectly in to your crappy mobile phone keyboard. Following rigid process and policies is boring.

So even with an easy way to organize work such as Personal Kanban for a band it became about managing the work instead of expression through music. This experience made me realize how important the Agile Manifesto is and that collaboration is not about what we all agree is on the board to do next, but that which we feel we should be doing next.

Conclusion

From this experience gathering my co-workers together I’ve determined that bands are strangely similar to software delivery teams in that they both require specialized skills to form a cohesive unit and output. They both deal with highly emotional and erratic behavior. Practice and repetition eventually improve the quality and outcome. When joining a band for the first time, like a software team, you must adjust to those you work with, and learn what is already in place before offering change.

Bands differ from software teams in that with a band the platform for creativity is there from the start. Exploration and experimentation is a foundation. With software teams you may find a dependency on upper management, a visionary, or a change management process to begin work. When one band member is not fulfilling their role, it becomes immediately apparent in the music being heard by all. Within software teams it’s possible to hide your productivity since measuring the impact of your product is extremely hard.

It’s the intention and skills that make up the team that may draw out the unique qualities. The main differences are whether your band is together to write or play the same songs until they are mastered and ready for live performances, or to simply innovate and express emotion through improvisation. Whether your software team is a backlog burning machine, service and cost center to the business, or a partner in producing revenue. Rigid process slants innovation, and leadership can create bias. There’s creative freedom until you trade it with following rules.