As per the KPMG Survey, on average, about 70 % of all IT-related projects fail to meet their objectives, and one of the main reason is the selection of the wrong software development process/model.
A software house owner explained in an agile conference “We were facing problems like over commitment and under delivery, unsatisfied customers, missing deadlines and unhappy team. We switched our development model, and it all turned out to be ok.”
Just selecting a model that suits your criteria can avoid these problems.
For example, if requirements are all clear and written down, you might have to choose a different model if requirements are not clear and constant changes are expected.
Here are 4 of the most effective models being followed by the software industry to achieve their goals timely and efficiently.
Probably the oldest and most straightforward SDLC (software development life cycle) development model, Waterfall follows a sequential model (like a waterfall) with requirements analysis, design, coding, testing and implementation in such a manner that the development does not move to next phase until the previous phase is completed. That is why it is called the linear sequential software development life cycle.
- Clear and easy to understand
- Easily manageable process
- Only effective if all requirements are clear and no changes are expected
- If one phase is delayed, it delays the whole cycle
Repetition is the keyword for the iterative model. Instead of having clear and known requirements or waiting for them, a team starts development on the known features, tests and then evaluate further requirements, develops, tests and so on until the whole thing is done.
- Ability to work even if the requirement is incomplete
- Early on visibility to clients
- Difficult to define or manage milestones
- Requires a lot of code-refactoring due to constant addition to requirements
Agile, the most widely used software development methodology is Agile, has become the industry standard, be it software development, App development or Game development.
Agile says a quick fail is a good fail, rather than knowing about the fail in the end.
Agile focuses on the small iterative and incremental approach. Its flow normally consists of sprints ranging from one week to 4 weeks. In each sprint, goals are set, developed, tested and then shown to clients to get early feedback, and this allows any changes at any stage of the development cycle, making it easier to manage and to avoid delays. Tasks that are not completed in a sprint are then added into next sprint, re-prioritized and developed.
There are multiple methodologies where Agile can be followed, but we are focusing on practical development models so let us talk about the most useful ones with their pros and cons.
In Scrum, the work is divided into Sprints (normally ranging from one week to four weeks) and the whole team works as a unit to achieve that common goal. Progress and bottlenecks are tracked in a daily standup meeting and team self-organizes to meet the deadlines.
Key team roles are:
SCRUM Master: He is in charge of leading the team, consult daily standup meetings, see if there is any bottleneck and remove it.
Product Owner: He is the one with software/app functionality specification, responsible for making clear enough for the team to start working on, and to be consulted if any confusion.
The Team: This is the development team which mostly consist of developers and testers. Although no clear roles are defined, the success is measured by the completion of the task by the whole team rather than individuals.
- Easier to deliver a quality product in the required time
- The whole team takes the responsibility of making it happen, instead of just the manager or the owner.
- Because of small sprints and early access of the product to the client, it’s easier to handle requirement changes.
- Only good for small teams. If the team gets bigger, it gets difficult to handle and measure key parameters.
- If a developer leaves during a sprint, it can have a huge impact on the development cycle.
- Scrum relies on the team to take responsibility without any external micromanagement. It will not work if the team is not taking responsibility or micromanagement is being done.
In this model, the main driver is the Kanban board. It can be a physical or a virtual board where tasks are picked up from the “TO DO” list by each team member and put into the “IN PROGRESS.” Once the task is complete, it is moved into “DONE,” and a new task is pulled from To Do list.
There is always a clear picture of what tasks are to be done. Management can limit the work in progress and share the done tasks with the client.
- Improved resource allocation.
- Reduce surplus work.
- Good for environments where priorities frequently shift, e.g., support the environment where the new incoming query can be of higher priority than the ones currently being worked upon.
- Less fruitful if resources are shared
- It heavily relies on the Kanban board being up-to-date. If the board is outdated, it can cause issues.
- Without release deadlines, the team can unknowingly fall behind.
ScrumBan is Scrum and Kanban taking the best of both worlds. It was originally created just for the transition between SCRUM and Kanban, but it became a model on its own.
Wikipedia defines it as “Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban. Today, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work.”
In Scrumban, a Kanban board is used to keep the flow of the process and to limit WIP in each step, while using Scrum principles of backlog management and prioritization.
The biggest difference between Scrum and Scrumban is the latter does not use sprints. The team continuously pull work from backlog, keeping WIP limits in the process.
Here is a short table that will help understand the difference a little better.
Scrumban is widely used in development and maintenance projects.
- Flexibility in process. A team can improvise and modify the process that suits them the most.
- Has the best of both Scrum and Kanban.
- As there are no dedicated sprint reviews, the product owner needs to be more active and responsive.
XP Extreme Programming
XP programming (or Extreme Programming) emphasizes on high-quality code which accommodates client change request quickly, hence increased productivity.
XP majorly relies on programmers to write clear and simple code that solves the problem and then unit test it thoroughly to verify if it meets the client’s requirement.
Five core values of extreme programming are:
- Communication: Team to communicate with each other and transfer knowledge.
- Simplicity: Just simply use the things that work.
- Feedback: Constant feedback from the client and the team to improve product development.
- Courage: Bold decisions that are not harmful to your team.
- Respect: And finally, respect for each other.
- Saves cost and time
- Simple yet effective product
- Easily adjustable changes
- Early feedback from the client makes the end goal more clear
- Some say XP programming focus on simplicity rather than good design, and this can be dangerous in some cases.
- Not effective if the whole team is not present at the same location
- Not effective where the team collectively does not have some business analyst experience
DevOps is a relatively new model that is gaining a lot of traction in the software world.
DevOps is a set of practices and cultural changes, supported by automation tools and lean processes, that creates an automated software delivery pipeline, enabling organizations to deliver better quality services and applications faster.
It is considered as an end-to-end solution resulting in fast, automated deployments on live servers daily, or multiple times in a day, decreasing the gap between development and operations team.
- The accelerated time between conception of an idea to live server
- Quick fixes
- Not suitable if there are only a few releases a year
- Expensive resources and rare in the market
Whether you are a software house that is developing custom solutions or creating apps and games, each of the above–mentioned models handles different challenges in their way. You have to decide which one suits your needs best.
If you have been working with the wrong model, here is the inspiration…
“Only through reflection, we change our history.”