What is the best working model for software product development?

So, what is the best working model for software product development? It’s highly likely that all projects will have a beginning, a middle and an end. So, any project delivery model would surely appreciate this fact. However, the beginning, middle and end of a project might look very different from experience and results perspectives. Particularly so when you reflect on the various methodologies for software delivery.

Software project delivery models have evolved dramatically over the past couple of decades (giving away my software age here), and this is a good thing (as can be the wisdom gained with human years). A short history lesson might well be appropriate now as it may also be worth acknowledging how not to develop software. We have broken this model discussion into two segments; Legacy Waterfall and Contemporary Agile.

1. Legacy Waterfall Models

Legacy (or, traditional) software development models were typical Waterfall in their approach. A Waterfall approach implied that the beginning, middle and end of a project are prescribed in advance. The respective scope and timelines are considered to be set in stone.

In practice, this means that significant time is spent on technical feasibility, requirements and feature specifications upfront and from this, a timeline is crafted to determine when a set of designed software would be ready for a final system and acceptance testing regime.

This sequential approach may be suitable for manufacturing industries where outcomes need to be - and can be - very predictable. Nevertheless, it has proven to be a flawed approach to software development. Now, some might argue that there can be exceptions to the rule and there, of course, can be. These exceptions will always be in the margins. The SAFe (Scaled Agile Framework) approach is perhaps a hybrid middle ground combining agile and waterfall that is relevant today.

The main flaw with traditional Waterfall approaches is that they are rigid. To coin an old adage, “planning is essential, following it isn’t”. To be effective, Waterfall delivery models require that all factors that influence a project have been captured or sufficiently covered by some contingent built into timelines and budgets. The scope must be known in advance and fixed. Changes that will be incorporated into a project’s content must be coordinated in a controlled manner, typically with some flavour of change request procedure. This approach is cumbersome and does not allow the project stakeholders to adapt quickly to changing markets, insights or needs for a complete pivot in direction.

So, gone are the days when an excel sheet containing a list of fixed, never changing, requirements could be sent to a software developer with a statement, “let me know when you will be ready with this”.

2. Contemporary Agile Models

More contemporaneously, the need for agility within a software development life cycle has been acknowledged and fully embraced under the banner of the Agile Manifesto. Derived from the Agile Manifesto values and principles, we have several similar, but different approaches designed for project delivery that can be adopted by a project and that allow for varying levels of agility.

Agile Software development approaches orient around the collaborative effort of self-organising and cross-functional teams and their respective customers and users. With this in mind, it’s important to tailor make the processes to your needs but keep the principles.

Scrum

The Scrum approach to software development allows for levels of structure to be introduced to focus a team on priority activities, while also allowing for sufficient flexibility to change direction periodically.

With a Scrum approach, software design or feature content are broken into timeboxed calendar windows, known as Sprints. Each Sprint typically takes two to four weeks and outputs something tangible, like completed designs, prototypes, working features, integrations to other systems, etc. Sprints are iterative, whereby you can have multiple Sprints during the lifecycle of a project. The content for each Sprint is selected from an ever-evolving and prioritised backlog of features. A product owner owns the backlog and the priority of any content within it.

Scrum offers a level of predictability, as you know what to expect as output and when to expect it. Scrum also provides flexibility as the content for the following Sprint can change based on renewed priorities of content within the product backlog.

Kanban

Kanban is similar to Scrum in that it feeds off a backlog of content. However, you might (depending on your perspective) consider it to be less predictable as timeboxing isn’t imposed. Kanban arguably focuses more on being flexible - or more agile - than Scrum in that content can be continuously adjusted in terms of its priority. Once a software designer or developer can work on something new, he or she will select the highest priority item within the remaining backlog that matches their skill set. As you can imagine, there is much agility in this mode of working, but it does require that the product backlog owner be diligent in keeping priorities ever up to date. Otherwise, time can easily be wasted on a lesser priority task.

Which of these approaches is best for software development, you might ask? Well, I can state for sure that the Waterfall approach is the lesser of the three noted methods. Then, the jury is perhaps out when it comes to Scrum vs Kanban as it comes down to which approach suits you, a presumed product backlog owner, best? If you like to work towards “milestones”, then Scrum may well suit you best. If, however, you prefer or need more flexibility, you’d likely lean toward Kanban.

If you would like to discuss the best approach for your product development, chat to myself and the team and together, we can build an innovative and advanced product.

- Merv Graham

To learn more about 'Agile Product Management', watch our on-demand webinar today.