Posted by: Seth Weedin

Earlier this week, we posted an article discussing the minimum viable product (MVP) and how to turn it into something that is ready for your entire target market. Here at Spotlight, we took a two-phase approach in developing our people and project manager app, starting with the MVP and finally releasing to the masses with our minimum marketable product.

Lean startups vary in several ways in how they approach the release of a new software or mobile product. One size doesn’t fit all and any of these variations can work. The important thing is to remember the underlying concept of the MVP process from Eric Ries: to provide a scientific approach to creating and managing startups and get a desired product to customers’ hands faster. The end goal is the same; get your product in the end user’s hands faster, get feedback on how the development of the product should unfold moving forward.

We piggyback off this theme for today’s Friday Findings to share other expert perspectives on how to manage the MVP process. It can often make or break your business.

The Findings

• Not exactly sure what is entailed when creating an MVP for your new business? This article answers 4 common questions about the process.

• Here’s how one company developed four MVP’s in less than a year to get it right. Sometimes to get the right fit, you have to throw everything out and start over.

• If you are just starting to think about developing a new product and wondering about cost, Forbes looks at four methods of MVP development and what to expect for spending.

• Here’s the entire MVP process from initial development to customer feedback and iterations mapped out in a informative infographic.

• How will your idea resonate with the early customers? Steve Blank discusses the best ways to find out if your MVP is worth it or not.

• Sometimes MVP’s are released that are absolutely dreadful to work with. Here’s how to turn your product into something users enjoy and make it ‘delightful’.

• Some great lessons learned from the AppBot mobile app creators when the launched their MVP.

• This is a very short, fun take on Apple’s MVP from Andrew Chen. Remember, your MVP doesn’t have to be lightning in a bottle right away.

• See how to actually implement a MVP from a more technical standpoint in this article from GROU.PS Chief Architect, Emre Sokullu.

• No discussion on the MVP process would be complete without wisdom from Eric Ries. Use this article and video as your ultimate guide to releasing your first product.

The trick is finding a MVP development process that fits your business and potential end users. But the overall concept of developing the MVP and getting it in the hands of your users will save you money, time, and sanity.

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

Posted by: Seth Weedin

“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 Facebook, Google+, LinkedIn, or Twitter profiles.

Posted By: Seth Weedin

Recently, a new approach to managing project teams has emerged combining traditional project management techniques with social network principles. Social networks allow project teams to communicate and collaborate on demand and in real-time, leading to a new management method called “Social Project Management”.

At Spotlight, we found the value of using social networks to keep our project teams communicating frequently during a project, especially since our entire company is virtual. But instead of using each social network individually, we integrated these social media principles right into our people and project manager app. Now development teams all over the world can stay in contact through the integrated social media features and project management techniques from their computer, mobile, or tablet device.

We aren’t the only ones jumping on the social project management trend. Thomas Kennedy, founder of www.PmBookClub.com is currently holding a business study on Elizabeth Harrin’s book Social Media for Project Managers. They go through the entire book in a study outline to help you take advantage of social media for project team collaboration.

In this week’s Friday Findings, we look at how social project management is being used for project teams to help them communicate better.

The Findings

• PMHut discusses how to balance coordination and management when using social project management principles.

• This article looks at how social tools are used in project management. One major advantage? It cuts down on emails.

• Here are 10 ways to integrate social media with project management. Using these types of tools can keep your project team communicating all day.

• Social media can be used in different pieces of the entire project management methodology. This article looks at how you can use social media to enhance project planning.

• A look at social media’s place in social project management. A good reminder in this article not to forget about security when communicating across social mediums.

• Integrating social media principles into project management can be quite a change for traditional project teams. Here are some tips for integrating social into your project management methods.

• If your business is thinking about moving towards the social project management ideal, here are 10 considerations to think about when making the transition.

• This article looks at where social media meets project management and how it can make your software project team better aligned.

• Social project management works best when a good balance is found between the social media tools and traditional project techniques. Here’s some keys to balancing the two and using social media to improve collaboration in “extended” project teams that comprise all stakeholders.

• Here’s a great article from MindJet with a look at social task management to help conquer time, budge, and scope challenges.

As you can see, social project management is a trend that is gaining popularity. Spotlight integrates social principles into all aspects of our people and project manager app to help keep our software teams on the same page. If you are interested in seeing Spotlight PPM’s social integration live, join our webinar next Wednesday, May 22^nd.

Has your business integrated any social media methods into project management? Let us know how it’s going!

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

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

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 Facebook, Google+, LinkedIn, or Twitter profiles.

Project managers have all heard those dreaded words coming from upper management: “Have a project report on my desk by tomorrow.” While they definitely aren’t the most enjoyable aspect of being in software project management, they are imperative.

To help you be better prepared the next time your boss comes by your desk and drops that phrase, here are 10 articles to help you create reports faster while maintaining quality.

The Findings

• Creating weekly status reports for a software project keeps stakeholders and the project team on the same page. But don’t confuse it with a daily scrum report.

• These tips on creating a project report from front to back will the management team informed and happy. Great take from a manager’s perspective.

• Ensure your project reports are clear and show accountability to your managers. The faster they can read and understand them, the better.

• This article from Tech Republic describes some great project reporting methods for Agile software projects. Specifically, four reports are used after every Scrum iteration.

• Communicating the status of an Agile project report to upper management can be a challenge. This slideshare presentation helps you bridge the gap when giving status reports.

• This article takes a look at how to keep a project report simple so everyone can benefit from it.

• When your boss or project sponsor walks up to your desk and asks for a project report on the fly, make sure to have these 5 essentials ready to go.

• Project reports can come in two different forms: from the PM to upper management and from the project team to the PM. Learn how to utilize both types of reports.

• A project report can be used for things other than keeping stakeholders apprised of its progress. It can also be used to gauge a project manager and their team.

• Another article from BrightHubPM showing you how to keep your project stakeholders informed without the traditional status report. Try keeping them engaged with a weekly newsletter.

Spotlight PPM automatically generates project status reports on demand. These reports include everything from a breakdown of sprints and tasks to billable hours by team member. Check out our webinar next Wednesday, May 15^th to see how Spotlight can generate the project reports you need to keep upper management informed and pleased.

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.

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.

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

Daily standups in Agile software projects are a way for a team to connect with each other on a current Sprint’s goals and issues. It’s an opportunity to get organized, collaborate, and engage with each other on the agenda for the day.

Next week we are offering a webinar on daily standups and reporting with a demonstration on how Spotlight actually automates a part of the daily scrum process. So this week, our Friday Findings offer a number of resources to make your daily standups more effective, engaging, and overall more valuable.

The Findings

• TechWell offers a helpful guide to conducting daily standups and how to resolve common issues that pop up. There are also tips for the distributed Scrum, which we use everyday.

• Sometimes daily standup meetings get stuck in a routine that loses team members attention to a certain extent. Try adding some variation to the daily standup with new questions or format to keep it engaging.

• A Q & A session from an expert panel on improving the daily standup for the distributed team. Time, technology, and even personalities all play a role.

• Here’s a unique and fun way to keep your meetings less than 15 minutes while keeping your team on their toes.

• Daily standups generally consist of the Scrum Manager and project team. But it may be beneficial to include the Product Owner from time to time.

• Answering the 3 typical questions in a scrum meeting sometimes goes from a detailed response to barely an answer for the last question. Here are some tips to effectively answering all 3 questions.

• This article is an excerpt from the book A Practical Guide to Distributed Scrum and discusses how to handle some of the challenges encountered with distributed scrum teams and meetings.

• Avoid these common mistakes when conducting standup meetings during your software project. One major tip: hold a standup everyday no matter what the make up of your team is.

• Base 36 offers 11 great tips for running effective standup meetings. Make sure they are short, on target, and collaborative.

• We all know one of the main reasons of having a daily standup meeting is to answer what you did yesterday, what you’ll do today, and any issues. But here are 10 other reasons for the meeting you may not have thought of.

Effective daily standup meetings during a software project can greatly enhance team communication and collaboration. This, in turn, leads to quicker identification of potential issues, code that may require some paired programming, and mutual understanding of goals. Be sure to stop in for our webinar next Wednesday to learn more about the daily standup meeting and how Spotlight improves the process for your team.

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.

This week features a guest post from Soneeka Jaiswal, who came together with Spotlight Software through Elance as a content specialist. She describes Spotlight and it’s social project management features from the viewpoint of an Elancer working from the other side of the world.

I was first introduced to Spotlight to do its user guide. And here I was browsing through this social project management tool to write the first-hand account of how to start in software management using this application. Let me share my experience and impression of Spotlight with you.

What is Spotlight and Social Project Management?

Like any other socially active person, I can say I’m an avid user of social media sites. The basic benefits or say interesting points I see in social media sites is effective communication and virtually staying connected with each other through status messages and comments. Why I’m mentioning social media while writing about Spotlight is the fact that the main quotient of this application is to stay connected the same way, but in an official group – a software project team.

Spotlight is unique for combining the social project management benefits to Agile software development methodology. The application is also available as a web and mobile app for access anywhere, at any time, and from any device.

Who can use Spotlight?

This product has been designed for associates of software companies working for small or medium projects. The major highlight is that these associates are virtual users sitting at different parts of the world and still working together. Spotlight’s goal is to make a virtual team project a great success by maintaining communication and hence collaboration between their members using social project management.

How to use Spotlight

Communicating and Planning

These different members are grouped together in Spotlight by creating a project. When a project is created, you have different hierarchies such as Project Manager, Lead, Developers, and Testers, etc. Their roles can be defined further, as to who can delegate tasks, view client reports, change accounts, department settings, etc. The project can then be framed as sprints and tasks based on the Agile development methodology, which can be tied to each team member’s task sheet.

Now, how these people stay connected is the most interesting feature of this product and contributes to its social project management ideal. A Status Update Control in each member’s profile enables them to update their current status on the task assigned to them. One can either update the status proactively or when requested by other project members or leads. This is broadcasted to everyone in the group as soon as it is updated. The task bar shows the progress made in the task from which the estimated/actual hours can be made out.  The other members can leave a comment on a member’s status and thus initiate further communication if required.

Imagine how comfortable it becomes not bugging a resource by email or phone every time you want to know the progress of a task. In turn, if you look at it from a team member’s perspective, it becomes valiant to know where and what your boss has been doing instead of thinking “Gosh is he passing the entire buck to me?!!!!”

When communication is the key focus, how can one forget about team member status and availability? So, as rightly expected, Spotlight has this online availability window, showing when and until ‘What time’ the team member is available/not available.

A detailed look can also show what other tasks are in the pipeline for the member. So, knowing the status and upcoming tasks, one can easily judge the team’s progress and project timeliness. Knowing this status allows the manager to plan ahead of time.

So, what I could find while browsing Spotlight was that it is a highly interactive, interesting and informative application. Without having to consolidate updates, one can identify the team’s and in turn the project’s progress.

For Software development and Reporting

So, until now I found all the ingredients for a great management tool. Where is this Agile methodology applicable? Agile Software development methodology is the biggest success in software project management as of date. What it means in layman’s term is that it involves all the stakeholders from the start, divides the entire project into incremental stages called sprints, finds the priority of the tasks and allocates them accordingly. At the end of each day, manager’s get the status report as to what has been done, what is the immediate plan moving forward, and impediments if any.

Now, the most common practice currently is to maintain a spreadsheet wherein an account of all the tasks are created and consolidated. But spotlight has replaced this requirement and offers a innovative way to successfully delivery Agile software projects.

Hence, I see that Spotlight is using social project management principles to make software projects highly interactive, interesting. This in turn, builds a highly productive team environment capable of making a software project a great success!

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

Effective team communication and collaboration is key to project success in software development. A software project is constantly changing, new tasks are being introduced, and requirements are altered. Communication between all team members, from developers to QA, is vital to keep the project on track for delivery.

Our new weekly webinar series starting next Wednesday, April 24^th highlights how effective team communication is accomplished using Spotlight. The team dashboard and status updates keep the project team in sync and moving in unison towards delivery.

Aligning with our webinar, this week’s Friday Findings features tips and tricks for achieving quality team communication and collaboration.

The Findings

• One of the fundamental values of Agile Management is communication. This paper from Agile Modeling looks at achieving effective team communication in an Agile project.

• Gina Abudi of Abudi Consulting Group discusses using effective communication as a best practice to increase the success of a virtual project team. Here she offers tips on building a communication plan when first starting a software project with a virtual team.

• The PMI Institute looks at communication between the client and project team during a technology or software project. Having open dialogue that clearly communicates the goals of the project to the project team helps deliver a successful product.

• Kelly Project Solutions offers 6 tips for effective project team communication. They stress the importance of communication across all levels, from executives to the project team.

• SmartBear discusses 10 reasons development teams don’t communicate. Learn how to deal with each one to make your software project team more effective.

• Small business computing looks at ways to effectively use social media to improve project team communication. Managing projects in Spotlight allows you to communicate using the social network tools you are already used to, integrated right in the app.

• eHow Money gives us 5 tips on achieving successful communication in a software project. Having an environment that encourages open team communication keeps project team members on the same page.

• Another good article from the PMI Institute provides 6 tips to improve communication in distributed Agile teams. Agile teams that are distributed are becoming more popular, especially with software projects, and these tips can make your project successful.

• This article from Agile Buddha looks at the main challenges that surface with distributed Agile teams and how to solve them. Addressing the people on the team and the communication challenges will help you successfully deliver a software project driven by a distributed team.

• Serena Software conducted a survey that showed while the Agile methodology is working well for software projects, communication is the biggest challenge. Check out the infographic showing the state of communication in Agile projects.

Communication between project team members is a big determinant of a successful project, whether in software development or another industry. Come join us next Wednesday, April 24^th for a short webinar featuring our social network communication platform in Spotlight. Learn some great strategies and tactics for using effective communication to your advantage in delivering a successful software project.

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.

Making 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 17^th 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 Facebook, Google+, LinkedIn, or Twitter profiles.

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