In our first installment in this series, we discussed how our unique approach to development blends together the best of agile project management to address the uncertainty that each new custom software development project brings us. Now, how does our team exactly take your idea and turn it into reality through custom software development? We tend to prioritize feature-focused iterative development, as it gets you closer to your end project faster and with much less risk.

Emergent Software custom software development process

Figure 1: The iterative process we follow to ensure we are building the right thing, quickly, and with your feedback.

Let’s dive deeper into what happens at each step in this process:

Step 1: Prioritize

First, we organize the work you request into what are called epics, which is a fancy term for things that add business value to your organization. Within an epic, there are one or more features you define that will help provide that value. For example, an epic in your project might be ecommerce functionality and features could include a virtual shopping cart, checkout experience, and acceptance of credit cards for payment.

Anytime we add something to the list of epics and features, we will work with you to prioritize it. This is all based on your direction and interpretation of what feature is most important. If you say that the shopping cart is the most important feature within the epic, we’ll start there. We may have some recommendations along the way as well based on our perceived level of risk and complexity in creating that feature. If creating the shopping cart requires a complex integration, we’ll want to start there and save the less risky features for later in development.

Critical and nice to have features

Figure 2: Features can represent Critical or Nice-to-Have functionality

Within each feature, we need to further define the specific functionality, which we will also work with you to prioritize. Now, just because something is a nice-to-have does not mean that we won’t end up incorporating it into the finished feature. All this process helps us do is focus on the critical pieces of a feature and then we can fit the nice-to-haves in later. Both critical and nice to have features make up what many call a minimum viable product (MVP), meaning your product has enough functionality to be utilized by early users who then provide their feedback for future development.

Feature by feature priority list Emergent Software

Figure 3: Each feature may have pieces of functionality that are Critical or Nice-to-Have within them, and we’ll work with you to prioritize those pieces.

By focusing on completing your project feature by feature and saving nice-to-have pieces for later, we help you reach a point where your project could go live much faster than less efficient old-school project processes. When a software development partner defines, builds, and tests everything in your project at once, the risk and time involved is much higher for your business, iterating through critical pieces and focusing on speed to value helps minimize that risk.

old school project management

Figure 4: A single deliverable that includes all the functionality is often a recipe for cost overruns and delays.

How Emergent Software develops custom software

Figure 5: Iterative, speed-to-value-focused development helps minimize risk, avoiding the potential ‘runaway train’ of a major all-encompassing release

Step 2: Define the Work

Once we’ve prioritized all the epics and features needed to successfully complete your project, we now need to define your acceptance criteria, which means understanding your criteria for considering a feature to be fully complete. We typically look for two things:

  • What: What are we trying to accomplish?
  • Why: Why is it important (provide context)?

Don’t feel like you need to have a fully fleshed-out idea in your mind when it comes to your project; a natural back and forth will occur as we work on feature development. We take your requirements and form them into user stories – a term in agile practices that describes the work items needed to accomplish the acceptance criteria of the feature.

Here are a few keys to success we look for when defining the work needed to complete your project:

  • It is critical to explicitly define what you need and why.
  • We won’t be able to successfully derive your project’s requirements simply by looking at your current solution. Helping us understand how your current program works and what you want it to accomplish after the project is essential in crafting a solution that satisfies your need.
  • Be sure to define what is needed versus what is wanted in the final product. We can help you accomplish as many tasks as possible, and defining the difference between needs and wants helps us with prioritization as we discussed in the first step.

Too often, we see clients who tell us to look at their current program and have us craft a new and improved solution based on that, which can be a dangerous road to go down. We might not get a full picture of your program by digging into it ourselves, so it’s important you show us the ropes ahead of time. For example, we recently spoke with a client about a piece of functionality on their site that they had deemed necessary, but when they pulled usage reports to confirm that, it turns out no one was even using that piece of their site! This is a win for all parties – our team doesn’t have to redevelop a feature that isn’t going to be used, and the client doesn’t have to spend money on it.

Step 3: Build, Test, Show

Defining and prioritizing work is a good start, but the best way to deliver value is to deliver work as quickly and frequently as possible. The sooner we can show you a working piece of functionality, the sooner we can gather your feedback and course-correct as needed. This is the key to developing complex software, as it emphasizes transparency and collaboration as a core tenant of our delivery philosophy.

Step 4: Feedback & Accept

As you see what we’re working on, you’re going to have new ideas and feedback for our team. This is normal and all a part of the software development process. After all, how do you know what you think of a feature until you see it for yourself? At this point, we help you determine if those new ideas are critical or nice to have, just like we did in the first step of the development process. If your new ideas are quick to implement – great! We can take care of those straight away. We’ve also worked with clients to create prototypes of their final product or have implemented A/B testing to gather research before going live. Our team is here to help you figure out the best way to launch your product and facilitate the review process in a way that makes sense for you.

Software development review and feedback process

Figure 6: We are constantly testing and reviewing feedback as we develop your product. After the initial release, we move into the continuous development phase.

Now, we’ve made it to the end – your software is ready to go live! All the hard work we’ve put in is over now, right? Not quite; development does not have to stop at the release of your project. Some smaller projects require minimal attention while other large projects may require an ongoing investment for growth. We have a variety of post-launch continuous development options available to support your project long after its initial development. Whether you need a long-term technical partner or ad-hoc support, our team is dedicated to your success long after your project is complete.  

We hope this gives you a bit more clarity into our thought process behind the world of complex, custom software development. Interested in learning more about agile-based practices? Check out this blog post on why your road-mapping should be a constant process

Want to meet with our team of experts to discuss your next software development project? We’re just an email or phone call away!