With Spotlight, it’s easy to get your team communicating, see what everyone’s doing at any given time, and deliver faster with Agile. The key to success is great communication, and Spotlight delivers with system-wide integrated communication and messaging. By leveraging the best of social networking, you stay in touch with what everyone’s working on in real-time.
Many of our clients had experienced success with their projects using Spotlight. Here’s what some have to say.
My startup, tripchi, has been using Spotlight for the past few months… It is a streamlined and easy-to-use agile project management sprint tool… I think it will continue to grow in user base, as it has a unique niche in a market that is typically represented by software that is either over-featured and too expensive, or so basic that you can’t easily roll up information (Excel, etc.). Keep up the good work Spotlight!
– Chandra Jacobs, Founder/CEO
With offshore, near-shore and home-sourced development teams, the need to quickly collaborate and insure productivity and utilization for these resources is crucial. This product is combining proven project management practices along with social media tools. The result – greater productivity.
– Stephen Booze, CIO
Center for Entrepreneurial Innovation
I recently had the opportunity to see a demo of Spotlight and I can truly say this software just blew me away. I’m always looking for that easy to use, but very useful project management software and Spotlight is just that. As a business incubator manager, I suggest that all our clients in the program use Spotlight… Best on the market in my opinion.
– Jeff Saville, Executive Director
Building up Leaders
There are no easy or clean ways to manage project resources and people around the world, until now! Spotlight Software gets to the social side of resource management using a fabulous tool. I recommend this software to anyone who is managing a project resource in another country, especially when there is a time difference in play.
– Eric Walton, President
Spotlight Software was designed by an experienced software developer and manager to answer needs not addressed by other project management offerings. As such, it has critical, helpful functionality for managing virtual teams that no other PM tool features…. That added functionality allows for stronger, more efficient management of virtual teams, with accountability of project members at its core. Regardless of what online project management tool you may presently be using, I am confident you will find Spotlight to be superior and worthy of your use.
– Alan Lobock, Founder
SMART Business Systems LLC
Spotlight is a straight-forward way to setup the sprint backlog, assign, track, post, and review performance criteria all through a shared online service. Managing a distributed Agile team used to be a challenge. Not any more!. SerpicoDEV provides it as a service to software development clients. They use it themselves to manage their own projects so it must be good!
– Kevin Pugh, Founder/Owner/Developer
We love using this application at SEED SPOT and with select ventures in our program. It has helped us stay organized and plan appropriately.”
– Chris Petroff, Co-Founder
To compete, collaborate and create today you have to embrace a distributed/non-centralized “creation engine”. To harness that engine we must have the tools to properly manage and apply its power. Spotlight is one of those few tools and, with their current product roadmap, it promises to be THE tool.
Spotlight Software is your go-to tool to facilitate communication within your team; however, there can be too much of a good thing, even where team communication is involved. Over-communicating may be an especially pressing problem for teams that are changing and growing at a rapid pace, such as with start-ups and app development projects.
According to a recent article in Inc. Magazine, studies dating as far back as the 1970s showed that adding people to a project will put it further behind schedule. The article summarizes an IBM project case study, which showed that:
Every time some aspect of the project fell behind schedule, IBM assigned a few more people to the task. And what [the study’s author] Brook’s noticed, which still surprises people, is that this didn’t work. His observation came to be known as Brooks’ Law: Adding people to a late project tends to make it run later still.
At the heart of the issue lies the growth of an organization or team. As the number of team members increases, so too does the need for more communication between individuals. In the beginning stages, a project may only involve a handful of individuals who are involved in all areas of development. But as the team grows, positions tend to become more specialized, meaning that, while the number of individuals involved in communication increases, not every team member may need (or want) to know everything that’s going on. It’s been documented that most meetings – nearly half, according to the Harvard Business School – are unnecessary and hence, unproductive, in part because of over-communicating. Email may be a contributing factor, making it easy to invite a whole list of people or, as with some web mail applications, suggesting names to add to a list, even if those people are only loosely connected to the department at hand.
Spotlight tackles the issue of over-communicating by allowing for specialized reports and focused dialogue. Unlike other task management tools, with Spotlight, users have control over what’s important. While Spotlight offers a top-quality task management system, the real strength lies in its ability to help manage people and encourage timely, appropriate communication among virtual teams. By using social network-like communication tools, virtual teams communicate even better than in an office because users quickly see what others are working on at any time of the day.
In any project, software development or otherwise, communication is key. It’s of crucial importance, but is often overlooked, that ending the day with communication increases both productivity and accountability. Spotlight’s Daily Progress Reports feature allows users the option to fill out reports on a daily basis. Using these simple, yet comprehensive reports, distributed workers recount what they’ve done for the day, and detail what they’ll accomplish the following day.
Similar to a scrum (where team members discuss their projects for the previous and upcoming days) but with some very important differences – the Daily Progress Report ends the team member’s day by communicating with their manager. By mentally cataloging and physically recording the details of their workday, the Daily Progress Report accomplishes several key actions:
Mentally prepares team member for the following day’s work by outlining anticipated tasks and workload.
Prepares managers for the following day’s scrum by reviewing the team members’ Daily Progress Reports
Constitutes a written history of performance for each distributed team member
In addition, the Daily Progress Report function is customizable. All reports for the day are viewable in the inbox of the Report Center, and are optional by default, but can be made mandatory if desired. If a team member doesn’t fill out a Daily Progress Report, the system will actually block usage until the progress report is completed. Daily Progress Report can also be created, submitted and accessed via mobile.
Vincent Serpico: Good morning, everybody. Welcome to this week’s webinar, where we’re going to discuss the Report Center and the powerful features of reports in Spotlight. Let’s go ahead and get started.
First thing I need to do is go ahead and change my status. Let me go ahead and change my status to “Spotlight Webinar.” We’ll be on this webinar until about 10:15, Arizona time. I am in a meeting. Always be sure to update your status.
Spotlight has a feature called “Daily Progress Reports.” The idea behind Daily Progress Reports is that team members fill out reports on a daily basis, recounting what they’ve done for the day, and what they’re going to do tomorrow.
This might sound similar to a scrum, where you have your morning meeting with your team and everybody talks about what they did the previous day, and what they’re going to do today.
Similar to a scrum, with some very important differences, the Daily Progress Report, number one, ends the team member’s day by communicating with their manager. This is very important.
In any software development project, in any project, communication is key. It’s very, very important that you end your day with communication.
Also, by submitting a Daily Progress Report each day, there’s a sense of accountability created in the team member by submitting this report to their manager.
Also, by creating a Daily Progress Report, the team member mentally becomes prepared for the next day. Your most successful CEOs of Fortune 500 companies will do journaling at the end of the day, recounting what they did, and planning for tomorrow. This is very similar.
Also, a Daily Progress Report allows the managers to prepare for the next day’s scrum by reviewing the Daily Progress Reports for the next day.
Instead of coming to the scrum saying, “Yesterday, you said you were going to do this. What did you do?” they read the Daily Progress Report and say, “I can see what you’ve done. Now, let’s discuss what you’re going to do today.”
Finally, the Daily Progress Report is a written history of performance for each and every team member.
Let’s take a look at the Daily Progress Report. I see I have one new report, which I have not read. I’m going to open it right now, and take a look at it. Let’s see what Norman did yesterday. Norman did a lot of work yesterday. Excellent.
Today, he’s going to be working on documentation assignments, design bugs, and continue with task. Excellent. His progress looks good, and I’m going to let him know. “Looking good, Norman.”
I can go to the inbox of the Report Center, and view anybody’s report for the day. Let’s take a look at what Dan worked on. Looks like Dan was very, very busy yesterday.
We get to see what everybody worked on, at any given day, and scroll through the history of all your team members, and get an idea of their progress.
The Daily Progress Report is optional by default. However, your Daily Progress Report can be mandatory if you so choose.
What we’re going to do is we’re going to Project Settings, Daily Progress Reports. What you’ll see over here is a check mark next to the team members who must fill out their Daily Progress Report.
What happens if they don’t fill out a Daily Progress Report? The system will actually block usage until the progress report is completed. The progress report screen will display. When the progress report is submitted, then the team member will be allowed to use the system again.
You’ll notice there is a field over here for recipients. Recipients means that once your Daily Progress Report is submitted for the day, an HTML version will be mailed to anybody on this comma‑separated email list.
Note that the recipients on the email list do not need to be members of Spotlight. What is this used for? Maybe you have a peripheral stakeholder, a peripheral executive, client, somebody who wants to be apprised of what the team members are working on.
Finally, your Daily Progress Report will be submitted via mobile. You’ll be able to check the reports via mobile, and you’ll be able to create reports via mobile.
That’s a very good question. The question was “What is the difference between the daily report from the team member, project manager, and team lead?”
This is pretty much role‑based. If my role is a team member role, I’ll be filling out a team member report. If my role is project manager, I’ll be filling out a project manager report, and be able to see project manager reports, as well as team member reports.
If I’m a team lead, same thing. I’ll be able to fill out team lead report, and see team member reports. My role is a super user, so I’m able to see all reports. If my role was a team member, I would not see these reports, and I would not see these reports.
I’m going to wrap up unless there’s any other…That is a good question. Team members cannot see other team members’ Daily Progress Reports. The idea there is that these reports are meant for your managers.
During the scrum, we all get together as a team. We all discuss what we did yesterday and what we’re doing for the day. The Daily Progress Report is a report you submit directly to your manager, and your manager reviews it. It’s almost like a daily progress review.
Thank you very much for the questions. Thanks very much for attending. We’ll see you next week. Bye‑bye.
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.
Telecommunicating, outsourcing, virtual employees – with more and more work happening remotely, it’s the wave of the future. The concept works best with the right tools to manage a distributed team. That’s where Spotlight shines. Spotlight is a communication and task management platform for distributed teams. It’s a way for teams to get things done together, even when they can’t get together.
Spotlight is designed so you can work across multiple companies and projects, helping distributed teams work more efficiently with the unique social dashboard. Users can log into Spotlight on the Web or on the mobile app, available for iPhone and Android.
Spotlight shines in its features, like status cards with integrated Skype connectivity, status updates, a message center to facilitate collaboration and reduction of email pollution, and agile task management, which allows distributed teams to deliver results faster. Spotlight’s rock-solid task management system combines task and bug tracking, built‑in QA testing, task comments, and file attachments with helpful functionality like automatic time tracking, daily progress report benefiting team members by tracking what they accomplished on one day, to set accurate and appropriate goals for tomorrow.
Spotlight is the most trusted way for distributed teams to collaborate and communicate. Make Spotlight part of your team, and see why so many people are agreeing Spotlight shines!
Vincent Serpico: Spotlight is project management for distributed teams. It’s a way for teams to get things done together, even when they can’t get together.
Telecommunicating, outsourcing, virtual employees ‑ it’s the wave of the future. The concept works very well with the right tools to manage a distributed team. That’s what Spotlight was built to do. That’s where Spotlight shines.
You log into Spotlight on the Web or on the mobile app. Spotlight is designed so you can work across multiple companies and projects. Spotlight helps distributed teams work more efficiently with our unique social dashboard.
At a glance, everyone knows what everyone else is working on, as well as their availability. Spotlight’s dashboard creates a sense of group camaraderie, as well as group accountability.
Spotlight helps manage distributed teams in a lot of valuable ways. Let’s review some of Spotlight’s features in the context of optimally managing the distributed team.
First, Spotlight makes it easy to get the whole team together for a morning huddle by integrating Skype directly into the Spotlight status cards. This is a great way for distributed teams to start the day communicating with each other. Spotlight really shines with status updates.
As the day progresses, team members alert the rest of the team what they’re working on and their availability. There is no better way to keep a team communicating than Spotlight status updates.
The Spotlight Message Center is a great way to collaborate. Messages are consolidated in Spotlight, so you can avoid the dreaded email pollution, and quickly get to your messages.
Spotlight employees agile Task Management, so that distributed teams can deliver faster. We’ve built a rock solid, best in class Task Management system that features Task Tracking, Bug Tracking, Built‑In QA Testing, Task Comments, and File Attachments.
Tasks are always timed, so you know who’s been working on, what and when. You can even drill into reports to balance your invoices against actual time worked.
Spotlight’s Daily Progress Report is a way for team members to recount what they accomplished today, and set their goals for tomorrow. It’s also a great way for managers to review the daily progress of the team.
Spotlight is the most trusted way for distributed teams to collaborate and communicate. Make Spotlight part of your team, and see why so many people are agreeing Spotlight shines!
Launching a startup will most likely require you to outsource part of the work at some point during the initial building phase. Lack of readily available resources and skills make this unavoidable, especially in software development and design. But there are tons of opportunities out there to find this type of talent – almost 30% of the entire freelance market is made up of development and design pros. Whether you need a team to build out the product in it’s entirety or just added manpower, outsourcing this type of work is going to be far cheaper than hiring a full-time employee.
While hiring a freelance or virtual software team can offer many benefits, new challenges arise in trying to manage and collaborate with your team across locations. Often times, lack of communication and accountability in these teams can increase the already high failure rate of projects. But there are some things you can do to ensure your virtual software team stays in sync and is accountable for their tasks. Spotlight CEO Vincent Serpico goes on to explain each one in more detail in the video below.
Daily “Virtual” Scrums – Since most project managers are used to gathering the whole team for a daily meeting, this same process can be achieved for the virtual software team. Let all team members share what they did yesterday and what they will work on today. It’s a quick way to get the team communicating first thing in the morning.
Regular Status Updates – One of the biggest concerns for a project manager leading a virtual software team is losing track of them. They can’t see them in the building, emails and phone calls are easy to ignore, and time zones make it difficult. By having team members communicate frequent status updates of their availability, what they are working on, and progress, the whole team can collaborate better.
Daily Progress Reports – These reports are simply the daily meeting on paper. Having team members submit this short, free form report at the end of the day keeps them accountable for their work and still communicating with their team. The project manager can then properly prepare for the next morning’s meeting, keeping the duration short and getting the developers back to work.
While there is more to successfully executing with a virtual software team depending on the project, these three tactics can be easily implemented and quickly improve the team’s efficiency. Our company uses them for all our projects and even has the process streamlined right into Spotlight.
What other tactics have worked for you in executing a project with a virtual software team? Drop us a comment and let us know.
Software project management requires a versatile style of management that has to be adapted constantly. No longer is a pre-defined plan set and followed to a T. There are now twists and turns with requirements changes, new features, and unexpected issues throughout. The agile or lean process of development can help offset these challenges and is a very efficient method to turn your software idea into a polished product.
At Spotlight, we place an enormous amount of emphasis on our software project management process and making sure it’s as efficient as possible. This allows us to maintain weekly releases of Spotlight People & Project Manager (PPM) based off customer feedback and suggestions. We’ve maintained this practice all the way throughout the development of PPM and hence, wanted to share it with everyone else!
Coming soon to our website, we introduce TheVisual Guide to Successfully Managing a Software Development Project. This guide will take you through the entire process of developing your business application successfully, from idea to delivery. One of the biggest challenges for entrepreneurs and startups in getting their business off the ground is creating that first website, software, or mobile app. We’ve produced this guide to save you time and money in developing that software vision that is so exciting for your new endeavor.
Our guide takes you through the software project management process using a three-phase approach: hiring, planning, and executing. Let’s take a closer look at all three to give you a first peek into what the guide offers.
This first step in the three-phase approach is probably the most important. Hiring the wrong people to work on your project can set you back a long ways, both in time and financially. Our visual guide will show you how to clearly communicate your goals to potential developers, evaluate candidates through programming tests, and finally, the benefits to using a virtual team. An important thing to remember here is to hire a team that aligns with your software vision and goals, not just the one that is the cheapest.
Going straight into execution without planning your project is like going into a football game with no plays for the offense. Some people feel that the agile or lean methodology doesn’t require a plan. This is definitely not the case. In this second phase, we outline how to form the initial plan to provide your team with a direction towards the end goal. By all means, use the agile methodology during development, but formulating a plan helps get you to that development phase.
Our guide will show you how to implement requirements analysis, wire frames, and use cases to get that software vision on to paper. Setting up goals, sprints, and tasks is also done in this phase and we’ll walk you through a strategy that keeps your project on track.
Now for the fun (and last) part in our three-phase software project management guide: executing. This is where your software app starts to take shape. Managing a software team through this final critical phase can often determine whether the project is actually delivered on time.
In this section, our guide offers advice on how to turn your team into a well-oiled machine through effective communication and accountability. Using daily scrums, frequent status updates, and regular progress reports, it will feel like your entire development team is working in the same office (if they aren’t already). This keeps everyone on the same page, including all project stakeholders, to move the project along without any major bumps.
Software project management is not easy. Things change constantly when creating software and the ability of a team to be agile (see what I did there?) will determine its success. That’s why we’ve created this visual guide to successfully managing a software project, to help you hire, plan, and execute your project in the most cost and time efficient manner possible.
Interested in when our new visual guide will be live on our website? Contact us or sign up for our mailing list at the bottom of our homepage and be the first to know, along with other news and special offers!
A recent article from Wired described LinkedIn’s recent transition to a form of continuous deployment for their software development. It has been a resounding success, leading to software releases several times a day as opposed to once a month as it was before. This has allowed them to implement new features such as new company pages and a home page redesign quite quickly.
Spotlight is engrained in the continuous deployment process, releasing code to the production environment weekly and sometimes more often. Here we look at our experience with continuous deployment and how it may be worth considering for your business’s development process.
What is Continuous Deployment?
Continuous integration/deployment is the term used in software development to describe a practice where small chunks of code are deployed in production on a regular, frequent basis. After passing through various staging processes, the new code is released to its end users.
How is Continuous Deployment implemented for Spotlight Development?
The codes are basically maintained in a source code repository, which is also called a version control system. The changes or new development done by the developers are integrated in the working version of the code known as the mainline or trunk. These integrations happen as frequently as possible and currently, Spotlight is on a weekly release basis. The build servers are used to carry the integration process. There are ample reasons of having a build server, such as standard workflow independent of local development environment and easy access to code/test metrics. The build servers have automated test suites deployed to replicate the requirements of production environment. With a developer’s new code commit, build server gets triggered for integration and the test suites begin to run. These automated tests and some amount of manual testing produce results in the form of “Ready to Release” or “Roll Back”.
In case the code gets committed, it is available for release to the production server and its end users immediately. If the code does not pass the test requirements, all the coding is halted for the time the team takes to fix the code and make it releasable.
It is also possible to commit sections of code that are found OK in the test suite run. For example, pieces of future features can even be checked in without them being visible to the users.
Benefits of Using Continuous Development
Spotlight has been developed on a completely distinctive ideology of merging social media benefits to the project management concept. Since the idea is comparatively new to the market, the Spotlight team uses feedback from the end user and believes in quickly adapting new features and updates to this feedback.
Going by the traditional practice of first receiving feedback over a period of time, making changes accordingly and then releasing a new Spotlight product version to the market would involve significant time. In this age of rapid innovation, we know that the present customer demand is for enhanced quality in reduced delivery time.
In achieving this, Spotlight team is adding value to its standard practice as well -
With decreased time frame between consecutive builds, the defects can be recognized early in the cycle and hence lessens the effort to resolve them. This reduces the time needed to resolve the defects and the cost of failure.
The practice reduces the overhead of release. For example, as soon as a developer is ready with his release he can deploy it in the line of production.
It fosters learning, coordination and project team collaboration since each member is able to learn from the defects produced in the production environment.
The team does not have to defer the bugs until the next release and can move ahead with the bug fixes as soon as it is completed.
Continuous deployment has reduced waste in the production line process. Changes queued up over a year, meetings to decide if changes are safe enough to release and then the rework if these changes failed in production can significantly slow down the development process. Continuous deployment reduces the software inventory.
Our development team practices continuous deployment, which helps it in achieving faster time to market, earlier feedback from the end users and greater ability to respond to change.
Spotlight would advocate the continuous development practice to all the organizations that share similar ideology. Does you company use this practice for software development? Leave us a comment on how it’s working.
Development projects are unique. They are hard to predict, change rapidly, and introduce a number of software project risks. These risks can often be mitigated through Agile project management and practices, helping to deliver the project faster and cheaper. Here we list five software project risks and how Agile techniques can reduce that risk.
The software development lifecycle can be very difficult to predict. One bug here or there or a poorly laid out requirement can delay a project by hours, days, or weeks. With the intangible nature of software, it’s very hard to look ahead and accurately estimate a timeline of milestones.
Agile can mitigate this software project risk by directly involving the development team in planning and estimating. Years of experience give developers a great sense of estimating their work, especially if the requirements analysis is thorough. Using sprints, or short increments of planning and execution, the speed at which the team will move through the project can be quickly identified. Now project stakeholders will have an accurate idea of how the project will proceed at the beginning so they can make appropriate decisions throughout.
Inaccurate Requirements Analysis
A requirements analysis is of the utmost importance before a project even begins. Project Managers and Business Analysts will play a key role in this by having conversations with the customer on what goals they want their software to achieve. Even with a thoroughly thought out requirements analysis, there is always the risk of “feature creep”. As the project progresses, more and more features are added, threatening the estimates and timeline of the project.
Agile reduces this software project risk by building in time for discussions about features and changes during every sprint. Changes in the requirements and new features are expected through the project with Agile, thus teams are prepared for it. Instead of trying to include all these features for the next release, Agile teams prioritize changes based on importance. This means they will push less time-sensitive features to the bottom of the product backlog, allowing teams to anticipate what’s coming and be prepared.
Requirement Specification Errors
After the requirements analysis is complete, a project is broken down into specifications that are more detailed. When the initial development phase begins, it becomes obvious if the specifications are incomplete, have conflicting requirements, or too many tasks for the timeline. This can lead to major project delays as a result of having to circle back around to the beginning and rewrite the specifications.
This software project risk is mitigated by the Agile methodology through the role of product manager to readily make decisions on the project. When there is specification breakdown, a product manager has full project visibility to make key decisions on how to proceed. Oftentimes, traditional projects may lack this role causing delayed decisions, which can derail a project.
Project Team Productivity
Software projects can often be long and drawn out, resulting in motivation and urgency loss among team members as time goes on. Unmotivated teams will result in timeline delays and overall wasted time just trying to get them back on track and engaged in the project again.
Agile practices reduce this software project risk by using short iterations with frequent deadlines. This creates a constant sense of urgency that keeps teams motivated and working together towards the end goal. Agile also encourages frequent project team communication and team member accountability through daily stand-up meetings and progress reports. This creates a very productive working environment that can decrease the time to delivery for projects.
Project Team Turnover
Things outside of a manager’s control will cause teams to have turnover during a software project. Key personnel leaving the project take their knowledge and information with them, often resulting in significant delays or project failure. The number of great software developers available for hire is unlimited, but it always takes time to bring them up to speed on a project.
Agile project teams practice lots of information sharing techniques such as paired programming and daily reporting in stand-up meetings. When all team members share key information every day, this software project risk of critical knowledge leaving with the employee is small. Agile also reduces the bigger problem of key team members leaving by offering a highly collaborative environment that developers thrive in.
Agile techniques offer a number of advantages for software development projects. It will not eliminate all risks with the rapidly changing nature of software development, but you can implement many of the practices to decrease the chance of an unforeseen road bump. Are there other software project risks that Agile practices can mitigate? Leave us a comment with your suggestions!
Not surprisingly, the mobile apps industry is booming. According to the Wall Street Journal, both Apple and Google have over 700,000 apps in their respective stores. Global revenue from app stores is expected to rise over 60% in 2013 to $25 billion. Looking at the image below from shoutem, upwards of 21 billion apps will be downloaded by 2013.
Obviously, businesses and consumers are downloading more apps then ever. What’s this mean for your small business, especially if you are in the SaaS market? A mobile app is practically required to reach your entire target audience. What once used to be a nice perk if you had the resources to create a mobile app, has now turned a must-have with the workforce becoming more mobile than ever.
Mobilization of the Workforce
A major factor in the boom of the mobile app industry is the mobilization of the world’s workforce. A Forrester report shows that 66% of workers in North America and Europe already work remote. This has led to a huge increase in mobile apps being used by businesses for increased productivity no matter where you are.
Mobilization of the workforce doesn’t just have to mean those who are working “out of the office”. The medical industry is a perfect example. While physicians are running from room to room for appointments, having a mobile device in their hand allows them to quickly take notes or look up new and updated information. Mark Mills lays it out perfectly in his blog article on Forbes: “Apps are what makes mobile smart. They include providing physicians the functional equivalent of a nursing assistant, all the way to giving the farmer weather-through-commodity market decision capability on irrigation and harvesting.”
In keeping up with this shift towards the mobilized workforce, businesses must continue innovating to match all the mobile devices available. No longer can you focus only on the mobile app for iPhone or Android, you now must consider the iPad and Android tablet. With 63 million Americans expected to be working remote in the next few years, you can’t afford not to.
Creating mobile apps for the mobile workforce
While the project management SaaS industry in generally not known for it’s mobile app availability, Spotlight offers apps for both the iPhone and Android. In addition to providing an Agile project management system, Spotlight focuses on improving the communication and collaboration between project team members and managers. What better way to facilitate real-time collaboration than on a mobile app?
Spotlight’s mobile developers utilized Xamarin to build both the iPhone and Android platform. Xamarin gives you the advantage of cross-platform development in C#, meaning you can reuse the code between iPhone and Android. Our app was developed for Android first and then we reused almost 80% of the code for the iPhone. It cut down the development time tremendously leading to a huge cost savings on the project.
With Xamarin’s help, you can build a mobile app for your business without having to recode, saving you money in the long run. Think of it as a long-term investment that will generate returns probably quicker than you think.
Remote work will only continue to grow despite what Yahoo says. With this increasing trend towards a remote workforce comes the need for mobile apps that businesses can utilize to make their remote employees more productive. For your business, look at building apps that facilitate the proper communication channels and can be accessed from anywhere, any time, and on any device. Those alone already increase production.
Spotlight’s mobile apps provide these benefits and more for managing projects, specifically in software development. We’re excited to see what the future brings for the remote workforce.