If there is one topic that you can guarantee will divide the opinions of software developers, it is development methodologies. No matter where you look there will always be a number of individuals that feel so strongly about their preferred methodology that they are unwilling to consider an alternative.
Unfortunately having such a limited mindset can end up becoming a hindrance. As although each methodology shares the same purpose, to define the structure and aid the planning and control of the development process, they vary in how they achieve it and which is best will depend on the situation or scenario.
Perhaps you are one of the guilty ones. Working away with the same methodology, project after project, not stopping to see if there is a better alternative. Maybe after having a glance through a couple of the other methodologies available to you, you may just find something more suitable.
Waterfall Development Methodology
Commonly considered the traditional development methodology, anyone who has so much as dipped their toes into software development will have come across the waterfall methodology. Rigid and linear in its structure, the waterfall method is made up of several sequential phases (typically requirements, design, implementation, testing and maintenance) where specific goals are accomplished. If followed to the letter, waterfall expects each phase to be completed to 100% before the following phase can get underway, and there is very little allowance for making changes.
In theory waterfall should allow for accurate project delivery, as each phase can be planned in detail and requirements are clarified right from the start, however in practice it tends to fall short of expectations. Very few clients know exactly what they want from a project, and those who do are often unable to accurately articulate their needs and wants, meaning revisions and alterations are often a necessity. As a result of its rigid structure and tight controls, waterfall is not very efficient at dealing with change. Expecting users to backtrack through phases, sometimes as far as the initial requirements, and work forward again resulting in progress that is both slow and expensive.
Despite these issues, the fact that waterfall is linear and sequential makes it easier to manage than other methodologies. Moreover, in situations where requirements are well defined, such as safety based projects, waterfall is probably going to be the cheapest and most suitable methodology to employ.
Agile Development Methodology
Calling agile a methodology is rather misleading, as agile in and of itself is not a methodology but rather a conceptual framework under which other methodologies and frameworks such as Scrum, Extreme Programming (XP) and Feature Driven Development fall.
Where waterfall is linear and rigid in its structure, agile methods are just the opposite. Usually working in a cyclic manner, agile methods attempt to minimise risks such as bugs, cost overruns and changing requirements by developing and improving software over iterations that are mini increments of the new functionality.
A major flaw of agile methods is their reliance on real-time communication and the demand for large time commitments from the individuals involved in the project to fully complete each feature within the tight timeframes imposed on each iteration. You can also find that important aspects of a development, such as documentation, can go by the wayside. However, this tends to be the result of individuals failing to follow best practice, forgetting that using an agile method does not equal ‘hacking’.
Agile methods really come into their own in situations where there will be very little time to prepare for the initial release of a project or service, or where changes to requirements are either expected or a regular occurrence. As software is planned, developed and tested over a number of iterations you will have access to a basic, but functional, product in a significantly shorter period of time than if you were to choose the waterfall model. This way of working also allows for the easy incorporation of requirement changes, should you realise something was missing out of a previous iteration you can add it in to be addressed in the next iteration.
For anyone who is familiar with the waterfall method, moving to an agile method does require quite a significant shift in thinking, and you may find that they will struggle to adjust. For many, not having to detail and outline requirements in full at the start of development gives the impression that there will never be an end when in reality this is not the case.
You can’t talk about agile without at least mentioning Scrum. Scrum is perhaps the most popular of the available agile methodologies and frameworks, following the typical iterative, incremental development process by applying its own unique workflow and set of roles.
In a Scrum controlled development you will always find three specific roles; the product owner, the Scrum master and the development team.
The Product Developer – it is their responsibility to continuously communicate the vision and prioritise the features of the project to the development team.
The Scrum Master – it is the responsibility of the Scrum master to remove the blocking points preventing progress by the development team. In essence, they are responsible for facilitating the entire Scrum process.
The Development Team – unlike other methodologies, the development team on a Scrum project are provided with autonomy and the ability to self-organise. It is their responsibility to ensure that the goals for the current iteration (or in terms of Scrum, the current sprint) are completed on time.
Before any work gets underway, the product owner puts all of the features that need to be developed into what is referred to as the product backlog, and are prioritised. During every sprint, items from the top of the product backlog are moved into a split backlog, to be worked on over the duration of that sprint. To help ensure that the development team will meet the goals of the sprint the Scrum master will hold a daily meeting, called a Scrum, where everyone gives a rapid report on what they achieved the previous day, if they have encountered any blocks that are preventing progress and what they plan to achieve that day. These daily meetings help to keep team members informed and identify progress blocks so that they can be removed quickly, and minimise the time lost.
At the end of a sprint a review is conducted where the functionality completed during the last 2-4 weeks is demonstrated to the stakeholders. Before the process is repeated once again for the next sprint, a retrospective meeting is held so that the team can reflect on the recently completed sprint and develop ideas for improvement during the next sprint.
One of the drawbacks with Scrum is its reliance on commitment. It is easy to pull backlog items into the current sprint and say that you will get them done, however actually committing to getting them done is another beast altogether. You also need to understand that once a sprint has begun the direction of the development team should not change until the sprint is over, meaning that there will be at least two weeks before they will be able to shift their focus and priorities. Of course, a delay of two weeks is significantly shorter than many non-agile methodologies can achieve.
If executed correctly there is no denying that Scrum can be an extremely effective and valuable way of working, but that is yet another issue with Scrum. Very few people actually follow the process very closely. Constantly making allowances to compensate for failure or trying to play the system.
Although very similar to Scrum in a number of ways, Kanban takes a slightly more relaxed approach. For example where Scrum divides the project backlog into small regular batches Kanban aims to achieve a continuous flow. Rather than hold regular planned ‘sprints’ Kanban teams are free to pull new work into progress as soon as it becomes available. Of course there is a limit on the appropriate level of work in progress, otherwise you will have an excessive number of tasks on the go with absolutely no progress being made.
Another notable difference between Scrum and Kanban is in the release methodology. In Scrum, providing there is approval from the product owner, there is a regular release at the end of each sprint. With Kanban, the release of features is continuous, with the point of release often falling to the discretion of the development team.
On the other side Kanban’s biggest asset, its simplicity and flexibility, can easily become its biggest disadvantage. There is a high risk that as priorities can be changed at a moment’s notice you run the risk of miscommunication and the thrashing of development teams. Then you have the challenge of getting started in the first place. As Kanban is almost a blank slate, teams that are new to agile, those that don’t yet have an existing process or are unsure of where they are going may not know where to start.
Test Driven Development
Typically, most development methodologies follow the ‘take your requirements, develop some software, test against the requirements’ formula. Test driven development comes from a slightly different angle. As the name suggests, those implementing TDD create test cases that accurately define the desired feature or function which then go on to guide development so that software is developed to pass those tests.
As you can imagine by writing software to pass a test, developers are able to spot and resolve bugs and defects earlier than they would if they were to use another methodology. You can also find that the overall speed of development increases in the long term, with engineers thinking more from and end-users point of view and the test cases acting almost like a live documentation, making the code easier to understand.
Of course as with any methodology, TDD does have its downsides. Writing good tests that cover the essentials whilst avoiding the superfluous is much harder than it sounds, and requires a lot of effort up front making the overall development process feel slow and laborious. A big risk with TDD is that a simple misinterpretation of requirements can go unchecked, providing that the related test cases are passed, potentially resulting in a feature that doesn’t actually fit with the customer needs. It is possible to minimise this risk through utilisation of best practice, but should be taken into consideration nonetheless.
Much like waterfall, TDD doesn’t lend itself to developments that experience regular requirements changes. Potentially resulting in wasting time developing test cases that will only be dropped further down the line. However if you plan to start a new development and have the design nailed down it may be that TDD could be the cheapest route to a quality product.