Blog
... latest news about Spotlight

News for the ‘Application and Mobile Development’ Category

A Guide to Choosing a Mobile App Development Platform

Posted by: Seth Weedin

The mobile app economy is booming. The word booming may be an understatement as the sales of physical goods and services from mobile apps is expected to reach $151 billion by 2017. According to Google’s Our Mobile Planet, people will have an average of 20 apps downloaded to their phone at any given time. So as Flurry put it: “It’s An App World, the Web Just Lives In It”.

It’s no secret that your business needs a mobile presence, whether it’s a native app or a mobile-friendly website. But knowing which mobile app development platform to choose for both cost and quality is difficult for business owners with no background in software.  There are so many things to consider from flexibility and scalability to cost and difficulty of development.

Some mobile app development platforms offer clear advantages over others. The key is considering the trade-offs for each and finding that one platform that gets you the biggest bang for your buck. Here we look at 5 popular platforms and how they stack up against each other for a quality mobile app experience.

Mobile App Development Platform Comparison

Click to enlarge

Objective C + iPhone

Using the Objective C programming language, this platform can be used across all iOS devices. The native platform for developing the app gives you the most comprehensive API integration and a very strong developer community. This combination of the developer community and extensive documentation offers your development team lots of great resources for efficiently building a mobile app with Objective C.

The obvious disadvantage is that it applies only to iOS and is not cross platform. But it is a very efficient mobile app development platform for iOS specific apps. The combination of a GUI builder, fast compilation speeds and great developer support will give you a reliable and high functioning iOS app.

Java + Android

Java for Android can be used across all Android specific devices and is a native platform. Similar to Objective C for iOS, it offers a very comprehensive API and developer community for support.  Java for Android is open source and has a faster learning curve than Obejective C.

While not cross platform, this is a very good mobile app development method to creating Android apps. Java is also a very secure platform if you plan on processing sensitive data via the Android app.

Mono

MonoTouch and Mono for Android from Xamarin use C# and .NET to allow you to reuse code between platforms. This cuts down on development time, reducing the overall cost of developing a mobile app. For example, we built Spotlight’s mobile apps using Xamarin and reused almost 80% of the code between iOS and Android. The platform provides access to native API’s on both devices and rich IDE support. Mono is very easy to learn as any developer with existing .NET skills can start building almost immediately.

The one drawback to Mono is that it does require a fee at $399. If you choose this route to build a mobile app, just consider the trade-off between reduced development time and the extra cost to use it. If you can justify the trade-off, this mobile app development platform is definitely worth it.

Phonegap

Phonegap uses a combination of the HTML, CSS and JQuery languages for mobile app development. This platform basically allows you to use a normal webpage and repackage it as a mobile app with minimal changes. There is no need to learn a new API or language to work in Phonegap making it fast and easy.

It also can be used across both iOS and Android devices but does not use native widgets meaning the app will not appear native. Documentation is sparse causing difficulty for developers if they run into something unfamiliar. Phonegap is good to quickly get your app ready but may lack some of the overall functionality the other mobile app development tools have.

Titanium

Titanium is an HTML and Javascript platform that can be used across iOS and Android devices. The main advantage with Titanium is the ability to use Javascript to build apps with native widgets, making all apps look native.

Several disadvantages of Titanium may make you want to consider the other platforms ahead of it. Titanium only uses its own API to lie out widgets so any other existing tools will not work. The API also differs considerably between iOS and Android devices, which will increase development time. Overall, builds are very slow, especially for Android.

Conclusion

These mobile app development platforms are only a few of the ones available but are probably the most widely used. Each has its own advantages so finding the one that is right for what you are trying to accomplish with your mobile app is key. Reliability, scalability, and security should all be major considerations when choosing the right mobile app development platform.

Choosing a mobile app development platform is only a start; you still have to manage the project through delivery. Spotlight PPM can help by providing you the visibility and collaboration tools needed to ensure your development team is on the right track towards a successful product delivery. Learn tips and techniques on how to manage a mobile app project by joining our community.

Have other platforms or tips on mobile app development? Share your expertise and help the rest of us learn!

To stay up-to-date with Spotlight Software and Spotlight People & Project Manager,  join our mailing list or visit our FacebookGoogle+LinkedIn, or Twitter profiles.


Themes, Epics, & A User Story – Huh?

Posted by: Seth Weedin

A user story, goal, epic, theme…terms you hear all the time in agile but can often get confusing. The fact is they are very useful organizational terms in an agile project and relatively easy to understand. We like to look at these terms as an agile hierarchy of how projects are broken down into smaller parts.

User stories, epics, and themes are a way to break down projects for easier manageability. A user story is simply a feature a user wants in their software. For example, you may be building a website for a client and they request the acceptance of credit cards for their shopping cart. So the user story would simply be “Accept all major credit cards”.

An epic is a very large user story. The story described above of accepting all major credit cards could be considered an epic because it could probably be broken down into smaller user stories. Just be aware that an epic will likely have many tasks associated with it if you go forward using one.

A theme is a collection of user stories. Accepting all major credit cards could be part of a theme called “Shopping Cart” or “E-Commerce Platform”. There will often be several user stories that all fall under this main topic or theme in the project.

The agile hierarchy is set up a little different in Spotlight but still follows the same principle. We break it down into three areas: projects, goals or user stories, and tasks. It may be easier to think of it as a folder structure, with each folder containing the one below it. So projects contain goals and goals contain tasks.

Projects

In Spotlight, each company workspace contains specific projects that the company is working on. If your company develops mobile apps for customers, you may have the projects divided up by the business name of that customer. The project below is for the Locke Supply Co web application that currently has two team members, two in progress tasks (yellow), and three completed tasks (green).

Project in Spotlight PPM

In any company that manages multiple projects, you will have different users working on different projects. By organizing your company workspace into separate projects, you can add multiple users to one project or the same user into multiple projects. Each project automatically keeps track of the users time spent working on tasks for easy invoicing and management.

All projects contain goals, which further breakdown the project for easier manageability.

Goals (User Stories)

A goal in Spotlight is similar to a user story. They are simply a feature or functionality the user wants in the software application. Goals are often a good way for outside stakeholders to follow the progress on parts of the project that affect them directly. For example, the billing department may want to follow the goal below of “Accept all major credit cards”. As this goal progresses, they will know when to expect its completion and their new customer billing process will begin.

Goal or User Story in Spotlight PPM

Each goal contains a number of tasks to complete the functionality the user asked for. In the goal snapshot above, the number of open tasks (three in this case) can be quickly verified. Stakeholders can also get an idea of the progress, efficiency, quality assurance status, and projected delivery date. As the tasks within this goal are completed, the progress and efficiency rating will change.

Tasks

Tasks are exactly that – specific things that need to be completed by the individual team members building the application. Having specific tasks that can be assigned to individuals is a way to keep teams motivated and accountable for their work. They won’t always be looking for something to do when tasks are out there waiting.

Tasks are clearly listed in the details of every goal. The owner can quickly see what tasks have not started, are in progress, or complete along with the QA testing status. By clicking on the task, further details will be shown including the team member working on it, comments, attachments, etc.

Tasks in Spotlight PPM

In Spotlight, not all tasks have to be part of a goal or user story. There may be improvements on existing features or bugs that need to be fixed, but don’t correspond with a particular goal. The task manager is the area to manage these. It is a complete list of all tasks within the current sprint of the project. It allows you to create, import, search and filter tasks among many more functions.

Conclusion

Organizing your projects into an agile hierarchy like this allows stakeholders the flexibility to contribute or follow the functions they are most involved in. Themes, epics, and user stories or goals in Spotlight keep the project organized and with that, the entire team delivering it.

Now it’s your turn – does your team use these types of organizational containers in agile projects? If so, how do you manage them?

If you would like to see how they are organized in Spotlight, give us a shout for a demo and more information.

To stay up-to-date with Spotlight Software and Spotlight People & Project Manager,  join our mailing list or visit our FacebookGoogle+LinkedIn, or Twitter profiles.


Measuring Quality in Offshore Software Development

Posted by: Seth Weedin

The term ‘quality’ comes up a lot when considering an offshore software development strategy. Any business that has thought about offshore software development as an alternative to hiring in-house often asks themselves, “How can I still ensure a quality product at the end of the day?” This tunnel vision of only thinking about quality in terms of the final product is what gets businesses into trouble when offshoring. Quality isn’t only about the final product; it starts the minute you decide to take the offshore development route.

Using an offshore software development team can be very successful and produce high quality applications. But the quality starts from day one of the project. An industry disrupting application doesn’t just happen with a talented developer putting his or her head down and writing the application. It definitely helps to have an experienced development team but the quality and success of the product is all about how the project is managed from the start.

Turning your software idea into a quality and robust application often comes down to three areas: preparation, people, and processes.

Ensuring Quality in Offshore Software Development

(Credit: Udayan Banerjee)

Preparation

Businesses thinking in the short term don’t often do all the necessary preparation. They just know they don’t have the people to build the software in-house or the resources to hire full-time. So the project is sent out the door to a cheap outsourcing firm with hopes for a quality application in 6 weeks. The horror stories often heard with offshore software development start right here.

Do all your homework first. This means having your idea clearly mapped out and a detailed software requirements analysis written. The fact of the matter is most offshore service providers will only produce exactly what is given to them. So go heavy on the details of your product roadmap. Ensure your management team and stakeholders understand each and every requirement that will form the roadmap. Show it to one of your colleagues with development experience for further validation. This will save a lot of headache when revealing the requirements to an offshore partner and help to ensure the quality will be built right in.

People

The requirements analysis have been written and a product roadmap in place. Now it’s time to engage the right people who will create that quality app you are looking for.

An offshore software development company will usually hand pick the people within their company to develop the software. It’s advisable not to let this happen and ensure you have an influence into the hiring decision. Thoroughly vet the software developers being considered even if it requires a few days. The best way to really get a sense of how they’ll work with your team and their talent? Hand them a short development task and see how they handle it. A payment may be required for this task but a mere $50 is worth the trouble if it validates you will get a quality product in the end.

Considering freelancers from sites such as Freelancer can offer more control over the project and team than a traditional, large offshore company. In this scenario, you have complete control over your team instead of trying to work through several people in a large company. Finding the right people will help make the process of working together smoother.

Process

The process of putting the project in motion begins the actual management phase. This mainly boils down to the question “How will we work together?”

First, ensure the requirements analysis are understood and agreed on by everyone involved on the development side. This will put the team all on the same page and working towards the same goal. The detailed nature of the requirements analysis helps build in the quality, not allowing the team to overlook something.

Ensuring a productive environment, especially in an offshore software development setting, requires constant communication. It’s the key to moving the project toward delivery. Frequent communication eliminates the “black box” businesses often find when the offshore team implements their own processes and they have no visual into them. Using an online collaboration tool like Spotlight can provide the needed visibility into the project and team through its social media based communication platform.

Processes also need to be implemented for dealing with uncertainties, how issues are handled, and many more factors. Having a process that the offshore team can follow for almost any scenario will create a high quality software development process.

Conclusion

With careful planning and preparation, using an offshore software development strategy can result in that quality product a business looks for at the end of the project. But quality service and development isn’t all about the written code, it’s engrained into a process that starts at day one.

Now it’s your turn, so let’s hear some great success stories about your business offshoring a software project. How did you manage that process? And if you are having trouble with a current software project or team, try a 30-day free trial of Spotlight to get your team and project back on track.

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.)

For more information on Spotlight Software and Spotlight People & Project Manager, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.


5 Ways to Reduce Software Development Costs

Posted by: Seth Weedin

Reducing Software Development CostsSoftware development is now a necessary part of starting and running a business, especially with the explosion of the Internet. Businesses cannot hardly survive without a presence on the web, whether it’s a website, SaaS, or mobile application. It can be very expensive but with proper planning and strategy, software development costs don’t have to break the bank.

Several of the cost-saving techniques for software development come before the project even starts. Most successful software projects start with a plan that serves as a roadmap for developers to follow. This strategy will cut down on the time to reach the project goals and save your business money in the end.

Here we discuss five ways that can you can cut software development costs and deliver projects under budget. Use this process enough and eventually it will become second nature to your team, helping get projects started and off the ground faster.

Consider Outsourcing

This is the traditional “make-or-buy” decision. Hiring in-house developers to “make” your software will include employee salaries and overhead costs. Outsourcing on the other hand, gives you the opportunity to find talent worldwide often much cheaper than locally. Freelance websites like Freelancer and oDesk give businesses an excellent opportunity to find this type of talent quickly. The hiring process of full-time employees is often lengthy and expensive and once the project is over, you have to find something for them to do. Hiring a quality freelance or outsourced team can happen in a matter of days and once the project is over, payments are made and everyone goes on their happy way.

Although outsourcing offers a low cost alternative to in-house software development, still take the time to choose carefully. Don’t always go for the cheapest proposal that looks like it will deliver all the project requirements. Give them a smaller test project first (no longer than a couple days) to get an idea of their skillset and how they work with your team. One size does not fit all in this situation.

Start With Requirements Analysis

Requirements analysis will prevent you from having to go back and constantly revamp work that is already done. Whether you are developing software for your own business or a customer, sit down and hash out a detailed requirements analysis plan to guide the entire team. This ensures the project team and stakeholders are all on the same page of what the software will look like at different increments through the project. Use both graphical and textual content to develop a product roadmap so everyone fully understands what is being developed.

Nothing increases software development costs faster then rework. This will likely delay the release making the customer, development team, and project stakeholders all very unhappy. Using a well laid out requirements analysis will lessen the chance this happens.

Use Agile

Agile software development consists of iterative approach where the requirements for the application are developed in a step-by-step manner with the project stakeholders. New releases take place in short, fixed time periods allowing the stakeholders to review the progress before approving and moving on to the next phase or “sprint”.

Using Agile can cut software development costs significantly as it drastically minimizes any rework that has to be done. Working in short increments with a review at the end allows the client or product manager to set priorities for what functionality is really needed for the next release. This does two things: First, it makes any rework easier because the development team only has to go back through the previous iteration and second, more emphasis is placed on the core functionality of the application instead of adding the unnecessary but cool new features. We like to call this “feature creep”.

The traditional waterfall approach that is typically used in lieu of Agile means the whole application is developed and then reviewed at the very end. If it’s not up to the client’s standards or major requirements are missed, the whole project fails.

Test Early and Often

Quality assurance testing can begin immediately upon the requirements being drawn up. This allows them to start creating the user acceptance scripts that will be used later on when testing gets complex. Getting them involved early also allows them to lend their expertise and experience on whether the software requirements are fully testable and make sense. This prevents confusion later on, which can slow down a project and increase cost.

Experienced QA testers usually have an ability to really see things from the user’s point of view. This doesn’t always happen from the development or management side of things. This perspective from the user side can reduce the number of issues that come up when your real customers start using the app.

Reduce Manual Processes

Tasks done manually are open to human error and just waste time and money. Don’t reinvent the wheel by trying to create this stuff, find tools already out there that automate these processes. For example, keeping track of your own work hours by hand can be difficult, let alone for 5 other team members. We automate this entire process in Spotlight PPM, where time spent working on our development tasks is automatically tracked by the system. This allows project managers or management to easily print reports showing how many hours our development team worked for accounting purposes.

Automation of tasks also ensures accuracy and reduces the margin of error. The risk of human error opens the door to incorrect information that may be used to make decisions on the future of the project. And as we know, the wrong decisions during a software project or any type for that matter can end up costing a boatload.

Conclusion

As a startup or small business trying to make ends meet, these areas offer great opportunity to cut down on software development costs. Just try not to sacrifice quality to get the lowest price possible. Hiring the cheapest resource available to build your software will often end up costing you more money in the end with dissatisfied stakeholders and rework.

What other techniques have you used to cut costs without sacrificing project quality? Leave a comment and share your experiences, we would love to hear from you!

For more information on Spotlight Software and Spotlight People & Project Manager, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Author Profile
Seth Weedin (seth.weedin@spotlightppm.com) is the Director of Marketing at Spotlight Software.


The Minimum Viable Product: When is it Marketable?

Posted by: Seth Weedin

Minimum Viable Product

Build Your MVP in Steps

“Lean startup” is a popular phrase in today’s entrepreneurial world and for good reason: it works.  The official definition to the lean startup methodology from Eric Ries is “to provide a scientific approach to creating and managing startups and get a desired product to customers’ hands faster.” This process involves developing a minimum viable product, or “a version of a new product which allows a team to collect the maximum amount of validated learning about customers”.

So a minimum viable product (MVP) is a way to get your product into the hands of users faster and use their feedback to continuously innovate. There is no better validation on whether your product has legs than honest feedback from your target market. They will be brutally honest. The key is to make sure you listen, as they will stop you from wasting money on developing a product that sucks in the first place.

When we were in the process of developing our MVP for Spotlight People & Project Manager, we took a two-phase approach. First there was the MVP phase, which we used to gather beta users and early adopters for thorough feedback. We used the feedback to continuously iterate and add functionality. Then there was the minimum marketable product (MMP) phase, which is a period where the product is out of beta and can be marketed to new customers. You will still be iterating and using customer feedback, but this product can have more marketing dollars pumped into it. Some people use these terms interchangeably but we separated it into two phases.

It’s often difficult to judge when the time is right to release a MVP and then MMP. Here we look at each one and some differences to help you in the process of building your lean startup.

Minimum Viable Product

The MVP is initially used to validate your product idea with customers. Here we look at three key areas that can help you determine if it’s worth moving forward with your product.

  • Value – Does your minimum product provide enough value that people are willing to use it? If you have a hard time attracting traffic to your product’s website through a smoke test PPC campaign, it’s obvious something needs to change. Or maybe the idea just isn’t going to perk much interest, ever. On the other hand, if you receive good traffic and a number of signups for early beta testers, chance are you’re on the right track. This initial user feedback will give you the information needed to determine if it’s worth spending the capital to move the product forward.
  • Future Benefit – As you move through the early MVP phase, you’ll get an idea of whether early adopters are actually using the product and coming back for more. Do they believe your product shows enough future benefit to keep using it? Users should be able to see the potential of your product with an MVP even if the functionality isn’t there yet.
  • Feedback– Feedback from beta users and early adopters is a two way street. You provide them some incentive, such as free use of the app right away and possibly in the future, for their feedback and suggestions. This will help guide your future development goals beyond the MVP. Instead of throwing in features that your team thinks would be beneficial (often called ‘feature creep’), use the data at hand from those using it everyday in real business situations. If the early adopters have suggestions for improvement, it will likely benefit your entire target market as a useful addition for the future. If they have no feedback at all, it’s probably time to reevaluate your product.

It’s important that early users can identify the vision and promise of the final product through the MVP. If they can’t see it or don’t think it’s worthwhile, gathering feedback and data will be tough.

Minimum Marketable Product

As previously mentioned, we separated our development roadmap into two phases, the second being the MMP. As our application evolved through the MVP phase, we asked ourselves, when is it ready to be released to the masses? Now that you’ve verified the idea with the MVP and people are getting value out of it, how do you know when the product is ready to turn on the marketing funnel? Here are three areas of your product to consider that help with this decision.

  • Reliability – The MVP phase is used to work out a lot of major bugs and server issues in your software product. While your beta testers will be understanding of outages or business crippling issues in the early phase, regular customers will not. Ensure your product is 100% free of any show stopping bugs that will deem it unusable. When you release a MMP to the world, people are going to rely on your product when they sign up, whether it’s for business or pleasure. Don’t release a product that is going to frustrate them with reliability issues.
  • Scalability – Ensure whatever platform you’re product is hosted on is fully scalable for a flood of new users. While most new startups won’t get overwhelmed with new users as soon as the MMP is released, scalability needs to be something that is worked out during the MVP. There is always that chance your product catches on quickly and the signups start rolling in. Make sure the traffic can be handled before releasing your MMP.
  • Performance – Nothing is slow these days in the world of technology. If it is slow, people don’t use it and definitely won’t pay for it. Test the performance of your product every which way before releasing an MMP. Studies show that 250 milliseconds can make the difference between someone visiting your website or a competitor’s. Chances are there will be multiple users hitting the system at once and any delay in response, even seconds, will frustrate them. Nothing good comes from frustrated users as soon as you release your product.

While there are several more things to consider before releasing your product to the entire market, these are three vital ones. You want to be prepared for anything when moving out of your MVP and into a marketable product release. While you will continue to iterate your product with new features, updates, and improvements, an MMP can be released when you’re prepared for the unexpected.

No matter if you are building a MVP or ready to release a MMP to your target market, the key to all of this is building a product that solves a problem. If it doesn’t solve some type of problem, people or businesses won’t use it. Starting with a MVP and morphing that into a MMP after honest user feedback will give you the best chance of success. Determining the timeline for MVP and MMP releases can be difficult but trust your judgment. And surround yourself with people who have done it before.

Has your business developed a product using a minimum viable product and minimum marketable product? Or do you combine them into one? Leave us a comment and share your experience.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.


The Who, What, and Why of Project Goals

Project Goals DefinitionUser stories, also sometimes referred to as project goals, help stakeholders track major deliverables throughout the duration of a software development project.  The stories describe the desired user interaction with a specific feature of a software application. Building an eCommerce system would be an example of a user story that describes the process someone goes through to actually purchase an item or service.

We recently introduced project goals (or user stories) into Spotlight PPM for easy tracking of major software project deliverables. Clients, upper management, and outside stakeholders can use these goals to track certain parts of a project that directly involve them. For example, the CFO of your company may want to track the progress of the eCommerce system implementation mentioned above.

So exactly what does a project goal or user story entail? They commonly use this format: As a (who), I want (what), so that (why). Let’s take a look at each part of the equation in who, what, and why from various user and role perspectives.

WHO

There are several types of users that can make up the WHO portion of the user story equation. While end-users are the obvious WHO, others include project stakeholders and product owners.

Project stakeholders want an easy way to include new feature ideas on the product backlog. They usually don’t need to provide specific details of the story yet but just want a placeholder for further discussion. This gives the project team a heads up of new features coming down the pipe.

End users provide the basis for a user story in how they will interact with a new feature or improvement. Development teams that can gather this information from end users have a basis for the features that were originally outlined in the requirements analysis, making them easier to understand. The end user also provides data for consideration of new features that will make an application more user-friendly and robust.

The Project Manager and Product Owner both utilize user stories when creating the project backlog. The stories are much easier to prioritize without all the details of tasks getting in the way initially. The development team can then use a story to decide what tasks are needed to make it a reality.

WHAT

Using the format above of “As a (Who), I want (What), so that (Why)”, the WHAT portion of user stories explain how users expect the software or system to behave. Using our example of an eCommerce system above, users will typically want the system to keep track of all the items added to the cart and check them out via a secure processing method at the end.

This portion of the user story equation typically outlines a feature or action the user wants to happen. Usually this will be a new behavior in the system, such as order tracking or integrating with PayPal for another payment method.

WHY

The WHY portion of user stories explain why a user, role, or system wants to be able to perform the desired interaction with the software. Going back to our eCommerce system example, a company would want the ability to cancel customer orders if requested, so the customer is satisfied and will potentially come back later for a repeat purchase. Keeping the customer satisfied to leave the door open for a purchase in the future is the WHY part of a user story.

Another aspect of the WHY portion are the reasons for product owners, project managers, and the development team to actually use user stories. For product owners and project managers, user stories make the backlog easier to manage. Since they are only an overview to describe what interaction is to take place between a user and the application, they are easier to organize and also let the development team know what’s lies ahead.

User stories also encourage communication and collaboration between different parts of the team to brainstorm what functionality is needed to implement the story. As the project team and stakeholders work together to achieve this, everyone gets in sync with each other to create a highly productive work environment.

Because user stories provide an overview of a user’s path through a new software application, it helps ensure that important requirements are not missed. Addressing the requirements in a group of user stories lays the groundwork for the development course, where detailed tasks can be added later. Trying to identify these detailed tasks immediately runs the risk of some requirements getting missed.

Conclusion

Quality user stories and project goals justify the reason for a new feature or improvement. They help project stakeholders keep track of the project’s progress and let development teams know what’s coming in the future. The stories can be added to the backlog almost immediately and serve as a placeholder for the future enhancements that satisfy the requirements. Think of it as the forest, with the trees being detailed tasks to implement the new story.

Project Goals in Spotlight use the typical format of having a product owner and all the specific tasks needed to create the user story feature as shown below. Oftentimes, we create new goals well ahead of time with no specific tasks yet for a placeholder as discussed previously.

Spotlight's User Stories and Project Goals

Is your software development department using user stories for new features? Leave us a comment with your experience.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.


How Spotlight Embraces Continuous Deployment

Continuous DeploymentA 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.

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.


3 Tips for Successful Software Testing in Agile

Software Testing for BugsMaking the transition from the waterfall approach to Agile software development can be an involved process. Documentation has to be updated, project team members trained, and new roles defined to accommodate the change. The transition is well worth it though, with Agile offering faster delivery times, higher quality software, and improvement on project ROI.

Businesses have to make this transition carefully. Several new processes have to be implemented and sometimes things tend to get overlooked. Software testing is often a process that falls victim to this.

Bug tracking and QA require a major change when moving from waterfall to Agile. What used to be a process of testing at the end of development with waterfall has morphed into constant testing throughout the duration of the project. For traditional testers used to waterfall, this is an entirely new way of thinking.

But some nurturing of the traditional QA process can make it very successful in Agile. Here are a few tips to help make the transition smooth for software testing procedures in an Agile project.

Involve Everyone

In Agile, everyone on the team—from tester to developer to product manager—needs to be aware of quality throughout the development process. Making software testing part of the daily workflow can lead to faster discovery and remediation of defects. This will help reduce time, effort, and cost in the QA process.

While the tester is in charge and ultimately responsible for the QA process, it never hurts to have another set of eyes looking at the product. During our sprints, our entire development team is keeping an eye out for bugs and reporting them directly to the lead QA tester. Our lead then enters any bugs found directly into the Agile task management system for developer follow-up. It’s a process that is quick and efficient.

Early and Often

In Agile projects, development takes place in small iterations, or sprints, that always end with a functional release. As a result, software testing has to take place early and often in the project. This doesn’t just mean testing the app for bugs, but includes unit tests, functional tests, load and stress tests with every sprint beginning right away.

During development, some changes or updates in the next sprint may require going back and testing something again. But consistent testing, even if it requires some repeat, will ensure earlier detection of issues that could otherwise stall the entire project. We have our QA leads create test scripts as they go through the application. This ensures that anyone else who comes aboard knows exactly what process to go through when software testing, saving a lot of time.

(Over)communicate

Consistent communication back and forth between QA and the development team ensures little bugs don’t turn into project-halting rework. Create an open communication environment by encouraging constant status updates from QA to development on testing progress. A tactic we also use is to include all QA team members in our daily scrum meetings. This keeps them apprised on all tasks the development team is working on so they know what to expect in the coming days. Not only will this help find defects quicker, but also improve teamwork that can often speed up overall project delivery.

Oftentimes, a project management tool for software projects can help manage QA tasks and improve communication among the team to make sure nothing gets overlooked. Spotlight does this by allowing the team to collaborate on a centralized dashboard using social network-like communication tools.

Conclusion

Software testing can be very successful in an Agile setting and actually much more effective than with traditional waterfall. Defects can be found quicker and remedied sooner, propelling the project to a faster completion. Involving QA testers in the entire project results in a new level of teamwork that can move software projects through the development life cycle much quicker. Additionally, increased and improved teamwork just makes everyone’s job more enjoyable.

Obviously we believe software testing is a very important part of successfully delivering a software project. This is why we decided to implement the functionality for our next release with the new Bug Tracking & QA Flags feature. Join us for a webinar on Wednesday, April 17th at 10 am Pacific (1 Eastern) to get a first look at the new feature before official release!

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Author Profile
Seth Weedin (seth.weedin@spotlightppm.com) is the Director of Marketing at Spotlight Software.


Using Agile to Reduce Software Project Risks

Risky BehaviorDevelopment 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.

Timeline Estimation

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.

Conclusion

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!

For more information on Spotlight Software and our services, please contact us or visit our FacebookGoogle+LinkedIn, or Twitter profiles.

Author Profile
Seth Weedin (seth.weedin@spotlightppm.com) is the Director of Marketing at Spotlight Software.


3 Signs Your Software Project May Fail

Every software development team’s goal is to complete their project within the time and budget determined in the planning stage. But not all projects go as planned. Knowing when to cut your losses and scrap a software project will allow you to put those resources towards one that is going to generate a return.

The statistics on the percentages and cost of software projects that fail are quite staggering. According to Galorath Incorporated, most studies quantify the dollar amount of software project failures to be in the $50 to $80 billion range. MSM Software recently interviewed 200 senior IT professionals and found that over half have been involved in a project that failed, as shown in the graphic below.

Software Project Failure

A software project failure is probably going to happen eventually throughout the life of a business. Being able to quickly identify the signs of a doomed project can save both money and time, as well as provide a great learning experience. While businesses obviously don’t want project failures, it can be compared with failing at a new business as an entrepreneur. It ends up being a valuable learning experience where you come back stronger the second time around.

So what are the signs of a software project that may be going backwards? Codesqueeze lists 101 of them but we’ll cover 3 of the more common signs.

Project requirements confusion

If your development team is still confused on the requirements of a project a few sprints in, then you may have an issue. This often can lead to having to start over or go back and constantly change things that weren’t clearly understood from the beginning.

When a software project is brought to the table, a thorough requirements analysis should take place and be discussed until everyone has a full understanding. Ensure that everyone on the team has ample opportunity to speak up when they don’t quite get it. Some people will be more hesitant than others.

Requirements analysis are sometimes difficult. Being able to decipher a client’s vision for their software and estimate what it will take is usually a matter of experience. When we have a new client sign up for Spotlight and ask for our consulting services to help plan their project, we’ll have our CEO and most senior level developer make the estimates. This ensures they get started on the right foot towards a successful project delivery.

Lack of interest

All software projects require active participation, feedback, and cooperation to be successful. If team members start showing a lack of interest, it may be because they don’t think the project is going to succeed. We all know what one bad apple can do to a team let alone multiple ones that lose interest in achieving its goals. They can bring productivity and morale down quite quickly to the point the project may be halted.

Constant interaction and teamwork throughout the day can keep team members interested and motivated to make the project successful. Spotlight’s social network like dashboard allows our team members to constantly interact on tasks and work together on issues. This helps keep them invested in the project and gives them a sense of security by knowing they can quickly seek assistance if needed. They stay interested in the team and project.

Poor communication

Communication can make or break a software project, especially if you aren’t all working in the same office. If things are starting to pop up in review meetings or daily scrums that are a surprise to everyone, then you have a problem.

In fact, communication can often be pegged as the number one cause of project failure. Project tasks are usually dependent on each other, so without communication between the people working those tasks, there is bound to be lots of confusion.

That’s just one aspect of it within a software project. Communication between outside stakeholders and the project team is another situation altogether.

The thing that makes poor communication so hard to stomach is that it can be avoided. Staying in touch during the day on task progress, availability, and problems encountered keeps everyone updated and can quickly bring light to any issues that need to be addressed immediately. A tool like Spotlight’s status update control can be used to quickly communicate your current status, availability, and what tasks you are working on. This keeps project stakeholders and everyone on the team current on the project’s progress and where potential bottlenecks could form.

And Finally…Failure Doesn’t Have to Happen

We’ve taken a look at a few warning signs that your project may be on a downhill slide. But rest assured, noticing these signs does not guarantee failure. Every project has peaks and valleys. The key is to recognize when the signs point towards failure and take action to prevent them from snowballing.

Have an experience in a software project that didn’t go as planned? Leave us a comment!

For more information on Spotlight Software and our services, please contact us or visit our Facebook, Google+, LinkedIn, or Twitter profiles.

Author Profile
Seth Weedin (seth.weedin@spotlightppm.com) is the Director of Marketing at Spotlight Software.