In a world of deadlines, tight budgets, and high expectations, sometimes we need that superstar on the team that can “get it done” so we don’t make our clients look bad.  On the many teams I have led, this superstar has shown up in a few different incarnations:

1. The Hare
   You want it done by 2pm? No problem. The Hare has no issue with short deadlines because the Hare can get it done in 15 minutes. What’s that you say? The senior team that estimated the work thought it would take at least 2 days? No problem, the Hare still thinks it can get done in 15 minutes. Lo’ and behold, 15 minutes later everything has been coded up, checked in, and the Hare is off to save another project from certain doom. The fact is that it hasn’t been tested, and maybe not 100% of the requirements are in there, and perhaps it has a few paths where a nice 500 error gets served…but that’s not a problem, because that’s what the rest of the team is for, right?
   
2. The Tortoise
   You want it done by 2pm? No way.  It’ll take at least twice that amount of time.  What’s that you say? The senior team that estimated the work thought it would take less than a few hours?  Uh uh.  The Tortoise isn’t going to let you slide by with a hacked together solution.  It’s time to buckle down, test the heck out of those three lines of code, and make sure we have 100% code coverage with unit tests.  Don’t forget the code analysis, and we better not forget to automate a load test of the display of the user’s first name in the header.   Sure, we’ve just blown a full day of budget on a simple feature, but this is the right thing, so the sales team should have secured a budget to deliver high quality, right?
3. The Mythical Unicorn
   You’ve never met this developer, but somebody you work with has either worked with them in the past, or worked with somebody who worked with them in the past.  The Unicorn was always on time with delivery, always within budget, and never had bugs.  Nobody can ever fully remember what their name was, or where they’ve gone now, but the legend remains.  You wish you could be this person.   Most of all, you wish this person was on your team right now. By the way, if you happen to KNOW this person, please send me their contact details as I’m sure I could use them on my team. 

In my own usage, I’ve been referring to the comparison of delivery speed versus quality as the ‘delivery quadrants’.  The discussion of balancing speed and quality is nothing new, but I think we need to recognize on our agile teams that we need a balance.

The Not-So-Superstars

We also need to recognize that sometimes we have team members that aren’t superstars.  They tend to operate in the middle-to-lower quadrant:

1. The Rock
   No, this is not the person you can depend on in any situation. There is no Chevy commercial playing in the background as this coder goes about their business. The Rock is there to help you drown. They drag the team velocity down, delivering low quality work while still managing to take a ridiculous amount of time to get there. Worse yet, there seems to be no reason for it. This individual should have all the skills, experience, and time to get it done, but they just don’t.
2. The Workhorse
   While some coders are racing to the end, and others are twirling around getting high quality, and others are stressed out just trying to get work done, the Workhorse keeps pushing forward.  The Workhorse isn’t going to win the Kentucky Derby, but you can put almost anything on this person and it will get done. There will be a few bugs, and delivery speed might be average, but the dependable Workhorse gets it done eventually.
3. The Pupil
   If you were just to look at the numbers after an early project iteration, you might confuse the Pupil with the Rock, but this would be a mistake. The Pupil is a temporary drag, somebody who is learning and whose quality and delivery speed is ramping up as their experience grows. If you stick it out with the Pupil you might even get yourself a superstar!

This is hardly a full list, but I find these archetypes helpful when I examine the team’s composition to look for potential issues with velocity, or where I might need to balance out the team. In one of my upcoming posts, I’ll address how to plan out a balanced agile team.