Scrum + Hip Hop: Vol. 3
Who’s Down With Your Crew?
When it comes to forming your hip hop crew, you’ve gotta have the right people. If it’s is made up of nothing but emcees, don’t be surprised when artistic differences stall the release of your album. Yet commonly, newly-formed scrum teams have a tendency to heavily lean with developers. Like hip hop crews, scrum teams need the right people too.
“Without my people I got nothing to gain. That’s why worst come to worst, my people come first.” — Dilated Peoples
Take Public Enemy. Each member plays a different role. Most notably, Chuck D is the front man, Flavor Flav is the hype man, and Terminator X is the DJ on the 1s and 2s. Though each has a different role, they still come together to produce albums packed with hip hop songs. On a Scrum team, everyone plays a different role too: product owner, scrum master, and the development team. In this context, the development team isn’t purely made up of software engineers, but also includes testers, designers, and ops engineers.
A common misunderstanding with new Scrum teams is that everyone continues to work as they did before. Worked is doled out based on skill set. Software engineers get assigned an issue, they write code, throw it over the wall to testers, and move on to write the next bit of code. At some point, the code gets pushed to a test environment, and barring any defects, it’ll go live on a predetermined release date.
In Scrum, teams need to be cross-functional. It means everyone performs different roles which aren’t necessarily based on their skill sets, or titles. Flavor Flav crossed over into the role of front man when Public Enemy put out “911 is a Joke,” and again when he released his solo album in 1999. With Scrum, everyone works one story at a time from the sprint back log together, in all phases from coding, to testing, to done. Developers should also test; testers should have access to code repositories, and attend code reviews. As I said in Scrum + Hip Hop: Vol. 2, It’s about following the beat. It’s what helps maintain a consistent rhythm.
Teams that struggle with this concept have a tendency to fall back into familiar Waterfall patterns. “It always worked in the past, why mess with it? It might not be fast, but it’s what we’re used to.” It’s good to remember that Agile isn’t a synonym for fast, but rather a method to consistently deliver over short iterations. It’s also about adapting, and quickly reacting to change. Subscribing to Scrum doesn’t magically transform teams into agile ones any more than showing up at the club with two turntables, and a microphone makes you skilled at hip hop. You have to work at it. Inspect, and adapt. Be open to change.
“I know you desperate for a change. Let the pen glide, but the only real change come from inside.” — J. Cole
When people aren’t willing to change, and developers aren’t expected to test, the result is overloaded testers. Ultimately, the unwillingness to change will most likely result in unmet sprint commitments. Incomplete stories then get dumped into the next sprint, which erodes your product owner’s confidence in your team, and builds mistrust. They’ll doubt whether everything committed to during sprint planning will get completed. It’s like if your hip hop crew only finished three songs for your upcoming album, but you promised your record label that you’d have ten, and the album release is in two weeks. It’s not sustainable, and your label will probably drop you.
Back on point, cross-functional teams won’t be effective if they aren’t self-organized. If teams don’t have the authority to adapt without checkpoints, and red tape, transforming to a more agile organization will be a constant struggle. Removing impediments is the Scrum Master’s job since these are what stand in the way of teams doing what they do: producing valuable, working software. Impediments are like your record producer insisting you add more cowbell to every song on your album.
The good news is that it’s fairly simple to spot when things go off the rails. That’s the whole point of Agile, right? To quickly identify what’s going wrong, and address it. If you’re creating additional sprints to complete unfinished stories, adding QA sprints because testers are overloaded, or your burndown chart is borked, alarm bells should be blaring.
Sometimes there’s a tendency to believe that the point of development is to roll out features that “the business” requested, but at the end of the day, your crew makes hip hop for its fans. Scrum teams need to make software for its customers. Anything that gets in the way of that holds your team back.
The Next Track: It Takes a Village
