This article is not about the what or even the why of developing a piece of software; it’s about the how. Deciding what kind of tool you need and why you need it are important initial steps, but you also need to think about what the process will ultimately look like. How will you do it? For that, you need a software development strategy that fits your needs.
For as long as computers have been around, programmers have been dealing with the issue of creating productivity and project management tools that relate to the technology of the era. This is because technology evolves rather quickly, but business processes are slow to innovate. For this reason, developers are always trying to find the methodology that will be their panacea. No one methodology guarantees project success, though. The strategy that works out excellently in one scenario may be an utter failure when applied to another one.
All this to say, landing on the appropriate software development strategy requires the consideration of many variables: the size of the project and its components, the skills and expertise of the development team, the tools and technology at their disposal, the budget, the timeline, scope and objectives – the list goes on. To have the best chance of success, you need to understand both why and how a given methodology will apply to your project.
Finding Your Strategy
The biggest mistake that can be made early in a project’s life is assuming a particular approach will work without sufficiently analyzing the problems, goals and challenges involved. Just because the method you used the last time you undertook a software project worked out well does not mean you’ll have the same outcome this time around. Your next project could come with much higher risk or a much tighter timeline; these are factors that change how you approach development and need to be evaluated beforehand.
The first step to identifying your software development strategy is determining who the product owner of the project will be. This person is usually an executive or manager from your business who has a clear idea of the application that will be built, and agrees to be the go-to person from your organization when issues arise during design and development. Of course, the team of developers you work with should be able to assist you in this process, but ensuring this role is filled with a key stakeholder will make any process you land on run much smoother.
Once a product owner has been named, you need to get into the nitty gritty, gathering information about your legacy systems, integrations and inventory of available tools and technologie that can be employed. You also need to document what the proposed product is, what it needs to be able to do, the features and capabilities it requires, any other requirements and challenges and potential roadblocks you’ve discovered through your assessment.
Once all stakeholders have a grasp of what this project entails, then you should be able to find the right solution. There are a few popular methodologies software developers favor, and many more that are pieced together from components of different processes as needed to satisfy the demands of the situation.
A Few Popular Options
It’s important to note that some projects, especially small and uncomplex ones, don’t require a full-fledged strategy to complete. Not having a strategy can be a strategy in itself. Devoting yourself to a methodology may actually be more of a hindrance in these cases, adding extra management overhead where it’s not needed. However, if you find yourself struggling to imagine how all of the processes will be managed, one of these strategies may be the best solution.
Waterfall
The waterfall approach is – compared to other strategies – pretty old, originating around half a century ago. It follows the development premise of construction and other real-world projects where steps have to be followed in sequential order. For example, first you lay the foundation, then you frame the house, then you add the walls and so on. In software development, a similar practice is followed. First, you determine requirements, then you design the application followed by active development and testing, and lastly, deployment. The next step cannot begin until the previous step has been completed.
A detailed plan for each stage must be decided upon before the project can begin, and tight control must be maintained as the project moves through the different phases. Formal reviews, demos and client approval are required to progress. This can be a good thing and a bad thing. On one hand, waterfall calls for a lot of upfront planning and preparation which decreases the likelihood of a project running into any huge surprises during development or getting off track and becoming something a client won’t approve.
On the other hand, as a strategy, waterfall has been criticized for its lack of flexibility which can cause budgets and deadlines to be overextended when a project gets stuck on a particular step. It’s also true that there are some things about a product you just don’t know until you’ve started building it.
Agile
The agile methodology takes a more iterative approach to development. You want to be able to pivot and readjust your course in response to new issues or changes. Achieving real agility requires knowing a lot about your project and circumstances – the product, your business objectives and needs, project goals, abilities of the dev team, technologies, use cases, data models, etc. – giving stakeholders a high degree of visibility into the process as it unfolds.
Unlike waterfall, the entire development process isn’t mapped out from start to finish in a highly-structured, linear fashion. For that reason, adopting an agile strategy for your project can go wrong fast if your dev team doesn’t have the training and skills to implement it. When all stakeholders dedicate themselves to a process that emphasizes continuous feedback and clear communication, this software development strategy can be very effective.
Agile may be your development strategy, but for the day-to-day, you need a working strategy such as kanban or scrum to manage tasks within each phase.
DevOps
DevOps is a relatively new strategy, rising to popularity within the last decade or so. The intention behind it is to bring development and IT operations together to speed up development by streamlining the product life cycle. We’ve written a whole article on the capabilities of DevOps in software development. Needless to say, this methodology has the potential to optimize processes in a way that benefits the bottom line. However, it is a young strategy, so the level of comfort with it may differ from team to team.
Going From Idea to Asset
There are as many possible solutions to project management in software as there are problems to be solved. Beyond the most popular approaches, there are applications that take components and make them their own to suit their needs. For instance, a spiral model of development steals the detailed pre-planning of waterfall and breaks down projects into different sections in order to prototype different features. This approach is useful when risk management is a major concern.
You can also take a more iterative, agile approach with zero pre-project planning, meaning that software is being planned at the same time it’s being written. This is not normally the wisest course of action, but in times where business objectives are paramount and technology takes a backseat, it has been known to happen.
The point is, the software development strategy everyone decides on can be just as custom as the software application you need to build. At Vice Software, we don’t follow the same strategy for development every time. Sometimes, bigger projects require a waterfall approach, while smaller projects can be managed with kanban or scrum. It’s all based on the parameters of the project and meeting the needs of our clients.
If you’ve already figured out the what and why of your custom software project, reach out to Vice Software today to nail down the how. Request a quote today!