« Technology Companies. We Hate You.| Main | What am I? A Salad? »
The Agile Jazz Band
Agile is like a jazz band. And that's a critical thing to know if you're moving from a specialized waterfall-type environment to an agile one.
In those older environments, everybody did their job sequentially in small meetings. This would be like having a musical instrument and playing it for a small group of people. After you were done, another person would come in with their instrument. You might go or you might stay. If you stayed, you certainly didn't play your instrument! You simply watched as the other person played theirs. It might take a year or two for everybody to take their turn at playing their instrument (doing their discipline) before the performance was over.
Waterfall is like that. Everybody has a role, and we work on them one at a time. It is sequential and it's gated. Each meeting is for doing one thing and one thing only.
When you move to agile, its a whole new world, and quite frankly, most places aren't so good at helping you switch. I think it's because we don't understand the change. In fact, I'll go so far as to say that many times coaches don't help teams adapt much at all.
In the Agile Jazz Band, instead of each person playing their instrument (doing their discipline) separately, we all perform at once. The listener (product owner) can then hear a lot more music more quickly than the old way. In fact, we put our work into small groups.
This time-boxing of our work, called sprints, is like a song in music terms. We all play together for fixed period of time playing what the product owner (listener) wants. The way we play, however -- the style and way the notes come together -- is up to us.
When introducing agile to new teams, we usually see these old behaviors return. We'll plan out what the sprint is going to accomplish and then start. Then wham! Everybody goes to a separate room and starts scheduling meetings to do their thing. They're used to the old way. It's back to muscle-memory.
This would be like our musicians going to their separate rooms and playing each instrument separately. Its no wonder that the first thing many teams ask when we tell them about agile is "how can we do so much work in such a short time?" They're thinking of the old way of working. And they're right -- if you worked the old way it would take you a week to play one song.
As coaches most of us are not so good at helping to fix this. We'll wave our hands around and say something like "you guys just all need to be together in the same room. It's called collaboration. You're supposed to work together. Stay in the same room!"
So folks work in the same room, setting up different meetings and all working in small groups by themselves. Many times you walk into a collaborative room with a team new to agile and see Business Analysts on one side, Developers on another, the PM and Product Owner in another group, etc. We're so used to formal roles and performing in a certain sequence and to a certain audience that, even in the same room, we self-segment and do it the old way.
Which brings me to the concept of Jazz.
The concept of Jazz is awesome. Each person plays in a freestyle, flowing fashion. The music self-organizes around a theme or concept. Listening to Miles Davis, I can't help but be astounded at what Jazz can do. Everybody is an equal. One musician will solo while others support, then others will solo, then the entire band is playing seemingly without a soloist. But everybody is still constantly performing. Each piece is completely different. You can hear the same song seven times and it is never exactly the same.
So we're teaching folks from moving from sequentially doing their thing in a highly structured format to doing it with everybody else. At the same time. And making parts of it up as you go along. Without a firm plan for how it all works. And in short timeboxes.
Is it any wonder that people are confused? We sound like aliens. The concepts we are using just do not fit into the way things have been done.
Even if we could show them another team and how they worked, it would still be completely foreign. How does anybody manage to get anything accomplished?
Our response as coaches, most of the time, doesn't help at all. We wax eloquently on and on about how teams "self-motivate" and about "Self-Directed Work Teams" and about "emergent behavior".
It's like somebody comes to us to understand how to play the tuba. Instead of teaching them, we give them an hour long speech (Or worse! A Book!) on how playing the tuba is such a great thing. Tuba playing, when done well, is the best thing in the world. I played the Tuba once and had a blast. We finish, and then slap them on the back and say something like "go get them, tiger!"
Geesh.
And it gets worse. For those of us who never understood (or liked) that there are real software engineering disciplines, we get hung up on the idea that agile teams don't have roles. "We only have one role, that's developer" we'll say. Or "Everybody is a generalist on an agile team"
This is a great ideal. Ideally, everybody on a Jazz band can play all of the instruments. Musicians are musicians, after all. There are similar concepts that one must learn and do to be a musician.
But still, playing the jazz piano is a different thing than playing the jazz trumpet. Even if you know how to do both. Both of those are acquired, learned skills. It might take years of work to make it look effortless. There are schools you can go to in order to become a good piano player, or trumpet player. People naturally excel at doing different things, and even though there is no set structure, there are still rules and craftsmanship that each band member brings to the table.
Just because you're in an agile team doesn't mean that the world of engineering goes away. There are sill specialties, disciplines, and bodies of knowledge which have to be learned and applied skillfully in order for the team to succeed. When we gloss over this fact by calling everybody a 'generalist', we confuse people and don't help them make the switch to working in an agile fashion.
What we're saying is correct -- it's just not useful.
The Agile Jazz Band requires that you know how to play an instrument. That you be able to keep time. That you can play your instrument at the same time as everybody else to make beautiful music. In addition, that you can adapt your talent for whatever type of band you're in and music you are playing. This is a long, long way from playing that instrument by yourself in a room with a few watchers.
Agile teams don't need specialists, but they need people with skills in special areas. Database design and optimization doesn't go away because you are on an agile team. User Interface Design is something that some people are good at and others are not. Talking to the Product Owner about what's in the backlog -- eliciting requirements as we used to call it -- is still a skill. Even though it happens all at once, we still can't talk at the same time. People have different agile musical instruments they play. In the real world, even though we're all in the same room, Joe is going to lead the conversation with Sue today. The rest of us will play support, getting in our critical conversation pieces in harmonious way with Joe. That's because Joe is really good at chatting people up and he's a great conversationalist. Joe takes a solo. We can still all join in any time we want. It's free form. But let's start with Joe and see how it goes, okay?
To a listener, a Jazz Band sounds and looks like everybody is playing at the same volume. But to the band, there's always an instrument leading, even if that instrument changes hands many times in a song.
The agile industry is awful about accepting this reality. Instead of helping existing skills and disciplines integrate into a working team (that's too tough to do in a book or presentation, so we can cut them some slack) instead we latch on to new shiny toys. TDD, Continuous Integration, and Pair-Programming are awesome new tools to do development with. But they don't replace everything that is already there. TDD is just another way of doing design and coding. Continuous Integration is another way of doing deployment. Pair Programming is another tool in the coding toolkit. But they are only tools in much larger disciplines. These disciplines are still there. And you always must understand these disciplines and strive to master them if you want to be a better team member.
It's like people complaining that our Agile Jazz Band sounds wacky -- the instruments all play at different times out of sync and while there is a song that is delivered, it's nothing near what we read about in books. So we, as coaches, try to sell them a newfangled Electric Trombone. Look at this Electric Trombone! we say. "People who play this say that the music is ten times better than it was before!"
While its true that the Electric Trombone will help a certain part of the band sound a lot better, it still does nothing towards teaching and training how all of the parts fit together as a whole. Instead, it gives us something new to focus on -- a new cool way of working, admittedly -- but keeps us from focusing on the real issues. It's the "tool magic" thinking applied to processes.
The coaches from a PM background are just as bad. Sometimes it seems that they don't care about how people actually do their work -- their discipline -- as much as they care about the trappings of agile. The stand-up. The showcase. The retrospective. "Get the retrospective right and the rest of it will just emerge" they seem to be saying.
Malarky. Jazz music emerged, sure, but it took a thousand years of music for it to do so. Most teams don't have that kind of time.
The answer? Just like in any band, everybody has to re-learn what it means to play their instrument. Everybody has to re-learn how to apply their skillset and area of expertise. That skill and training doesn't go anywhere. In fact, we need you to raise that to an entirely new level. We all need to not just hear about playing -- you don't learn how to play an instrument by reading a book or watching a video. We actually need to play the instrument -- at the same time everybody else is playing theirs. At first, we may need to structure up the songs a bit: it's really tough to ad lib it if you've never done it before.
We need to concentrate slowly and methodically on how each discipline can work with each person's skills in the particular team they are in. Then we need to do that again and again.
We'll hit rough spots. So we stop and talk about what went wrong and how to make it smoother for the next song. For pieces that are hard, we might "script it out a bit" -- list certain steps and how they'll come together. We might practice offline to see how it goes. Like any other musical endeavor, it's practice, practice, practice. We're not going to get to be an agile team by reading a book, going to seminar, or watching a video. This is not something you can train your way out of. Instead, it takes a people who are already experts in software development, an open mind, practice, feedback, and gentle coaching. It's not easy.
Being an agile person who knows database design, or web configuration, or any one of a hundred other technical specialties is like playing a musical instrument. Agile teams are like a bunch of musicians all playing a song together. It's tough enough mastering the instrument without everybody else being there, but the really beautiful music comes when you are able to meld it seamlessly in to other people doing their work all at the same time.
I had a Project Manager ask me yesterday how long it took to really learn agile skills.
Coming from a non-waterfall environment, where you "grew up" agile, they've already got them. They just need to keep improving, I said. But for people who are used to the old way of doing things?
Seven or eight projects. At least. Probably more. After all, even if you were an expert piano player, could you learn playing in a jazz band just after three or four sessions?
I don't think that was the answer he was looking for. I think he wanted the "Master the Piano in 21 Days" book.
Better hone up on my electric trombone skills.
Leave a comment