Help Spotlight Software move through the field of 64 and win the Venture Madness!
We are proud to be selected as one of the 64 participants in the Invest Southwest Venture Madness. This innovative competition pits 64 of the region’s most promising startups against each other in an exciting bracket-style, head-to-head competition. In round 1, we are up against a very worthy competitor in Brett Approved and need your help!
Watch our video for the competition below and cast your vote for Spotlight here.
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.
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.
In part 1 last week, Spotlight CEO discussed the benefits a business can see by using a distributed team model. Today, Vincent looks at the issues he ran into while running his nearshore software development company that ultimately led to the creation of Spotlight People & Project Manager.
“Where the HELL is Pablo?!?” Mickey was pissed. Pablo was hired as a full-time dedicated resource for Mickey’s company through my services company.
“Did he send you an email or something, Mickey”, I asked.
“Nope. And we need to deploy the database before tomorrow morning. I tried Skyping him, emailing him, and called his mobile.”
It was 3:30 in the afternoon. “OK, let me try to get in touch with him. I’m sure he’ll make up the hours and we’ll be fine. Pablo’s responsible.”
Pablo really is responsible, and gets his tasks done. He works more than 40 hours per week… but not the usual 9-5. As a remote contractor, he enjoys the benefits of working remotely, which include picking up his kids from school around 3:15 in the afternoon.
I reached Pablo a little after 4:00. “Pablo… I don’t mind if you take off to pick up your kids… but you have to let the client know.”
Pablo seemed panicked. “Vincent, I sent Mickey an email. Here let me forward it to you.”
The email was sent in the earlier part of the afternoon. And lo and behold, it cited that Pablo would be out from 3:00 – 4:15, and that he would deploy the database when he returned. Which is exactly what he did, and the deployment turned out to be a success.
However, we still have the issue of solid communications among distributed teams. Because while I wish this was an isolated instance, it actually happens a lot more than it should. And it wasn’t just my company, it’s an issue that plagues all distributed teams…whether they are an office that telecommutes, an enterprise team spread across a campus, or a company that hires contractors in Mexico, India and China. Distributed teams face the challenge of communication, collaboration and accountability.
We all know where this story’s going, so I’ll cut to the chase. I built Spotlight to enhance communication, collaboration and accountability among my crew of ~25 contractors spread all over Mexico and the United States, and to provide my clients with a way to peer into the daily operations of their project. In other words, Spotlight’s mission was to minimize the “Where the HELL is Pablo?!?” phone calls from my clients.
It worked. It worked much better than even I expected. That’s why I spun the product off as its own entity. And with the help of my partner, Dan Schulz, we took the product to even higher aspirations by adding a task-timing feature that blows the competition out of the water.
So… guess whom our most excited customers are today? That’s right… PM’s, scrum masters and other product owners that received similar “Where the HELL is Pablo?!?” calls when they ran distributed projects.
Family, pets, laundry, the doorbell…the list can go on and on. Working at home can present its fair share of distractions, if you let them. But there are several things you can do to remain productive while working at home. In fact, mastering the art of balancing your work/life can often make you MORE productive working at home.
Our company has been working entirely on a distributed basis for the last year now. All of our employees have their own way of being productive; whether it’s working at night, tucking away in a coffee shop, or taking breaks during the day. This type of flexibility allows us to find times that are most productive for us and thus, make the entire company operate more effectively.
Using a combination of feedback from some our colleagues working at home and our own experiences, here are 10 to-dos’ that will help you be more productive.
Establish Your Space
If you don’t have your own office space in the house, you need one. Plain and simple. Oftentimes, half the battle of working at home is not being able to get away from interruptions because of no place to go. Having your own office space (with a door) allows you to completely separate the two: you can go to work in the morning and leave in the evening just by walking in and out.
Plus, who doesn’t like to be able to set up their own office?
Not being in the same office sometimes results in those creeping thoughts of wondering if your counterparts are really working. Don’t let those thoughts even start to brew. Being very visible online and communicating frequently with whatever tools you choose lets everyone know you are working and available. We use Spotlight to do this. One look at the dashboard lets you know exactly who is online and what they are working on. Trust is a big part of working at home so always be available when you should be.
There are hundreds, if not thousands of tools out there to help you work productively at home. And a lot of them are free. Skype, Join.Me, Zoom, and Google Hangouts are just a few of the free tools you can use to stay in touch with your team. While there are tons of tools out there, being able to find those that are multi-functional and have many of these features streamlined will make it a whole lot easier to manage.
Freshen Up (Your Location)
While a home office is great, sometimes you just need a change of scenery. Take advantage of a local coffee shop or library for an afternoon. The new environment can help you focus and make your office feel fresh again when you get back. Another advantage of the coffee shop is opening the door to impromptu conversations that you wouldn’t get at home. There are always other business people working so you never know when a connection might be made.
The Pomorodo Technique is relatively new and is a way to manage your time effectively. Simply set a timer to 25 minutes, which is called a Pomodoro, and see how many it takes to finish a task. Using this information and following a series of steps (see the video on the website) allows you to set up accurate timetables of your tasks and other activities. It helps eliminate burnout, manage distractions, and create a better work/life balance.
Learning how to self-motivate can take you a long ways when working at home. Since you aren’t always in the presence of other co-workers that can provide this motivation, teaching yourself how to self-motivate can keep you inspired and focused. As an employer who is thinking about using a distributed workforce model, having training sessions from experienced coaches on how to self-motivate may make your employees even more productive.
Multi-tasking with several chores around the house can get you into trouble quickly. It’s very tempting to get a head start on the laundry, run those errands you have, or clean the house. But you may find that these small tasks take up more time than you think and pretty soon you are way behind in work. You may be best off setting aside a time for tasks like this and separating it from the workday.
Goals are important in any work setting, whether you are working at home or in an office setting. But sometimes these goals are harder to achieve while working alone at home. Set daily and weekly goals, then write them down and refer to them frequently. Having set goals or tasks to accomplish each day and week will keep you focused and create a sense of accomplishment when you start crossing them off your list.
Start With a Routine
Don’t fall into that rut of your alarm going off and the only thing you do is walk 10 steps to your office and start working in your pajamas. Develop a routine in the morning almost as if you are going into the office. For example, I wake up and go to the gym, come home and walk the dogs, then get ready for work like I’m actually going into the office. A routine gets you ready to take on the day no matter what pops up (including that impromptu video call from your boss).
Working at home can mean you may not get out of the house for a while. So make sure you create time when you can get out, whether it’s with your family or friends. Look for local Meetup or networking groups in your industry and attend the meetings as a way to make new connections and find business prospects.
Working at home is a much different environment than going into an office, especially if you’ve never done it before. Staying productive can be a challenge for some people at first but by following these tips (among many others), productivity can often be increased. That’s why Spotlight has operated as a distributed workforce for the last year; we’ve found our employees to be much more productive and motivated. Stop in at our next webinar to see exactly how we do it!
What other tips do you have for being productive working at home? What’s worked for you?
Spotlight CEO Vincent Serpico talks about his experience working with distributed teams and why he ultimately decided to make the entire company 100% distributed.
“No, no, no!” That was my response close to a decade ago when I was informed the company I was working for was going virtual. At the time I was a VP leading a development team of 15 when C-level management made the decision to jettison the office space in favor of a virtual environment. I was staunchly opposed. I cited reasons like, “I need to look my developers right in their eyes”, “they’re going to slack off at home”, and “you just can’t get good synergy when you’re a distributed team”.
I was dead wrong on all accounts.
Fast-forward to today, and it’s obvious that I am big supporter of working remotely. As founder and CEO of Spotlight Software, working remotely is the foundation of Spotlight’s value proposition. Not only am I a big supporter of the distributed model, but also recommend it to anyone that’s starting a new business.
My transformation from anti-remote to pro-remote happened slowly, and quite unexpectedly. It was for reasons I never expected. It was for reasons that make working remotely much more preferable both from an employee perspective as well as a business owner perspective.
Better Work Life Balance / Less Stress
This one caught me out of left field. I wholly expected my work-life balance, and that of my employees, to suffer when working from home. I mean after all, how can you separate work and life if you work from home?!? What I discovered was quite the opposite. My work-life balance got better, as work related stress actually decreased. I hear the same s thing from my team as well.
No one could really cite why work life balance improved, but I have my theories. It revolves around mindset. When you’re at work, that’s your mindset. You’re at work. When you’re home, that’s your mindset; you’re home. And when most employees are home, they block out work. But when your home is your work environment, all that seems to change. You’re actually able to have work and home life coexist in the some environment. As such, work related stress plummets, as you’re able to step in and out of the work mindset at will.
Of course, decreasing your commute from 5-10 hours per week to a few footfalls away always reduces traffic related stress.
So this one was a very pleasant surprise. Remember I argued that employees would slack off at home? Well, again I was wrong as I noticed that my employees and I were actually MORE productive at home then at the office. My theory here is goes back to the improved work-life balance. Since at-home workers can step out of their office at any time to eat lunch with their family, go to the dentist or just talk a quick jog to recharge their batteries, they feel less under-the-gun. As such, the remote worker feels more empowered and more in control of his own day. The result is more focus. Speaking from a personal perspective, when I know that I am not under-the-gun to get things done by 5:00… that I can go pick up my kids from school when they get out, I am more focused while I work because I am less stressed. More focus, of course, equates to more productive hours. Also, when an employee is less stressed, he has more of a willingness to put those extra hours in when needed without being prompted.
Greater Team Synergy / Better Collaboration
I thought that ditching the office meant a decrease in team synergy. Yet again, I was wrong. Synergy and even team bonding jumped. I think it’s because of self-empowerment. No longer is a PM standing over an employee as a task master, instead, the employee is empowered to carve out his own day and live up to their own responsibilities. As such, they don’t feel encumbered by an Orwellian overlord to take the time to chat with a fellow employee about a design pattern or ask for help testing or debugging. My distributed teams have forged a better bond thousands of miles apart, then a few feet away in an office.
Of course, there are other reasons to embrace the distributed environment, like:
Lower cost of overhead for employers (office, phone, electricity, etc.)
Lower cost of living for employees (tax write-offs, gas savings, etc.)
Wider talent pool
Potentially lower cost talent pool
“Greener” (no cars commuting)
So… the net net is that I am hooked on distributed development. So much so, I created an application that encapsulates the best of what I learned managing distributed teams. Spotlight is a communication and task management platform designed specifically for distributed teams. It enhances the best of a remote model, while filling in the gaps to bridge the remote world with the same experience as being in an office. We use Spotlight on a daily basis with dozens of clients who embrace the distributed workforce model.
Is your company using a distributed team environment or thinking about hiring online? Join us for our next webinar when we go into more detail on our distributed environment model and how we make it so effective.
Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at firstname.lastname@example.org. Andy’s new book Risk Management for Project Driven Organizations is now available.
This is a guest post by Andy Jordan, President of Roffensian Consulting, a management consulting firm in Toronto, Canada. If you are looking for more from Andy, he is also a regular contributor on projectmanagement.com.
Technology has brought a considerable amount of change to the way that work happens today, and to me one of the most significant (and welcome) changes is the way that it has enabled people to work closely together regardless of where they are physically located. While the idea of flexible working or distributed teams is not new, until recently it always required compromises to be made. As a project manager I had to accept that I wouldn’t be able to communicate so easily with a team member in a different office, country, time zone, etc. I knew that there would be delays and confusion at times and I just accepted that as part of the cost of doing business while trying to minimize the impact.
Well that’s not the case anymore, but to look at how some organizations manage distributed teams you would never believe it! Advancements in technology have allowed for new tools to become available that allow for true collaboration, real time communications, universal access and updates to status, etc. It’s project management gone social, and yet many organizations still manage distributed teams by e-mail and voicemail – ironically while ensuring in their personal lives that they are always able to monitor Twitter and Facebook.
The success of any project is built on a strong team, synergy has become a clichéd buzzword in recent years, but it is no less real, and when a group of individuals can come together to work on a common goal the results can be dramatic. However, if some of those team members feel as though they are not truly a part of the team because they are physically removed, or if energy has to be spent trying to connect with people to discuss issues, obtain updates, etc then not only is synergy lost we can easily create an environment where the entire team dynamic is damaged, reducing morale, lowering productivity and significantly damaging the chances of project success. With the recent growth in Agile project execution approaches this becomes even more important – delays and confusion can have dramatic impacts.
So what can organizations do to better manage distributed teams? Well tools are part of the solution, but before you run out and buy a Project Portfolio Management (PPM) software solution, you need to understand what your unique challenges are and what problems you need to overcome. The best tool in the world won’t help if it isn’t used properly so organizations need to consider:
How effective and efficient are projects with remote / distributed teams relative to projects where all resources are co-located?
What are the specific problems that those projects face?
What is the root cause of those challenges – process, training, people, etc?
Only when these aspects are understood can the organization implement a plan to improve, and only one there is organizational commitment to improve is the organization ready for a tool to support that transformation.
In my experience many of the problems come down to broken or ineffective communication links so one of the most important elements of any PPM solution is the ability to effectively facilitate real time communications through instant messaging, status tracking, etc. A few years ago there may have been reluctance by teams to embrace these tools, but in the current technology environment the fact that these are really just corporate extensions to the type of interactions that many of us have in our personal lives through social media makes rollout and acceptance much easier.
It probably won’t be known for several months the exact cause of the collapse, but it would be a pretty safe bet that a communication breakdown is somehow involved. The importance of effective communication and collaboration during an agile development project sometimes just isn’t realized until it breaks down.
It’s even more important in agile development projects with distributed teams. More businesses are implementing this strategy as a cost reduction and to expand their talent search outside the local area. But with this comes the challenge of keeping the distributed team on the same page and collaborating effectively.
This week’s Friday Findings offers a list of books for managing agile development projects with distributed teams. The authors are experienced and seasoned in the process, offering a great resource for your business to effectively use this strategy. On to the findings…
This book covers a 60-minute interview with Ambler where he discusses some great examples of how development teams are adapting agile methods to work in a global team environment. You will learn how to break down communication barriers to improve project team performance.
Eckstein discusses how to address the challenges of agile software teams working together over great distances. Full of several real-world experiences from other practitioners, this book will train you to form customized plans that fit your distributed team’s situation.
Written by three of IBM’s Scrum experts, this guide serves as basis for Scrum practitioners working in a distributed environment. The authors look at several real-world project examples and how to apply key Scrum practices in a distributed environment.
Global software projects are becoming the norm for many businesses that operate in multiple locations to take advantage of talent and cost savings. The question often comes down to whether they should implement agile tactics in their global projects. The authors break down agile implementations for distributed teams into five areas: motivation, transition, management, teams, and the epilogue, which offers future trends and research.
While not directly targeted at distributed teams, collaboration is one of the biggest keys to project success in a distributed environment. Tabaka discusses collaboration and facilitation techniques for agile software project leaders to get their teams interacting through the project lifecycle. More effective collaboration equals higher delivery success.
This book discusses the “Design for Hybrid Agile Adoption” approach in implementing successful agile approaches with distributed teams. Venkatesh covers various tactics in making agile development projects with distributed teams successful such as collaboration techniques, metric analysis, meetings and interactions, and many other factors.
Yassin creates an entire global software project scenario in this book and takes you through the whole thing. He looks at all the possible roadblocks that could be ran into when working on a distributed basis and solutions for those roadblocks. Collaboration techniques are discussed that address time zone, culture, familiarization, and trust issues that pop up in agile software development with distributed teams.
Techniques proven successful at electronics and software company Siemens AG are shared in this book about developing software on a global scale. The authors discuss how Siemens uses a high-level process framework of agile methods that fosters team building and effective team collaboration. Real-world examples of both successful and failed projects offer takeaways of what to do and what not to do for success in leading agile development projects with distributed teams.
In this book, Ebert covers best practices for managing software projects across borders. He discusses his own first-hand experience in executing projects across multiple locations, mitigating risk, and creating a highly effective collaboration environment for distributed agile teams.
Properly managing risk in a global software development project is a key consideration for any business looking for success. Using real-world experiences, this book provides several tools and techniques to manage the risk that arises in agile development projects with distributed teams. Hussey discusses how to gather insight into diverse team personalities in order to achieve trust and effective collaboration between team members, ultimately leading to success.
Every book has one thing in common (at least) and that’s effective team communication and collaboration. Agile software teams on a global scale can’t survive without it. Phone and email are typically not enough and a social network based collaboration platform like Spotlight offers can make a team that much more productive. It keeps everyone on the same page all the way through the project.
Are you an experienced project manager leading distributed teams? Share your experience and techniques to help the rest of us out!
Stay up to date with Spotlight’s latest content, news and special offers – Join our mailing list! (We promise not to use your email address for anything else and you can unsubscribe at any time.)
Daily scrums are the first step in building team trust in Agile software development. They keep development teams communicating and working in sync towards the project goals. Scrums keep projects on track, help identify issues early, and increase overall productivity.
Virtual teams made up of freelancers or contractors are increasingly being utilized to execute software projects for businesses. One team member may be in Mexico while another is in Chicago. With different time zones, little face-to-face interaction, and different schedules, how can a daily scrum possibly be executed? We offer 5 tips for holding daily scrums with virtual teams.
Daily scrums only allow you to get your entire team together for 15 minutes every day. Maximize that time to the fullest with open and quality team communication. Whether you use video or web conferencing, the traditional conference call, or even a group chat, ensure that it’s not 15 minutes of only one person speaking. Silence from team members can mean a number of things so don’t just infer there are no issues if this is the case.
At Spotlight, we have all team members log into a Go To Meeting session daily. They communicate three things:
What tasks did I do yesterday?
What tasks will I do today?
Are there any issues that need addressed?
As a result, developers will end up doing some paired programming on any issues that are brought up during the meeting, further strengthening team trust and camaraderie.
The daily scrum process may be a little different for every business or Scrum Master. Some will include only development team leads and others will include all developers. We have found that including everyone, from QA to Designers to developers, keeps the team operating at the highest efficiency. In a virtual team setting, information is more likely to get lost or forgotten if communication is not optimal. Having the entire project team collaborate in the scrum ensures there are no surprises and keeps the entire team moving forward in unison.
All phases of a software development project are interrelated so one piece can’t operate without the others. Having all members of the team participate in the scrum lets development know when design is ready and so on.
Once you decide on a method of communication and time for the daily scrum, try to keep it consistent every day. Ideally, it will be first thing in the morning so the team can discuss what went on the day before and the tasks they have coming up that day. If any issues are brought to the table, the developers have the rest of the day to find a resolution.
One of the beautiful things about working virtually is the ability to be flexible with schedules. If your developers don’t work the typical 8 to 5 workday, schedule the daily scrum at the beginning of their shift. Our development team typically works from late afternoon well into the night. The daily scrum is scheduled when they get online so they have a full workday’s opportunity to address any concerns.
Keep it short
Keep your daily scrums short, typically around 15 minutes. Developers don’t have time to sit there on the phone or in a web conference listening to a conversation that doesn’t concern them. Virtual daily scrums can get especially time consuming if every team member is taking time to speak in this manner. Clearly communicate the answers to the 3 questions of daily scrums and adjourn so everyone can get to work.
Schedule follow-up meetings
Abbreviated daily scrums lead us to the next tip: schedule follow-up meetings. If team members get into a conversation on an issue or development task during the scrum, have them jump back on the conference call later to discuss further. This allows the rest of the team to go about their daily agenda while the other team members work together on the issue brought up in the scrum.
The Scrum Master can then assist with any specific issues directly if need be or take a question back to the product manager.
Daily scrums keep the communication channels open within virtual Agile software teams to keep the entire team in sync with each other. This helps tasks get completed faster and bugs identified sooner. All of this adds up to faster time to delivery.
Do you have other unique ways of executing scrum meetings in a virtual setting? Leave us a comment with your experience!
These days, businesses are going to hire the talent they want, regardless of location. This means they are more willing to fill a job with a person who is thousands of miles away if they are indeed the best candidate.
When people of a project team are scattered throughout the world, the door opens a little wider for virtual employee problems and disconnect from the team. That’s why it’s so important for managers to make sure team members stay engaged and productivity remains high. If motivation is starting to lack and virtual employees are becoming distant, it’s important to learn how to recognize it and take action.
So how do managers recognize this change in behavior? It can be difficult at times but there are some ways to hone in on virtual employees having issues: Level of communication, tone of voice, and body language.
Level of Communication
The first, and maybe most obvious, sign that a virtual employee is disengaged is decrease in overall communication. If you are having a hard time reaching them on email, phone, or whatever communication method you use, there may be a problem. This could signify they have other things on their mind ahead of the project.
Granted, this could be a temporary breakdown of communication that is short-lived. So look for a consistent downturn in responsiveness over a period of a couple days. If you are having a hard time reaching a virtual employee within two days, it may be time to take other measures. One approach is to use their direct peers to check if something is wrong. For example, in software development projects, fellow developers can often provide some insight because they are working with each other constantly and develop a different type of relationship.
Tone of Voice
Conference calls are a necessity of any virtual team. A good way to gauge a virtual employee’s engagement is by the tone of their voice. This also includes even listening for complete silences. Billie Williamson, partner at Ernst & Young, would listen for signs of disengagement during every call. “Silence can mean consent, or it can mean the person you’re not hearing disagrees or is disengaged.”
If you sense a virtual employee is lacking engagement, follow up immediately. Put a positive spin on the follow up and see if there are any issues you can help with. This will often give you a good sense if it was a fluke or there is a larger underlying problem.
The first thing you might be asking is how can you use body language in a virtual team setting? Even though you aren’t in the same office, body language can still be recognized via video conferencing. If you suspect a team member is not fully involved, see how they collaborate at the next scheduled video conference meeting. Multi-tasking, lack of interest, or no eye contact can mean they aren’t fully processing the information or even paying attention.
Try to engage the employee during the meeting if these signs are evident. If you know they are knowledgeable about the subject, ask things like “…you had some great ideas when we talked about this last, can you offer your insight?” This will ensure they feel positive about communicating their ideas and help dig a little further into the potential problem.
This is by no means an exhaustive list on how to gauge your virtual employees level of interest in a project. At Spotlight, we gain a sense of this through team member status updates, using both the quality and quantity of the updates as a baseline. If a member updates his/her status in the morning and not again the rest of the day, we have a pretty good idea something is going on. Our project manager will follow up and see if there are any problems, offering as much help as possible.
Another key that can often tackle this problem form the beginning: communication, communication, communication. Frequent and quality communication between all virtual employees on a project team can help quickly build trust and lead to faster identification of potential issues.
Are there other ways to evaluate your virtual team’s engagement in a project? We welcome your tips and comments from past experiences!
It’s no secret that in any project, frequent and meaningful communication is the key to success. This is especially true in software development as teams are doing more and more projects virtually across borders. When you think about all the means of communication available for teams, there is one that connects all of us regardless of location: social networks.
Our tag line here is “Project Management goes Social”. Project management and social are two words that you probably don’t see together very often. But Spotlight combines the two, using social network-like communication to keep project teams in sync and Agile project management for process and delivery. Now team members can collaborate efficiently on project tasks and know the status of everyone without ever picking up a phone or writing an email. Saves time to say the least.
There are a number of ways social networks solve communication challenges. Here we look at three that help project teams improve their communication, regardless of location.
Software development projects will definitely have those urgent situations. Bugs that need fixed now, impromptu demonstrations, and server interruptions require very quick action. While email may be option, many people don’t have alerts set up or even check it that often.
Twitter-like communications can serve this need for quick information sharing that requires immediate response. Using protected Tweets and hashtags, team members can be quickly notified of events. Spotlight incorporates this Twitter-like messaging through quick status updates for events like this. Our developers simply send out a short message to let the rest of the team know when a major bug is reported or if they will be out of the office for an appointment. These messages immediately appear on the Spotlight dashboard for all team members to see and take action.
Using this Twitter-like feature has cut down our emails and phone calls dramatically. This allows us to use our email for communication with customers and external stakeholders.
Building a community
Project teams, especially those working virtual, often run into trouble building that trust between team members. Being successful requires the project team to learn about each member, how and when they work, strengths, weaknesses, and culture. This will develop that team chemistry even if you aren’t in the same office.
Building a Facebook-like community can encourage this kind of interaction. These communities give team members the opportunity to get to know their colleagues a little more on the human side. Spotlight incorporates this sense of community by providing every team member their own status card that appears on the dashboard for all other members to see. We often encourage our team to update their status with exciting things going on in their lives to build that team camaraderie. Other team members can “Like” the status or reply to it.
Building this trust through communities can be invaluable when the project hits a road bump and things get a little tense. Team members who know each other on a more personal level will often work together better in these scenarios.
Shared team discussion
Discussion boards or shared notebooks can serve as a great platform to work out bugs and assist each other. A social wiki often serves this function well where people can add, modify, and remove content at their choosing. Have a great tip to help someone with a task? Post it to the wiki and let your teammates add supplemental information to it.
Spotlight incorporates this idea into its platform through a shared project board. Similar to a wiki, any team member can post content to it, ask a question, or upload relevant files for the project. Our developers often post to the project board when a major upgrade to the production server is being deployed, letting everyone know the situation. Unlike the quick, individual status update, this message appears there until it’s manually removed so no one misses it.
Having a collaborative area like a wiki where the project team can trade ideas and help each other often results in faster task completion. Eventually, it can turn into an entire library of reference material for future projects.
While social networks like Twitter, Facebook, and a wiki are great tools, you still have to keep track of all three separately. That’s why Spotlight incorporated all of these features into a centralized platform where you can take advantage of each. It makes communication among our project teams seamless.
Has your business or project team used other social network platforms for improved collaboration? We’d love to hear about other tools and your experience.