A true mark of a good Software Development Agency is the ability to deliver high quality software backed by a rock-solid Software Development process.

While majority of the agencies have solid development processes (in theory), things start falling apart when these agencies either:

a) bow under the pressure of the client (we’ve been there before), or

b) try to do much with no explicit budget allocation (we’ve been there too), or

c) simply get caught in the mess of changing requirements and try to accommodate the client to keep them happy (we’ve been there too)

Failure to control either of these scenarios can be extremely damaging to the client and eventually to the reputation of the development agency (we’ve been there before too).

It took us 11 hard years of trying different methodologies and approaches working with both on-site, off-site development teams across numerous time zones to fully appreciate the fact that COMMUNICATION or lack thereof is one of the primary factors that run software projects to the ground.

In a future post, we will address how we as an agency communicate with our developers using checklists and priorities to ensure that things are done the way we (and ultimately, our clients) expect them to be done.

Once Communication (or comm as we call it) issues are handled, the SOFTWARE DEVELOPMENT PROCESS becomes the most important factor in building high quality software.

Majority of our clients that are seeking Custom Software Development often ask us about our Software Development Process.

The truth is…

Every Software Development Agency has their own unique process that works for them.

Software development processes aren’t set in stone and are often fine-tuned over time.

Here’s another kicker…

The Software development approach may change completely depending on the client’s needs.

If someone tells you that their process works great across the board, they’re probably inexperienced in this complex field of software development.

We’ve been in the trenches building software for over 13 years. We’ve had numerous successes and failures (if there’s a thing like that) under our belt, we can assure you that there’s no such thing as a ONE SIZE FITS ALL.

This article will aim to address *our* software development approaches and also highlight some important reasons why we may choose specific processes for different clients.

At a high level, the industry has settled on two basic approaches to Software Development:

• The Waterfall Development Model
• Agile Development Model

Let’s take a look at both of these models and highlight their key differences.

Waterfall Development Model

Photo by www.headsmartmedia.com on Unsplash

The Waterfall Development Model works on the assumption that all of the requirements for the software are defined and don’t change over time.

It is a very linear process of Software development where requirements are gathered first, followed by System Design, followed by Software Development, followed by Testing, followed by Deployment and Maintenance, hence the name, Waterfall.

Advantages:

• This approach of software development works great when all of the Product features are known upfront and there’s very little chance of changes.
• A given phase of development is fully complete before the next phase begins.
• Works great for small projects with fixed budgetary constraints.
• Extremely simple and easy to use for Clients who have very specific needs.

Disadvantages:

• Takes a long time to see the actual Software. Business needs may actually change by the time the software is delivered.
• High amounts of risk and uncertainty when building software. Very difficult for clients who are visual and believe in building things faster.
• If the technology needs or requirements change during the development cycle, they come with increased costs.

So when and why do people still use this model?

Well, many customers just need to build a more modern version of their software. Their needs haven’t changed over time. The requirements are very stable, not much interaction is needed with stakeholders and the outcomes are well documented. These type of clients can easily use the Waterfall Model for software development.

Most modern B2B and B2C applications today do not use this model anymore due to the changing nature of the Software requirements.

Agile Development Model

Photo by Cara Fuller on Unsplash

The Agile Model for software development is an incremental and iterative approach that allows software to be developed in rapid iterations (usually called Sprints). Each iteration yields a fully working product that is tested and approved for release. An example of this model called Extreme Programming (XP) is a great implementation of the Agile Model.

Advantages:

• Rapid, continuous delivery of software
• Can account for changing needs easily
• Working software takes weeks to deliver
• Collaboration increases between stakeholders and the development team, resulting in less surprises

Disadvantages:

• Estimation and approximation is hard for larger projects. Planning is difficult.
• Giving clients estimates on costs and budgets is even harder.
• Many teams completely give up documentation of any sort in the name of agile development.
• Skilled developers can accomplish a lot more compared to inexperienced developers who may risk the entire sprint if they are unable to deliver on their estimates.
• As it often happens when building complex solutions, developers may often run into an issue that was previously unaccounted for, or was inaccurately estimated in complexity, thereby throwing the entire deliverable off.

Agile, for all its benefits can be very complex if incorrectly executed and has let to failure of a lot of software projects. A future post will address some of the greater challenges that come with Agile.

REMEMBER: There’s no tried and tested Software Development process that JUST WORKS.

A good Software process allows iteration, is open to changing requirements, works majority of the time in a predictable fashion, and doesn’t produce major surprises for any of the parties involved.

Software Development, due to its very complex nature is a tradeoff between SCOPE, BUDGET and TIME TO MARKET.

This is often termed as the Golden Triangle of Software Development and is a MUST UNDERSTAND item for anyone trying to get into Software, either as a client, or as a developer.

The HyperTrends Software Development Process

OK, now that you have a basic understanding of the main software development models, let us take you into our world of software development.

Our Software development approach is unique (to us), and is an applied Agile Model that has evolved over the last 13 years. We have gone from Waterfall, to semi-Waterfall, to Agile, to semi-Agile (or Light Agile as they call it) and back to Agile depending on the needs of the project.

As we worked on projects (both big and small) we saw a pattern emerge and we called it DIDI.

Yes, that’s what our Software Development Process is called. It stands for Discover-Ideate-Develop-Iterate (DIDI). It sounds extremely simple, and it really is. We pride ourselves in keeping things super-simple. What’s interesting is that this same approach works for both Agile as well as Waterfall models.

This simple process is adaptable and really cuts through a lot of noise. We’ve written in-depth about DIDI here. Here’s a quick recap of DIDI:

• Discover – We along with the stakeholders undergo a Discovery process that will allow us to identify the core deliverables of the product we are about to build. It is through this discovery process that we are able to understand the product from the eyes of the market and build deliverables accordingly.
• Ideate – In this phase, we start playing around with ideas, build wireframes, write up user stories, perform proof-of-concept development (rudimentary), identify deployment/go-to market strategies and present them to the stakeholders for approval. We may also produce a Product Roadmap with contingencies.
• Develop – This is where we undergo a few sprints of development to build out the key deliverables. Depending on where we are in the project, these deliverables may/may-not be released to the market. Stakeholders will definitely see them and be able to provide us with feedback.
• Iterate – Once stakeholders approve, and the product is in the market, this is when our main experimentation begins. We collect huge amounts of data on user behaviors, other key performance metrics including user journeys across the application, error/usage metrics, page load times etc. to identify core areas of improvement. We tell this to our clients all the time. Our REAL DEVELOPMENT begins when we go LIVE and start collecting this data. Every Software we build has a different reaction from the marketplace. In fact, our goal is to get to market as early as we can (without sacrificing quality, of course), so that we can adapt and evolve.

Why does DIDI Work?

DIDI works for us. It has really allowed us to deliver software with biggest bang for the buck for our customers.

Our customers will often be surprised by how much we can get done with their dollars compared to other agencies.

It isn’t that we’re geniuses. It’s just that we are masters in prioritizing and focusing on the WHY when we build software using DIDI.

Here are some of the reasons we think DIDI works:

• Our Discovery process is extremely formal. An initial day of high level talks gives us an idea of what you’re trying to build and gives us insights into your priorities. We build user personas, go-to market strategies, measurable outcomes and plan the software development around these outcomes.
• Sometimes this discovery process happens for each component of the software we’re building so that we don’t spend too much upfront time going through each and every component. This speeds up development, but still keeps the overall vision and the component’s vision in context AS IT IS BEING DEVELOPED.
• We leave CRAZY MARGINS FOR CHANGE. We know that building a product is never easy. Things change. We get it. A classic example was in a Travel system we recently developed for a customer of ours, our priorities were changed mid-sprint to satisfy a potential investor’s needs. We simply changed gears by putting the current feature on hold without much hassle.
• We can use additional strategies like MOB DEVELOPMENT to rapidly develop software with minimal overheads.
• The IDEATE phase allows us to prevent issues that many agile teams run into. Most teams start building software based on stories without thinking about the technical ramifications. It is a well documented fact that most agile teams fail due to numerous reasons, primary among them being the lack of vision or planning involved in building a high quality product.
• We consider iteration (or what others call maintenance) not as an afterthought, but as a CORE STRATEGY in building quality software. By considering maintenance outside the scope of the software development, 99% of the agencies shoot themselves in the foot and don’t really account for the unpredictable needs of the market. This single fact alone has helped us plan and deliver better software.
• DIDI deliverables can flexible and range from polished, signed documents to proof-of-concepts to fully functional software depending upon the needs of the client.

Closing Remarks

In closing, we’d like to re-iterate that every agency has their own development model that has been tried and tested by them and mostly works without big surprises. Communication is KING. Over communicate. Formalize, as much as possible.

Our DIDI model works great for us, and is extremely flexible to allow us to build some seriously high quality software.

A few of our recent successes (despite the odds stacked against us) include:

• LaCantina Doors/SYSPRO Integration Project – This is as ROUGH as it can get. We ran into obstacles that included cross-team communication, multi-party deliverables, ever evolving requirements, complicated programming, almost no room for error, ‘deadlines first – plan later’ approach, integrating with a 3rd party system building something very few have ever implemented, developers wanting to quit due to inter-personnel issues. YUP, sounds like a tough one, but we delivered. It was a WAKE-UP call that deviation from process is lethal.
• TicketSocket – a Startup with a roadmap so crazy that it gave us numerous sleepless nights, but with adequate planning and room for changes, we were still able to control the beast and get it to a happy place.
• Spledger – another Startup with some really tight deadlines and complex requirements and multiple deliverables that we were able to deliver.

Over the next few articles, we will go into the 4 steps of the DIDI process in-depth and discuss the various approaches we use for each step and how we navigated through some of the toughest projects and were able to deliver working software.

Feature Photo by David Travis on Unsplash