Overview
Without a doubt, the number one reason we see some software projects fail is haste. Nothing is worse than a great idea poorly and hastily executed. Such ideas quickly fail for several reasons which we will outline here for considerations.
Table of Contents
Poor UX Process
Among the most common ways haste shows up in software projects is in the area of User Experience. Many organizations with great ideas are unwilling to perform the due diligence required to refine their great ideas into a User Experience (“UX”). This not only produces a poor-quality product, it does so at great expense as bypassing this step inevitably causes significant levels of change requests, re-work, and test cycles. Investing in a solid UX process ensures the best product. Great UX should simplify development efforts and with it, cost and time to market.
Lack of Product Definition
Another very common area we witness haste appear is in product definition. Naturally, people who don’t design and build software for a living don’t enjoy spending significant time documenting their specific requirements.
While a common issue, failure to thoroughly define a product immediately begins to hinder the development process as those tasked with designing and building the application encounter scenarios for which there is no documented requirements or definition.
This issue always goes hand-in-hand with the former issue of poor or no UX process. Good UX process surfaces issues that are essential to understand, then documents and solves them – all before a line of code is ever written. Solving these kinds of issues during a UX and design process is far less complicated and expensive than waiting to address until after coding has started.
Evidence that a product lacks definition is a lack of well-documented backlog of user stories and/or tasks. If a software developer cannot immediately understand the work being asked of them and begin it with minimal questions, the tasks are not well-defined. They may be defined elsewhere, but not in a way that will allow most software developers to make a productive start. Does that mean all the minutia must be defined about every single thing? Not necessarily. However, many project owners are riddled with assumptions that because it is clear in their mind or because they have spoken the requirement to someone along the way, that the developer understands clearly what is to be done. This is simply unrealistic. It’s not a requirement until it’s written down.
Poor Architecture
Like a home or building, software requires a solid foundation. Any haste erecting architecture will show up continually. It will impact quality, stability, speed of adding features, and maintenance. Never hastily build a foundation, on anything. Ever.
Improper View of Testing
Your agile CI / CD process will also suffer as you can’t continuously deliver with confidence without a strong base of tests. Product owners in a hurry often compromise on many things – those mentioned above are usually among the first. Another common area of haste or, alternatively, excess – is testing. It is common to see two testing patterns in software applications. None or too much. Haste doing either can sink a project. No testing will cause countless defect cycles. Too much testing will premature exhaust budgets. Obviously, no testing is a bad practice for obvious reasons. However, excess? Yes. Many junior resources spend too much time testing invaluable things – what we could call “nervous testing”. These are tests that prove what is already proven by the frameworks used or by logic itself. These waste significant time.
Waiting Too Long to QA
Lastly, waiting too long to start a QA process can cause foundational issues to be discovered so late in the process that correcting them becomes costly and risks budgets. QA testing should be performed with every agile sprint and a feature isn’t accepted as DONE until QA approves and the product owner signs off. Therefore, the QA process should begin as soon as there is output that can be tested – which in an agile project, should be the first sprint typically. This can be challenging to manage if the volume of output is not strong-enough to warrant QA resources, however it should begin as soon as is feasible.
Summary
As we’ve mentioned, haste can ruin a software project rapidly – in one way or another by exhausting resources through poor planning and execution. Often all the above issues are found together and go hand-in-hand. Addressing these challenges requires experienced professionals ready to speak the truth.
If your organization needs professional help without the haste, contact us today.