How to Show Agile Behaviors on a Resume, Starting with Collaboration

Back at OOP 2012, I gave a talk called “Six Behaviors to Consider When Hiring for an Agile Team.” These are all team-based, interpersonal skills that any team needs, but are critical on an agile team: collaboration; how to stop when something is good enough–especially when the customer says so; how to ask for help, those kinds of behaviors. My good friend and colleague, Udo Pracht, asked the million dollar question, “How do we show these behaviors on a resume?”

Good question, Udo. And, too often, these behaviors can appear weak to people who don't understand about agile teams. “Collaborated on a team” does not appear like a strength on a resume, does it? It flunks Rich’s Resume and Interview Preparation Tips.

If you transform it so it shows value to the team and the organization, now maybe you can use it. Let's start with collaboration. Did you help the team increase it's throughput? Can you say this? Only if you measured before and after.

Led our team to 20% increase in throughput through use of swarming around features and other high-collaboration approaches in our agile approaches.

Ok, so maybe you didn't lead the team. I hate the word “enable” on a resume, but that's me. Maybe you can think of a better word.

Enabled our team to increase its throughput by 20% through use of swarming around features and other high-collaboration approaches, such as pairing in our agile approaches to our projects.

This is a sentence that should leap out at anyone who reads the resume. 20% is a huge, gigantic number. You'd better be ready to defend that number. Even if it was 10%, that's a big number.

If you have worked on an agile team, you have burnup charts or cumulative flow diagrams, or cycle time numbers, so you have the data. No problem. (See, this is why I don't use burndown charts; burndown doesn't provide you this kind of data.) If you kept the data on paper, you might have to go digging for it. That's ok. If you kept the data electronically, it should be easy to find. (Those famous last words, should be.) If you have not kept the data up until now, start keeping the data. It will be interesting to see if your collaboration is working.

And, if the collaboration is not working, you can address that in a retrospective, so you can attempt to improve this job while you look for another one, right? In either case, you win.