Not only does it do that, but the actual gist that you create is a full fledged Git repository, which means you have the ability to clone it , pull and push from it.

I also use a plug in for my blog that let’s me show individual files on any of my gists.

Not to worry. In the Self-Organizing stage your role turns to more of a Coach. You need to grow your team into learning new things, technologies or tools to help them in what they do. Inspire them to be passionate about their job. This is also the perfect stage to take those team members that you identified earlier as your potential leaders and really coach them into becoming leaders. If you do your job well enough, then they can do your job for you. This is not a bad thing. If they can do your job for you, that frees you up to help with other projects, or start new ones.

In reality, a team will never be able to sustain being in the Self-Organizing stage, though. Teams will cycle through stages. Usually it’s a circular pattern. It almost always happens because the scope of the project changes in some way. Maybe they need to learn a whole new technology stack. Maybe the project has taken a whole new direction and you need to develop completely new projects. If this happens don’t think it’s a sign that you or your team has done something wrong. It’s just a natural part of the team cycle. It should be easier for subsequent cycles. The more your team has experience going through the cycles, and gain experience with how they work inside each cycle, the easier it will be to ramp back up to Self-Organizing.

The problem with teams that are not self-organizing is that they don’t have the skills to be self-organizing. Your job is to identify what skills are lacking, and give them the opportunities to grow those skills.

This usually involves a couple of different areas. Your team won’t need help in technical areas, mostly, because they focus on that themselves. There are exceptions, but to get them to self-organizing, you want them to focus on other areas too.

When a team member comes to you with a problem, don’t solve it for them. Give them the tools they need to solve it for themselves. Let them grow. They may hate you for it at first, but in the end it will be very rewarding for them, and the good ones will recognize and appreciate what you’ve done for them.

Find your leaders. They will be the ones who will lead when you get to self-organizing. Give them the tools they need to learn how to do your job. No, they’re not going to replace you, and you won’t lose your job. If you can grow one leader to do your job so well that they can replace you, and a team to be self-organizing, then you’ve just shown that you have the ability to grow teams. Any company will see that and capitalize on your abilities to produce good teams.

When your in the chaos stage, you spend a lot of time putting up barriers between your team and the outside world. This is to protect them so you can give them room to learn and grow. You’re not in chaos anymore, though, and it’s time to start taking down some of those barriers. Your team needs to grow in the areas that are outside of the barriers you put up. Lower your barriers, and let your team learn to handle what’s in the outside world. Clients, business analysts, project managers, etc. They need to learn how to deal with different actors, people besides QA and their team lead.

Eventually they’ll grow to the final stage, Self-Organizing.

Ask yourself a simple question.

Does my team have enough time to learn new things?

If the answer is no, then you’re in chaos. I’ll go one step further. If the answer was “no, why does my team need to learn anything?”, then you’re in chaos, and if you want to fix it you need to look at yourself.

All teams need time to learn. This is important so that they can become more productive, and to move towards being self-organizing. If they can’t learn then they’ll never get the self-organizing stage.

If you’re with me so far, then you’re probably asking

How do I make time for my team to learn?

It starts by identifying why you’re team doesn’t have time. Sometimes it can be as simple as giving them some extra time in the week to learn something new. Tell your team they can have 4 hours on Friday to learn whatever they want. This will let you see which people on your team are self-motivated. This is vitally important. It identifies your leaders. For those who choose not to learn anything, make it a requirement. The best way to go about doing this is to just ask people how they’re learning is going. Maybe every Monday you ask each team member individually what thing they learned on Friday. This is great because it sets up an expectation for them that they not only have the opportunity to learn, but that you’re expecting them to learn.

Not all teams will have time for this. Your release cycle swamps you with work, for various reasons, and prevents you from being able to give this critical time to your team. So what then? That’s when you’re role become a fire fighter of sorts. You have to put out the fires. The point here, though, is to extinguish the fire, permanently. If you’re putting out one fire, and two fires pop up in it’s place, then you have another issue which needs to be addressed. You’re the team leader, and it’s your job to control the fire. You have to shield your team, that’s your job during this stage. That means putting out fires, but it also means not allowing other fires to start in the first place.

This is usually a good indication that you’re lacking tools that help your team be more productive. For example, maybe your “fire” is releases. They take too long to do, because they’re manual. You release often, so it’s something you spend a lot of time on. Why isn’t your release process automated? Take a step back, is your build process automated? No? That’s the beginning of your problem. You can’t have an automated release process if you don’t have an automated build process. Another example, is it hard for your team to share projects? Do you find yourself in situations where two people are working on the same thing and stepping on each other’s toes a lot? Does this require you to put people on separate projects so you don’t get into a tangled web of conflicts? Yes?

Are you using source control?

No? Get it.

Yes? Are you using a good source control system? Your team needs to be able to work together, and if your source control doesn’t accommodate that it’s probably because it’s not so great. Try a new one. Maybe Git, or Mercurial, or if you’re not into DVCS, try SVN.

There are a lot of things that can hinder your team’s productivity. Most of them have been solved by other teams already using automation. You’re team probably isn’t special, and their problems have probably been solved by other (bigger and more productive) teams. See what they’ve done. Copy them, mimic them, learn from them.

Get your team out of chaos, so they can learn, and make your job easier.

So I decided it was time about time to do this. Notice to recruiters, if you are soliciting information from potential candidates in the hope that you’ll grab a bite, you’re fighting an uphill battle. The reality is, you’ve already lost, and you need to go back to the drawing board.

I know you’re job is to find candidates, and I’m not saying you should stop doing that. What I’m saying is, you should be doing a better job. Let’s assume for a second that your opportunity is legitimate, and let’s take it a step further and say it’s a good opp. You should be doing your due diligence to find the right candidate, not just spamming a bunch of people’s emails that happen to fit the search criteria you used.

All those fields you want people to fill in for you? You should have figured them out already. At the very least, the ones that actually matter. For example, if you’re looking for “local only” candidates, then guess what, you should only be soliciting local people. Another example, and this one is really ridiculous, if you’re looking for a job with certain technology requirements (i.e. “X years experience with Technology ABC”), and then you proceed to ask what technologies the person you’re soliciting knows and how much experience they have in each. I don’t think there are words to describe how much of an oxymoron that is.

You should know what skills your candidate has before you contact them. That’s the whole reason why sites like monster, dice, careerbuilder, and careers @ stackoverflow really exist in the first place. Use them.

Also, this one goes out to recruitment firms: stop making people fill in another application form just because your recruitment firm is somehow special. Guess what, it’s not special at all. In fact, that pretty much means your firm is on my list, the list of firms not to get involved with.

I guess that’s about all I have to say. If this post only changes one person’s mind about recruiting, then I think it’s time well spent.

If my previous post about how to do interviews correctly, I talked about 2 questions I ask my interviewees. The second question is about letting the interviewee show me if they can explain basic development principles, in layman’s terms. There’s not a lot of streamlining that can be done there, to be honest. Ask the question, let them talk. However, the first question is a programming question, and getting the user set up to handle the question can be tricky depending on how they want to answer it.

How do I know that the interviewee answered the question correctly? Usually, I can just eye ball it, and I’m right about 95% of the time, but I wanted something better. I wanted to present the interviewee with something that removed the possibility of me screwing up, but also of them misunderstanding the problem.

So what I did was create a project on github that has different versions of the question. So far I have one in javascript, and one in C#.

The javascript version runs using jQuery and uses QUnit to verify the user has coded the problem successfully. I have a runner html file that the interviewee can fire up in their browser of choice and it will automatically validate if what they did is correct. The great thing is, if it works, everything “green lights”, whereas if they’re wrong, it “red lights”. I mean that literally, so I can visually see within a split second if the code is good or not.

The C# version is similar, but it presented itself with some different dilemmas. For example, with C# usually people are going to want to showcase their talents using Visual Studio. The problem is, how do I get my test framework to the interviewee? The traditional approach would be to send it to them in an email or something, but I want to rule out the possibility of the interviewee trying to pull one over on me, or coming up with excuses like “I couldn’t load what you sent me”, or something to that extend. Instead, I built a nuget package, and I’ve pushed it up to the nuget gallery.

This has a few benefits. The first being that anyone running VS 2010 with the nuget extension installed can find and install my interview questions. Below I’m going to include a video of myself doing it just to show how simple it actually is. The second benefit is that there’s no guess work involved, so the interviewee can’t give excuses. All they need is VS 2010 and internet, which if they’re being interviewed by me, they already have internet. If the interviewee doesn’t have VS, they can just use notepad and I can copy paste what they’ve done on my side and run it.

Either way, there’s no excuse, and it’s fast.

How fast is it? Check out this video of me setting it up on a new project:

I give the same problem to all the people I interview. It helps me form a baseline and I can easily compare how one person did to another. After all, they solved the same problem. The problem I give has nothing to do with technology stacks. In fact, I usually let the user choose what language they want to do it in, and also how they want to deploy it. My preference is to watch them use some kind of testing framework, but I don’t expect it, nor require it.

I also record the interview. I record it so I can refer to it later when anyone has any questions about the interview. The recordings are also a really great way to coach other people how to do the interview.

The algorithm/problem I give my interviewees is really simple. I mean, it’s drop dead simple. Why make it so simple? For a couple reasons, actually.

• I don’t want to be there forever.

Totally selfish reason, I know, but if I hated long interviews when I was taking them, you bet I’m going to hate them when I’m giving them. I want it to be short. I shoot for 30 minutes, but if I’m going over an hour there’s a problem. This portion of the interview should only take 15 minutes. Any more than that and a flag goes off in my head.

• Simple problems can show you a lot about a person.

Does the person take time to do it right, even if the problem is simple? Do they use TDD when they say they’re an avid TDDer? Do they stick to principles like SRP and DIP when they say they know and use all of the SOLID principles? These things come through on simple problems, and are a lot easier to spot.

• Benchmarking

Simple means there’s no excuse. If I give a simple problem, no one can come back to me and say, “how can you expect me to answer this kind of thing on the fly?” It also lets me take how one person did and compare them to another person. Here I’m not so much concerned about time as I am about technique.

When they finish with the problem I gave them they move onto the second item for the interview, which is a question or set of questions about Object Oriented Principles. I’m not looking for the dictionary definition, either. I want a real life, come up with an example for me on the fly, kind of answer. It let’s me watch the interviewee think. They have a chance to show me that not only can they tell me what the principles are, but do they understand them and can they explain them to me.

Again, the questions are simple for the same reasons that the problem was simple. It should be easy in concept, and thoughtful in reply. I’ve already seen them code, so I should have seen some of these concepts in action, but I need to make sure they know what they’re typing. If you can’t tell someone else what you’re doing, then when you work on a team you won’t be able to explain to your team mates what you’ve implemented, even if it’s good code. Contrary to what most people might think, communication is more important than your coding skills.

However, doing an interview right only get’s us part of the way there. We also need to know how to do is easy.

Let’s start of with the title of this post. I work in a technical field. All of the “first time” interviews I’ve had almost always end up the same way. I spend about 30 minutes (probably more) talking with some person about my skill set and whether or not I’d be a good fit for the job they’re asking me about. I’ll put these people into two buckets, the good ones and the bad ones.

The good people that I talk to always do it the same way. They don’t really ask me any questions at all. They tell me exactly what the position is, where it’s located, any skills that are absolutely required, the salary range (usually), etc. The key here is that they’re the ones talking. They aren’t asking me any technical questions. This is vitally important. The “first time” call should only be about 2 things: do I exist? and how interested am I in this position? A really good recruiter, or whatever you want to call them, will keep this call very short. Some times I’ve had them be only 10 minutes. I would love for them to be only 5, but that’s not usually feasible because recruiters really like to go into details about the positions they’re filling.

The bad people grill you. And a lot of times they grill you for a really really long time. I think I’ve had first time calls last me over an hour with someone asking me all sorts of questions about “do I know this” and “do I know that”. The problem with first time calls asking you a lot of questions is really quite simple. How would they know if I’m lying? They wouldn’t. They wouldn’t know because they’re not technical people. The problem is usually with these bad first time calls is that they don’t have a second call. Once they talk to you and get the obligatory “this guy said yes to all my questions, he must be totally awesome!” run through, for all intensive purposes they’re done.

This can really be a nightmare from a positioning standpoint. Companies get ridiculous turn over on resources because they don’t take the time to find the right person for the right job. It seems like common sense that you would want to evaluate someone on what they do before they are hired. The stance on this this in the tech industry has been varied, though. A lot of people think that asking questions is sufficient. That someone being asked complicated enough questions who doesn’t know what’s being asked will just buckle under the pressure. Unfortunately that has caused our industry to become full of professional BSers. Other people think that you’ll never really know if someone is worth their grain of salt until you try them out. This is somewhat true, but doing nothing about it will only land you with the same group, the BSers.

I’m joining the side that will be responsible for ridding our industry of these people. My position on this is simple. If you want a job as a professional developer, show me teh codez. Talk is cheap, I want to see you code.

And that’s how I interview. Get ready to see some code.

Now that we know how to measure out velocity, we can use that metric to figure out one of two fundamental things:

1. How long will it take us to get there?
2. How far will we get?

Velocity can’t answer both questions for us, but if we’re willing to concede and control one of the two variables, either the distance or the time, then we can project what the other thing will be.

For example, if the team is getting pressure to release by a certain date (sound familiar?), then with your velocity you can project how many features you’ll actually have done by that time frame. If, however, the team is under pressure to get Awesome Feature X done and released, then you can use the same formula to project when that feature will be done.

With road trips my family almost always chooses to control the distance and project the time. My wife wants to go to Disney World, for example. That’s choosing the distance factor. Now if I know my velocity I can project how long it will take us to get there. On the other hand, some times we want to do a quick weekend trip to somewhere just to get out for a few days. In those cases, we’re bound more by time, because we don’t want to be on the road the whole weekend. In that case, we constrain our time window, and see how far that will take us.

This is where the real power of knowing velocity comes from. Your implementation team is the engine of you car. Understanding velocity and how it works and what it means to your team is like having a speedometer. Until you know about velocity, you’re like driving a car with a broken speedometer.

A lot of common questions of project management start being fundamentally changed when you introduce velocity. For example, a question like, “How do I make my team work faster?” changes to something like “How do I increase my team’s velocity?” I’ve seen this happen almost any time that a team embraces these concepts, and it’s not only a change in the wording of the question that is profound, but in the meaning of what is behind it. Velocity is a historical metric for your team’s progress, so asking a question like how to make that number go higher because a much more scientific question completely. The answer is can be varied, but it all comes back to where it started, with the velocity. Try something out on your team, then wait and see how your velocity changes. You’re doing an experiment now. Not only that, but you know how to measure the results.

Enjoy your new found technique. If you have any questions or comments feel free to contact me.

Measuring your team’s velocity is actually an easy thing to do. Your team will start working in release cycles that are broken down into parts. The lead or the project manager is usually a good role for determining how long these cycles should be. Some teams will have a release cycle of 3 weeks. Others will have longer cycles, it’s completely flexible. The key is to stay consistent. Once you make a choice on your cycle, you need to stick to it. The reason will become clear later.

The other thing to note here is that you can break down your release cycles into parts. My team calls them Iterations. I have some teams that work on 1 week iterations. I have other teams that work 3 week iterations. One team I lead has a 2 week iteration. The release cycles for all these teams are different, too. Some teams release at the end of every iteration. Other teams release every 2 iterations. I’ve worked on teams where the planning of the release was done more rigidly because of customers, and we would release every quarter or maybe 6 months. The point with those teams was not so much about the release cycle, but that the iteration cycle was still small. The largest iteration cycle I’ve worked on was 4 weeks long I think.

The point of the cycle here is to do one thing: allow your team a consistent amount of time to work on an attainable goal. That attainable goal is a certain number of features. How many features you ask? It completely depends on your team’s velocity! But when you first start, you don’t have a velocity, so you have to do a couple cycles just to figure out what the team can do.

So say you have 30 features to work on. You decide to have your team work in 3 week cycles. At the end of their first cycle, they complete 3 features. One of the features was valued at 5 points (from the estimation sessions, remember), and the other 2 were valued at 3 points. That means the first cycle your team finished with a velocity of 11. That’s all there is to it! Now you repeat the same process over again. Do another cycle. Maybe the team got 15 points completed. Now average the two cycles together. The team’s velocity becomes 13. Rinse. Repeat. That’s how velocity is measured.

This is why your cycles have to be consistent, because you’re taking an average of the points your team completes. If you change the cycle length, then it messes up your velocity values. Now, having said that, there are points where it’s appropriate to change the cycle. I’ve done it many times before, but you have to account the change in your velocity calculations when you do it.

Now that we know how to measure velocity, we can use it to figure out things, which is our next topic:

Projections