5 Stakeholder Questions To Ask Before Starting the Software Development Process

Software development is an intricate process that requires skill, planning and team effort. There are several stakeholders involved in the project, from company executives to various departments within the company.

It isn’t possible to satisfy all of them completely, but you can take their concerns into account before working on the project by asking the right questions. Doing so can help you understand their priorities and plan the development process accordingly. Here’s a list of 5 questions to ask before starting a software development process:

  1. What is the Product?

Projects tend to get out of hand if you don’t have a clear vision in mind. Software developers need to understand what the end product should look like before they even start planning for it. For example, does the company want an app that will help users find the best online deals? Does it want a software program for its HR department?

Stakeholders can provide a list of features or ideas for the end product to make things easier for a development team. If there’s any dispute about the final product, this will be the best time to resolve it. Make sure everyone is on the same page before proceeding.

  1. What is Not a Part of the Product?

Developers can sometimes go overboard and add features or elements that aren’t necessary. That happens if they don’t know what should be excluded from the final product. For example, if a website is only delivering to the US, there’s no need to include a feature to convert prices to other currencies. In many cases, stakeholders assume their development team is going to deliver something, but the latter is unaware of it. It is essential to establish what you will and won’t deliver.

  1. What is a Successful Product?

Software programs are tools designed to achieve a specific goal or purpose. A company creates a website if they want to establish a presence online. They design an app if they want to build a robust and long-term customer base. They develop a software application to make daily processes easier. If the product fulfills these goals, it is considered successful.

The end goal isn’t to deliver a good product; it is to provide a product that succeeds in the market. There’s a clear difference between these two goals. For example, a website can be beautiful and functional but still not provide all the services the target audience needs. Stakeholders should define what a successful product means to them at the start of the project.

  1. Do We Have a Single Point of Communication?

This is one of the most challenging aspects of project management. The project starts with one team and one client, but eventually, a large number of people start becoming part of the process. The IT guy must approve one aspect of the design, the other should please the marketing expert, and so on.

If these people start offering suggestions or requesting changes, the project can quickly get out of control. It is crucial to establish a single point of communication between stakeholders, clients, and development teams. You can maintain a smooth flow of information while keeping track of numerous requests.

  1. What are the Potential Roadblocks or Problems?

No one likes to discuss problems before they work on a project, but you need to address it. Gather all stakeholders together and ask them about possible hurdles. Can the project run out of money? What happens if some temporary contractors don’t live up to expectations? What if the client changes their mind in the middle of the project? If you know about possible hurdles, you can develop systems to counteract them.

These questions will help a team start their project on a firm foundation. Don’t hesitate to ask questions to stakeholders; the answers will help improve the quality of your end product.

At Number8, our philosophy is to empower our clients to produce better software, faster. We are experts in augmenting scrum teams with senior consultants that can help increase team velocity immediately. If you’re interested in learning more about Number8 and what we do, give us a call at (502) 890-7665, or check out our information page.

 

The 12 Principles of the Agile Manifesto

The agile methodology started in the software development industry in response to the limitations of traditional software development principles. Eventually, companies realized that it could be used to improve project management, team management, and other such processes. Agile focuses more on individuals and interactions between different teams than processes or sophisticated tools. There are 12 core principles of the agile manifesto.

  1. Customer Satisfaction – Providing Early & Continuous Delivery

The Agile Manifesto states that developers and companies can achieve customer satisfaction by delivering products early for testing and feedback. Teams can continuously share their progress with the clients and incorporate their input into the product. The focus is on fulfilling client priorities and then focusing on other aspects of the project. This allows developers to adjust to the client’s changing requirements during the development process. Customers get a more refined product at the end of this process, and they’re more satisfied.

  1. Responding Positively to Change – Even During the Later Stages of Development

The modern business environment is fluid, and customer requirements change frequently. Traditional working models don’t adapt well to change, especially during the late stages. The agile methodology adapts to change quickly at every stage. Agile offers a simplified model for requesting and making alterations in the product design. There’s no formal documentation or approval required, which can speed things up.

  1. Frequent Delivery of Product Elements

Rather than forcing the clients to wait for several months, the development team can deliver the project in stages. You need to make sure every aspect is finished, tested, and styled appropriately. This gives customers quick fulfillment and offers assurance that their project is progressing as planned.

  1. Communication Between Developers & Executives

There’s often a communication gap between developers and executives. People who work on the project have more technical skills and knowledge about the product, while executives understand the business side of things. This can lead to miscommunication, delays, and other such issues. Agile requires everyone to be on the same page and maintain open communications.

  1. Trusting Developers & Teams to Do Their Job

Many executives don’t trust their workers to choose the right job, which results in micromanagement. Such micromanagement can hamper productivity and place unnecessary pressure on the team. Projects should be built around motivated and passionate professionals who understand their strengths. Self-organized teams are more efficient and content to work on every aspect of their projects.

  1. Face to Face Conversations

Essential instructions and project requirements can become lost in endless chain emails, which is why face-to-face communication is necessary. Executives should obtain feedback from the source and work with the team on the project. Virtual communications like video conferences can help in this process.

  1. Collocation & Pair Programming

Collocation is the process of making a team work from the same open area. Pair programming is when two programmers are assigned the same workstation. One programmer is writing the code while the other looks at the bigger picture. Both swap roles every few minutes. Both of these processes improve product quality and make teams more productive.

  1. Sustainable Development

No one can work continuously or at a demanding pace without experiencing some form of burnout. Agile methodologies focus on improving work-life balance and making sure everyone in the team is healthy. Product development is only sustainable if workers are allowed to get adequate rest.

  1. Self-Reflection to Improve Overall Performance

The agile manifesto is focused on the human aspect of development. The best designs come from teams who are committed, passionate, and happy to work. They also come from teams that are willing to look back at their past work and improve.

  1. Simplicity

The Pareto Principle says that you get 80% of the work done with 20% of the effort. Professionals should focus on the 20% and make sure that 80% of the work reaches the customer on a priority basis. You can then focus on the nitty-gritty and refine the project later.

  1. Self-Organizing Teams

Executives should give their teams some room to flex their creative muscles. The team has skilled employees who are experts in their field. Allowing them some independence will help product development and improve overall work culture.

  1. Adapting to Change

Agile means fluid and adaptive. You can only be agile if you’re willing to accept changing demands and requirements during a project. Everyone can plan for a perfect product, but you can only develop something substantial through trial and error. Adopting agile principles can help improve your team’s performance and productivity significantly.

At Number8, our philosophy is to empower our clients to produce better software, faster. We are experts in augmenting scrum teams with senior consultants that can help increase team velocity immediately. If you’re interested in learning more about Number8 and what we do, give us a call at (502) 890-7665, or check out our information page.

 

“Automated QA: Save time, use a web calendar handler!”

Number8’s very own Derick Arzu was recently published on Medium. Read the article on automated QA processes below.

Text boxes, check boxes, radio buttons, and other elements of forms are fairly simple to deal with when it comes to developing UI functional tests for a web application. But what happens when you want to write a test that verifies that the UI for a web calendar is working?

You are probably thinking that it can be easily achieved with a couple of clicks and validations, which is not only true but also the approach that led to the idea of a handler.

Before you discover how to make your automated QA team very happy, here are some reasons why writing a simple function or just a segment of code that deals with ONE specific calendar is not as scalable. Imagine you are a QA Developer at a company who is developing the websites for airlines A and B and your team is requested to create the automated test suites. Sounds quite easy, you will use the same code in both projects, nothing will need to be changed; until someone shows you the designs of the two web calendars each airline uses in their website.

Beginning with the obvious differences, airline A uses two windows while airline B uses only one; that surely represents a significant change in the code of that first approach. Another difference you might not have noticed is that airline B has a dropdown to change the year of the calendar, so that would mean a slight change in the method used to get the text of the displayed year. Those are two visual differences that will affect the way your bot interacts with the calendar and the DOM will surely surprise you with more.

Now that you are interested, the coding begins!

This handler was implemented in Node.js and uses WebdriverIO as the test framework that interacts with the browser.

You will find out that the framework has two functions ($ and $$) to fetch web elements. However, a hierarchy of classes will be created to manipulate elements, later on you will learn this is so that the handler can easily be able to cover many web calendar designs.

The main class is Element. Here is where, the method to obtain the fetch function is implemented, it has two parameters:

    1. selectorObject (required) which refers to an object with two properties; the first named selector , is a string that specifies the selector that will be used to fetch the element. The second is index, which is an integer that must be assigned to the object if the fetch result wants to be treated as a single element and not as an array of elements.
    2. additionalProperties (optional) is an object with any property that wants to be added to the fetch result. The subclasses of the hierarchy use this to manage how some data is obtained from the web elements, you will learn this later on.

Read More…

Q & A Best Practices

On top of delivering a project on time and within budget, developers must test for quality assurance upon completion to ensure stakeholders’ expectations have been met.

However, testing for quality after a product is built, usually results in far too little, too late. The agile model of software development encourages practicing quality assurance throughout every phase of the project. The agile way also prioritizes quality by making it the responsibility of every team member, not just the QA testers. As a result, the QA team coordinates efforts with the development team at each iteration, providing continuous testing.

Implementing a feedback loop is a fundamental step in the quality assurance process. In order to guarantee that the product meets all of the requirements (feature functionality, design, reliability, usability and efficiency), it can be helpful to enlist the perspectives of those with varying backgrounds. This can include those proficient in testing, business and or development.

Quality assurance testing can be both manual and automated. While both approaches are proficient at mitigating bugs, automated software testing is often more beneficial in that it is quicker and more effective at checking for code correctness. It’s important to remember that the goal of Q & A testing is to find faults within the software so that an error-free application can be delivered to the client.

The following are integral software testing methods when best practicing quality assurance:

Test Driven Development (TDD)

TDD works by building a project’s code around the QA tests. The programming team first designs and builds tests for functional code, and then creates code that will pass them. This development method helps everyone gain an understanding of the code’s purpose before development; guaranteeing the initial functionality of the code and effectively building in quality.

Behavior Driven Development (BDD)

Similar to TDD, in that the test is written before the code, BDD tests the behavior of an application under specific conditions. This is done with the end user in mind. As development progresses, BDD often proves to be more reliable than TDD. BDD is also written in English instead of code, allowing for a more streamlined feedback loop.

Acceptance Tests

Acceptance tests are simple pass or fail tests that check whether or not a feature behaves as it should. These are often automated to meet customer and business requirements.

Regression Tests

Once one feature is functional, regression tests ensure it’s stability throughout the software’s other modifications. As more features are built, these automated tests check that the others aren’t being negatively affected as a result.

Exploratory Tests

Exploratory tests are usually manual, in that a human operates the software looking for unknown unknowns. These tests are meant to identify new situations that the development or QA teams haven’t thought of.

Once a product thoroughly meet’s it’s intended purpose and performs well under pressure, the QA testing is complete.

At Number8, we believe in developing software that is user-friendly, reliable and completely functional. As a result, we are always recruiting talented QA professionals for quality assurance jobs on our team. To learn more about how we can help you complete and successfully launch your software project, contact us at 502-890-7665. 

10 Agile Project Management Terms You Should Know

Whether you’re planning on managing a project the agile way, or just want to stay up to date on the latest developments in the field, here are 10 agile project management terms you should know:

1. Agile Manifesto

The agile manifesto is a great starting point for anyone looking to familiarize themselves with the agile methodology. The manifesto outlines the 4 values and 12 principles of agile software development and was actually created by a group of software developers in an effort to provide a clear and alternative set of processes for developing software. The agile way of doing things prioritizes individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. 

2. Scrum

A scrum is a daily stand up meeting with the sole focus being to review each team member’s progress on any given project. Scrums help to keep everyone accountable and on the same page, ensuring no one falls too behind or gets too far ahead in the development of a project.

3. Scrum Master

A scrum master oversees the development process and acts as a problem solver for the team; preventing roadblocks and enforcing the agile way of doing things.

4. Stakeholder

A stakeholder refers to anyone with a vested interest in the product. This can be the client, the end user, sales people, legal representatives etc. Stakeholders have an informative role in the development phase, and are critical in defining the project’s requirements.

5. Backlog

The backlog is the ever changing list of the software’s requirements. It’s not to be seen as a to do list so much as a prioritized list of desired features of the product provided by the stakeholders.

6. Story

The story tells the software system’s requirements from the consumer’s point of view. For example, as “a <type of user>, I want to <perform some task> so I can <achieve some goal.>”

7. Burndown & Burnup Charts

A burndown chart visually measures the progress of a project over time (the vertical axis is made up of the backlog while the horizontal axis represents time). A burnup chart displays completed work (the vertical axis shows the amount done over the horizontal axis, time). These charts are essential to inspiring the team as they work and help provide a realistic time frame for the project’s completion as well as a working scale of the project.

8. Feature Creep

While changes are expected, and certainly embraced in the agile way of doing things, the phrase “feature creep” refers to features that are added after development has begun. Adding too many features during the development phase can result in feature creep and software that is too complicated or difficult to use.

9. Timeboxing

Timeboxing is kind of like time blocking in that it assigns a specific time frame to accomplish a goal. The definitive feature of timeboxing however, is that the work stops at the end of the timebox, instead of when the work is complete. This is extremely helpful in terms of productivity, and controlling the scale of a project.

10. Sprint

A sprint is a short development phase usually lasting anywhere from 1 week to a month. Sprints help prevent projects from feeling overwhelming and allows feedback to be given at appropriate junctures.

At Number8, we help project managers connect with highly trained and efficient IT support to help reach company goals. If you’re interested in learning more about Number8 and what we do, give us a call at(502) 890-7665, or check out our information page!

What to Look For In a Nearshore Development Partnership

More and more throughout the United States, development work for web-based companies is moving out of the country. The reason that a company decides to look for offshore or nearshore developers is different from situation to situation. Some reasons for looking into nearshore outsourcing can include budget restrictions preventing the company from expanding in-house or office spacing being too limited to hire additional in-house developers. Regardless of the reason that a company decides to enter a nearshore development partnership, there are things to look for in the hired team.

Location

One of the main motivators behind web-based companies using nearshore outsourcing for development work is the fact that nearshore developers are usually in the same time zone as the company. If they aren’t in the same time zone, they are in a time zone with operating hours more similar to the company’s. This has a lot of benefits in regards to communication than working an outsourcing company located in India or another country on the opposite side of the world. Nearshore development partnerships are often established for this reason.

By operating in the same, or similar, business hours companies enjoy the benefit of being able to discuss problems in real time with their development counterparts. Being able to quickly address and resolve development issues results in faster turnaround times and happier clientele. When looking for a nearshore development partnership, consider the time zone potential teams are in and how that will affect your business.

Communication

When considering nearshore development companies to partner with, it is also important to consider if there will be a language barrier. While most nearshore development companies employ people who speak fluent English, some do not. Clear communication is a huge part of a successful partnership and a necessity for getting development work done quickly and correctly. Being able to communicate clearly and effectively will also affect how the business operates between the onshore employees and their counterparts. Without an open line of communication, it doesn’t really matter whether the nearshore development team is operating in the same hours as the onshore company or not. If the two teams cannot work together without a language barrier then the IT project will ultimately end up failing.

Quality

Companies searching for a nearshore development team to partner with should also assess the quality of the development team’s work. Does the team you’re considering partnering with have a portfolio of previous work they’ve done? Can they offer you statistics on how many projects they’ve successfully completed? It’s difficult to forge a successful partnership with so many miles between locations. Therefore, it is important that the team you choose for a nearshore development partnership is a strong one. Companies should trust their developers to complete projects on time and turn around workloads in a timely manner. There is nothing wrong with asking for statistics on project completions, turnaround times, and more. High quality work from a nearshore development team will be pertinent to your success as a company. Don’t be afraid to ask for proof of the quality of a company’s work.

Turnover

In a recent study, the 7th Annual Conference on Information Science, Technology, and Management revealed that the turnover rate of software developers in India falls between 30 and 40 percent. In comparison, the turnover rate of Americans in the IT industry sits at 13.2%. By choosing to forge a nearshore development partnership, your entering into an IT sector with a substantially lower turnover rate. This, in turn, opens up opportunities to work with the same development team over multiple projects. Familiarity with how a team member communicates, delivers work, and executes tasks only improves project turnaround time. It also improves the business relationship, in general. Being able to establish a long-term business connection is one of the biggest benefits of a nearshore development partnership.

Deciding to enter a nearshore development partnership has its benefits and its risks. Thankfully, we feel like the benefits highly outweigh the risks. No matter how perfect a situation may seem, you will want to look at some specific metrics. If you are thinking about hiring nearshore developers to outsource some of the work at your company, be sure to ask these 12 questions before you hire anyone. For more information on outsourcing benefits, visit our blog archive to read countless articles on the benefits of a nearshore development partnership.

At Number8, we pair onshore businesses with a dynamic nearshore development team that will effectively get complete development work. Our entire team of nearshore software developers are based in  San Jose, Costa Rica. They are fully trained in agile product development and will produce the solutions your company needs to succeed. Interested in learning more? You can learn more about what we do on our website or call us at (502) 890-7665 today!

 

How to Approach Project Management the Agile Way

An agile approach to project management has become prolific within many industries ranging from software development, construction and even marketing. Approaching a project the agile way ensures the product meets the client’s needs in a timely manner. The agile method also specifically makes room for improvements along the way rather than at the end when a lot of effort has already gone into the finished product. The result is often a shorter development cycle and quicker product release.  

However, an agile project manager’s duties differ from that of a traditional one’s. While the typical project manager is tasked with communication and quality control and manages the scope, cost, risk and personnel, many of these responsibilities are spread throughout the team in an agile workforce. 

Agile encourages team members to determine how to best achieve their tasks, report on their progress and determine their own schedule. Instead of a project manager, teams evaluate their own time and cost as they move through their work. Project goals are set by what is called a “product owner” and an agile project manager is referred to as a “scrum master.” 

The scrum master (or agile project manager) deals with problems as they arise and handles interruptions so his or her team can focus on the work at hand. This often comes in the form of facilitating meetings and discussions, removing progress blockers and setting priorities.

While traditional project management dictates a detailed master plan that must be followed, the agile way aims to determine the requirements as the project progresses. For this reason, an agile project manager tends to only be utilized in particularly larger complex projects. 

When approaching project management through the agile mindset, one must:

Be Flexible

Agile is built to incorporate regular feedback, updates and changes in requirements. While it’s important to understand the end goal and overall scope of a project from the start, an agile project has many cycles to it’s completion. Therefore, an agile project manager must be flexible enough to work with what is thrown their way rather than adhere to an unchangeable itinerary. 

Prioritize Client Satisfaction

At the end of the day, project management has always been done in the name of customer service. This is perhaps exemplified in the agile model as a project manager is in constant flux when it comes to meeting a client’s ever changing needs. It’s important therefore to remember that the end goal is to ultimately satisfy the client even if it’s at cost to the original plan.

Embrace Meetings

Coordinating with team members, stakeholders and clients still remains a large part of an agile project manager’s role. The agile methodology embraces daily meetings often called “scrums” where everyone participates in team transparency. During these scrums, everyone shares what they accomplished the day before as well as what they are working on that day. These are brief workflow updates and can even be done standing up. If not done in person, video conferences are another way of establishing accountability. 

Be Prepared to Problem Solve

Central to an agile project manager’s responsibilities is the ability to quickly adapt and correct course when need be. Continuous improvement ultimately saves valuable resources by reducing the risk of a larger scale failure in the end.

At Number8, we help project managers connect with highly trained and efficient IT support to help reach company goals. If you’re interested in learning more about Number8 and what we do, give us a call at(502) 890-7665, or check out our information page!

Why Mistakes are an Important Part of the Creative Process Even in Tech

Those in the Information Technology field know that software development doesn’t occur in a vacuum. It’s collaborative and often times risks need to be taken in order to achieve any level of innovation. With risks come mistakes and projects that don’t always pan out as planned.

However, IT teams that follow the agile methodology tend to be familiar with the ideology that mistakes are an important part of the creative process. The agile way of developing tech is adaptive in that it is designed around embracing feedback and learning opportunities.

As Albert Einstein once said, “A person who never made a mistake never tried anything new.”

Here’s why you shouldn’t let the fear of making a mistake keep you or your team in your comfort zone:

Mistakes let us know what doesn’t work and paves the path for what could.  

When it comes to developing something new or going into uncharted territory, mistakes are bound to happen. But with experimentation comes discovering a new way of doing something and that is almost always value added. By pivoting and testing new ideas, one is better able to evaluate and refine a product or idea and then learn from it. 

It’s not the mistake that defines an employee, but how they rebound from it.

If mistakes are inevitable, a team should know how to handle them. Take the stigma out of it, and you’ll find that enabling a team to make mistakes means also giving them the opportunity to problem solve effectively. Employees who take accountability for their mistakes and are able to learn from them are a valuable asset to any company. Instead of creating a culture of fear where one tends to get defensive if a mistake is made, establish one where everyone feels empowered enough to innovate and safeguard for the future.

At Number8, we help project managers connect with highly trained and efficient IT support to help reach company goals. If you’re interested in learning more about Number8 and what we do, give us a call at (502) 890-7665, or check out our information page!