It’s a horrible, but true fact: 50 to 90 percent of software development projects fail – and the more distributed or remote your team, the higher the rate of failure. Fortunately, this fate is far from inevitable! With a bit of planning and an organized process of communication and accountability, your project can succeed.
There’s no magic formula. Rather, there’s a simple process to follow which is teachable and easily integrated into your team’s framework. There are three major phases in this process:
Hire good developers:
- Engage the right developers from the project outset
- Expand the talent pool by hiring virtual developers
Plan a framework for your project:
- Determine your vision with a requirements analysis
- Set a clear goal with wireframes and use cases
Execute the project using Spotlight or other media:
- Instill accountability and follow-through with Daily Scrums, Status Updates, and Daily Progress Report
When your project is ready for the execution phase, Spotlight is your go-to for managing the distributed team.
To stay up-to-date with Spotlight Software and Spotlight People & Project Manager, join our mailing list or visit our Facebook, Google+, LinkedIn, or Twitter profiles.
Vincent Serpico: Good morning, everybody. Welcome to this week’s webinar. We have a very special webinar, by popular demand, “How to Hire and Manage a Team of Virtual Software Developers.” We’re going to go over the process of hiring, the process of planning, and the process of executing a distributed team.
Before we get started, as usual, let’s go ahead and update our Spotlight status. I’m going to update “In a webinar. I am currently busy. I will be busy until 11:00 AM. I am currently in client relations.” I will update my status, and everybody knows that I am currently busy.
Let’s go ahead and get started with the webinar. Again, thank you for joining. This is going to be “How to Hire and Manage a Team of Distributed Software Developers.”
My name is Vincent Serpico. I am Founder and CEO of Spotlight Software. I’ve been building and developing software for over 15 years, serving a variety of roles in various capacities, from software developer to VP of Dev in several companies.
I own a software development service company, and I serve as CEO of Spotlight Software. Dan Schulz is Co‑Founder, President, and COO of Spotlight Software, and has been in technology for over 30 years. Seth Weedin is Director of Marketing for Spotlight and heads up all marketing efforts.
Horrible fact, 50 to 90 percent of software development projects fail. What’s worse is that the more your team is distributed, that is, the more your team is remote, not working in the same office, the higher the rate of failure is.
Take heed. Your project can succeed with a bit of planning and an organized process of communication and accountability.
I’ve been working with distributed teams for many, many years. My success rate is actually inverse of the failure rate. I have a success rate of way over 90 percent.
I’m not some kind of genius or anything. I don’t have some sort of magic formula. I simply follow a process, a process that is very, very teachable. By having a teachable process, anybody can learn it. Literally, anyone can learn it.
The first thing is let’s talk about hiring. “Who’s going to develop your software?” I cannot stress enough that you need to get this right.
Developers, they are not commodities. Developers are building your lifeblood, your dream. Make sure you get good developers. You want to build a team that’s going to last. It could take a developer three, four, five, six, even nine months to ramp up on an application.
Let me put it like this. Let’s say you buy one of those old muscle cars, like an old Mustang from the ’60s, and you want to restore it. You hire a mechanic. Mechanic’s been working on your car for two or three weeks.
You decide to lay off the mechanic, and hire somebody new. That new mechanic will be productive day one. A carburetor’s a carburetor. A manifold’s a manifold. They can get up and running immediately.
Not so much in software. If you lay off your developer, he quits, or whatever, it could take a new developer months, literally months, to become productive in your system.
That means months of downtime that’s wasted for you ‑‑ wasted money, wasted opportunity cost. Make sure you hire the right developers on the get‑go.
We recommend hiring virtual developers. Why do we recommend hiring virtual developers? First of all, if you limit your search for developers within your geographical location, you’re going to have a much limited talent pool than a search all over the world.
If you’re looking for a really good .NET guy who knows C# and knows the ins and outs of a mongo database really, really well, it’s going to be hard to find that guy within 20, 30 miles of your office.
However, if you expand your search to the whole United States, you have a much better chance. If you expand your search to the Western hemisphere, you have a huge chance. If you expand your search to the world, you’re going to find this guy.
The larger you expand your search, the better the odds are you’re going to find this guy at a really, really good rate. There are a lot of very good websites out there that help freelancers get together with employers, like Elance, oDesk, Freelancer.com. There are so many more.
We do definitely recommend hiring a virtual developer. When you jump on one of these sites and you go to Elance, when you go to Freelancer.com, or an oDesk, it’s really important that you find the right developer.
By finding the right developer, there is a process of describing what you want done in your project, and communicating the what, not the how.
What do I mean by that? What I mean is that when you’re looking for a developer, you’re not looking for a mechanic. Again, development is extremely difficult. It’s not like building a skyscraper or doing heart surgery. Development is a very, very difficult task, and as such, it’s not so much mechanics as it is an art.
When you are communicating with a developer, and you’re hosting your job in Elance or Freelancer.com, describe what you want, not how you want it implemented.
For instance, don’t say, “I’m looking for a iOS/Android developer who can create a geo‑fence application that will send an alert back to a MySQL database, do some processing of other devices within a 10 mile radius, and then send that out over a REST web service.”
Instead, you might want to say, “I want to develop an application that taxi drivers can find fares within 5 to 10 miles of where they’re located.” By doing that, a developer will come back to you with an architecture, with a design, with a plan, that you might have never thought of, and lend huge, huge value to your development process and to your business and theirs.
Developers are going to be your lifeblood. Describe what you want. Describe the goals of the project, the goals of the business, not how it should be done.
When you do find somebody to create a good rapport with, give them a programming test. This is really, really important. When I say a programming test, I am not talking about one of those multiple choice or fill in the blank tests. Anybody can do those. What I’m talking about is a real programming test.
If you need a mobile developer, go ahead and give him a test to create an application on a mobile device. Design it so the test will take him two or three hours. You don’t want to give him a huge test, but give him a test that would take two or three hours.
I also put a couple of guidelines in the test to really ascertain the developer. I will go ahead and leave the requirements a little open‑ended so that the test can be completed in two or three hours, but he could work on it for a lot longer if he wants.
I also make the requirements a little bit ambiguous. Why? Because I want to see what a developer does when he’s not completely clear on requirements. Does he ask me questions? Does he make assumptions on his own? There are pros and cons to both, right?
By actually creating a test, what you’re doing is you’re seeing how much this developer really wants to work for you, how ambitious he is. Does he do the minimum on the test or does he deliver a really robust test?
I’ve had developers tell me, “Nope, not taking a test until you hire me.” Well, then I’m not hiring you. I’ve had developers return the bare requirements and I’ve had developers spend days on a test, turning in masterpieces, who wound up being senior level architects for me for a long, long time.
Just to wrap up the development, communicate your goals, what you’re doing not how, and require a real world programming test. If you’ve done this before, great. If you haven’t, I highly, highly recommend you get a consultant to help you out the first or second time around to provide a gut check for you.
Let’s talk about planning. This is the second phase of hiring and managing a distributed team.
Would you build a house without a blueprint? I would hope not. Would you drive in a new city without a GPS? Again, I would hope not, unless you want to get lost. Why in the world would you build software without a clear plan? I see this all the time. I see folks just jump in there writing code saying, “We don’t have time for requirements analysis. We’re on a tight deadline.” Or, “We’ll wing it because we’re agile.”
They give you a whole bunch of excuses why they can’t do requirements analysis. I’ve seen projects go on and on and on because they have no clear goal of where they’re going.
Requirements analysis doesn’t mean that you’re locked into doing something the same way or the same plan for the entire project. Requirements analysis means that you have a vision, and you have a way of getting there. But you’re never going to get somewhere if you don’t know where you’re going in the first place.
The first step in requirements analysis is to create what’s called the wireframes and use cases. A wireframe is a graphical depiction of every screen in your software. If you’re developing a web app, it’s every screen in the web app. If you’re developing a mobile app, it’s every screen in the mobile app. Desktop app, same thing.
It’s a sketch of every single screen. What you’re looking at right here is a wireframe of the Spotlight status cards. This is a wireframe created in an application called “Balsamiq.” It shows the developers, the designers, everybody else, the project managers, what we’re creating.
Those numbers that you see all over there, they correspond to a spreadsheet that depicts what happens when each one of those items are clicked or what they are.
For instance, number one is the team member’s profile, his image. Number five is a chat button. Number five in a spreadsheet might say something like, “When the user clicks the chat button, a chat opens in the lower right hand corner of the web browser, enabling a chat with the two team members.” Then, it might see, “See chat wireframe and use case for more information.”
By doing your wireframes and use cases, you have lots of benefits. The first benefit is you really get an opportunity to think about what you want to design. I have seen, more often than not, when an entrepreneur does his wireframes and use cases, he starts thinking about things in his application he never would have thought of before. He starts pivoting some ideas he already had. It becomes an incredibly, incredibly useful endeavor.
Number two, by having wireframes and use cases, you’re able to go to your developers, your project managers, your QA and say, “Here’s exactly what we’re developing.” It’s not nebulous. You have something concrete that everybody can work towards, and everybody can create a project plan for, which leads us to the next planning item.
Now that you’ve got wireframes and use cases, let’s go ahead and set up what’s called sprints, goals, and tasks. A sprint in software development really is just a logical timeframe. For instance, a one week timeframe, a two week timeframe, where we decide that we’re going to go ahead and do the following tasks within the timeframe.
It’s a way to have a discrete unit of tasks to be done within a certain time in order to impose a deadline on everybody, so that we’re working towards a goal versus working without any clear guidelines. By setting up your sprints, by setting up your task, by creating clear, defined goals, everybody now is on the same page, on what needs to be developed.
Again, you’re not locked into doing everything that you’ve laid out, but, by laying everything out in advance with the wireframes, with the use case, with sprints, goals, and tasks, you now have a clear plan of what you’re going to do. You can modify that plan. In fact, 99 percent of projects are modified along the way, many, many times, usually every single sprint. But, again, without a clear focus, without a clear direction, you’re not going to get anywhere.
Spotlight is an incredible tool to set up sprints, goals, and tasks. Our tasks management system is a rock solid system to track tasks and to also track the time spent on every single task by all your team members. It is a world‑class system on parity with anything else in the world.
Let’s talk about phase three of hiring and managing a distributed team. This is the execution phase. This is the day‑to‑day phase. You’ve hired your developers. You’ve got everything all set up with your requirements analysis. Now, it’s time to sprint forward and execute on a daily basis.
There are three things that I recommend on a daily basis to do that will keep your team communicating and collaborating and on track. The first is a daily meeting, the second is regular status updates, and the third is daily progress reports.
The daily 15‑minute meeting. This is sometimes called a scrum. It’s sometimes called a stand‑up. Why does software development always have these unique vernacular ‑‑ scrum, stand‑up? Let’s just call it a meeting, ’cause that’s what it is, a 15‑minute meeting.
What’s it designed to do? It’s designed to get your entire team together, especially a distributed team, at the beginning of the day, and let everybody in turn describe what they did yesterday, what they’re going to do today, and any issues or blockers that they might have.
This daily meeting, this daily scrum, has several key advantages. First of all, for a distributed team, you’re getting everybody communicating first thing in the morning. If you’ve got a couple of guys in Mexico, a couple of guys in New York, and a couple of guys in Indiana, all of a sudden, everybody is communicating with each other first thing in the morning which is fantastic and exactly what you need for a distributed team.
Number two, by publicly saying what you’re going to do today, you’ve created a sense of group accountability. If I say, “I’m going to finish those database tables today,” everybody now is aware of what my goals are today. Scientific research suggests that when you make a goal public you have a much better chance of succeeding.
Do these daily meetings every single day. Spotlight makes daily scrums extremely easy by simply integrating Skype right into Spotlight.
You started your day with a daily meeting and instilled a sense of group accountability and communication into everybody. How do you get the team now communicating and collaborating all day long? Because, traditionally, with distributed teams, if they do their daily scrum, they now go off on their own.
What typically happens is a project manager or a scrum master will be Skyping all the individual developers all day long. “What’re you working on? How’s it going? How’s it going? What’s going on?” Basically, your scrum master or your project manager becomes a glorified babysitter. She might know what everybody is working on, but nobody knows what anyone else is working on because they’re all distant from each other.
That’s why in Spotlight we created what’s called regular status updates. If you’re not on Spotlight, you can do this via email also. What a status update is literally a update on what you’re working on, what the progress is, any issues, and your availability, sent out three to five times a day.
If you take a look at the status update on the screen, you’ll see that Harry has sent out an update saying he’s identified the database issue that causes the error and it should be fixed in 15 minutes. He’s 80 percent done with this task that he’s working on, and he’s available, letting everybody know that he is around. He’ll be available till this evening. Maybe later on, he’ll go ahead and change his status to away, saying, “I’m at lunch and I’ll be back in about an hour.”
These only take about a minute to do. There’s no excuse for anybody not to do these status updates because of how incredibly valuable they are.
Now that everybody knows what Harry is working on, somebody can jump in and say, “Hey, Harry, if you’re going to be good in 15 minutes, I actually don’t have anything else to work on for a little while. I can help you test it.” But nobody would have known it if they didn’t see the status update!
I can tell you, by experience, from somebody who has worked with distributed teams for a long, long time, these daily status updates are our lifeblood. It keeps distributed teams communicating and collaborating like they’re sitting together in the same office.
So you started your day with accountability and communication, and then throughout the day, the regular status updates kept the team communicating and collaborating. Now, you want to end your day with more communication and accountability, what I call the daily progress report.
Think of the daily progress report as an inverse scrum. Instead of saying what you did yesterday and what you’re going to do today, you create a report recounting what you did today and what you will do tomorrow. But instead of sending that report to everybody, it should be sent only to your supervisor, or the team member’s manager, or whatever.
In this way, there’s a one‑on‑one sense of accountability between the team member and the manager. The team member is now ending his day with accountability of what he said he was going to do in the morning, and he’s ending his day by communicating directly with his manager. Managers love daily progress reports, because they’re able to see what really happened during the day ahead of the daily scrum, and they’re able to plan for the daily scrum much better.
I find that when team members do daily progress reports every day, the actual scrum in the morning lasts about 50 percent shorter, because I’m able to scan the reports and say, “OK, I see what you’re working on. I had a question about your daily progress report. Any changes over there?” It moves so quickly. After all, the goal is to spend less time in meetings, and more time working.
I want to end this with just a quick note about “lean and agile.” You guys have heard the term many times. I’m sure everybody has. What “lean and agile” basically is is a way to create software in a fashion, such that you can change your mind as you move through the cycle of developing the software, without any major impediments to speed, delivery, time, cost, or anything like that.
The way that’s done is by first planning out exactly what you want to do, as we talked about during the planning phase, and setting up what’s called “sprints,” those predetermined time frames, those discrete time frames. A project might have, let’s say, 20 sprints that are two weeks apiece, and each one of those sprints has a certain amount of goals you want to accomplish.
The idea in agile is you’ll do one of those two‑week sprints, you’ll finish coding and QA for that one sprint, and then you’ll pause for a second. You’ll look at what you did, and then you’ll look at the goals for the next sprint and say, “Is this still what we want, or have market conditions changed? Have customers’ conditions changed? Has anything changed that we need to alter course, or are we still on course?”
A lot of the times, you will alter course. You’ll say, “OK, what we did was right, but for the next sprint, these goals are not appropriate right now due to current market conditions, and we want to swap out these goals for a goal much later in the project.” That’s what “agile and lean” allows you to do. Spotlight is set up for the agile, lean process, and it makes things extremely, extremely productive.
All right, I’m going to now open up the floor to any specific questions. Any questions whatsoever? If you have any questions about your own project, ask them. If you have questions about hiring, planning, or executing, please ask them now. Any questions about Spotlight, ask them now. I always like to keep my webinars right to the point, not a lot of flowery talk, so we jammed about two hours of information in about 23 minutes, just for the sake of being concise.
First question is, “What are some good requirements analysis tools?” Balsamiq. I think it’s spelled BALSAMIQ. It’s an inexpensive, online requirements analysis tool that allows you to create wireframes that can get you way down the road. You’ll have to create your use cases using a spreadsheet, and the two accompanied together are very, very impactful.
Another tool is called iRise, IRISE. It’s more of a prototyping tool than anything else. It has some unique advantages over Balsamiq. Balsamiq has some advantages over iRise.
The back of a napkin and a pencil is another requirements analysis tool. The idea about requirements analysis is make sure you sketch out what you want. If you have a client that you’re working for, you definitely want to make sure you have requirements so that the client doesn’t come back and say, “This is not what we agreed on.” With requirements, you’ve also added accountability to your client.
Another question is…Let’s see.
Every task is timed in Spotlight. Let me show you. I’ll give you an example. There’s a question about timing, and I want to show specifically. Right here, you see Javier is working on “Display time zone under picture.” What we’re going to do is we’re going to add a feature over here that shows the time zone that he’s in. He is 95 percent done with this task. He has been timed the whole time with this task. Let’s click on this and look into this task.
What you see is that Javier worked on it from 8:48 to 9:36 AM, again from 9:36 to 10:24, and again from 10:24 to 10:25. There is also a project report that will detail everything he’s worked on. So when someone submits an invoice, you can go ahead and balance his hours against all of the hours that he’s reported. Spotlight is designed to granularly track every single hour, every single minute, that somebody has worked on a task.
Other questions? The question is “How long should a sprint be?” That’s a very, very good question. I’d like to say that sprints typically should be about two weeks long. I like to say that “typically,” because there are conditions where your sprints will be one week, and there’s conditions where your sprints might be three or four weeks.
Once you’ve kind of hit a stride and you’re moving at a good runner’s pace, you’re going to find your sprints are going to get shorter and shorter, because everybody is working in sync together.
In the beginning, your sprints are going to be a little on the longer side, because the team’s getting to know each other, the project’s getting up and running, and you’re still getting your sea legs, so to say.
I would say, in the beginning, make your sprints a little longer, with an eye towards making it shorter as you move along. That’s just my personal experience.
Any other questions before we call it a webinar? All right, thank you very much. I appreciate you attending, and look forward to seeing everybody next Wednesday. Thank you. Bye‑bye.