Turing's Man Blog
- Last Updated on Monday, 30 June 2014 11:40
- Published on Sunday, 29 June 2014 21:42
- Written by Pawel Wawrzyniak
- Hits: 23836
There are many software development methodologies (or system development methodologies – which in my personal opinion is even better term) in the field of software engineering. Debates on their pros and cons are countless, the same way like other discussions of such kind – for example: "which programming language is better"? The answer is simple – this methodology is better in given case, which suits the requirements and conditions best. The problem is – it is hard to choose the proper one. Therefore, to stay current with the latest trends, it is a good idea to watch the shortest (I've ever seen) introduction to Scrum – an iterative and incremental agile software development framework for managing product development – and compare it to the well-known Waterfall model.
There are three roles in Scrum:
Product Owner - takes care of the backlogs
Srcum Master – defines three ceremonies: Sprint Planning, Daily Scrum (standup) and Sprint Review & Retrospection. He is also a facilitator for the team, therefore often mistakenly treated as a Project Manager or Team Leader.
Team Members – the team responsible for software development
There are three artifacts which are used by the Team Members in Scrum:
Product Backlog - a list of every desirable outcome users expect from the product. A 'to do' list of goals sorted by importance.
- Sprint Backlog
- Burndown Chart
Now – a question? Is Scrum a universal methodology which can be used in all possible cases? Definitely no. However, this is very popular among many software development teams that work not only in small startups, but also in big companies. The huge advantage of this methodology is its dynamics and flexibility. Let's have a look:
Explaining Scrum in less than 120 seconds - a presentation by Pyxis Technologies
Also, what is really important – Scrum recognizes the fact that during a project the customers can change their requirements (or the way how the problem is seen can be changed, because actual development unveils some additional, previously unknown facts). Such changes, which are very common in many projects, can be easily addressed with Scrum. In other, classical methodologies of software development, especially in well-known Waterfall, which is sequential model, such adaptation to requirements change would be – in many cases – impossible. The main reason of such inflexibility of Waterfall model is its main assumption that each stage of development can be started on the basis of previously finished stage. Therefore, it is really hard to include changes without repetition of the whole project stages. Hence, the popular phrase among Project Managers – "it's out of scope"!
To better understand the difference between these two frameworks of software development it is a good idea to compare previous presentation with this one:
A great description of Waterfall model by Simplilearn
At this stage we must agree that Scrum is not a silver bullet of software engineering. All the agile software methodologies can be considered more dynamic and flexible, when compared to classical frameworks. However, there are still some areas in which old-good Waterfall model can be considered an advantage. I can see at least few strong sides of Waterfall at a first glance.
First relies in the business sphere – an external company can protect its own interests and earnings once signs a contract with its business partner quite easily. There will be a small risk of often changes in defined requirements, as this will result in expensive change requests – the process of change implementation will always be started with in-depth requirements analysis.
Second is directly related to the fact that Waterfall is strictly defined and enclosed in its six-to-eight (depending on the version presented) stages of development process. It closely follows all of its phases. This means that both designers and developers have to be sure that the expected milestones of all the phases are satisfied in their pre-defined time. Such approach requires discipline. Also, a careful and comprehensive planning is necessary to assure that all the issues would be solved and fixed before they manifest – this results in two additional things: first of all, the clients can get the best product in a defined period of time; secondly, the whole team is able to tell the clients what is the deadline for software product delivery.
What is really dangerous – there are many inspirations coming out from the world of software engineering to the world of IT infrastructure. Many Project Managers, previously experienced with software related projects, are trying to use some well-known schemas from these two methodologies (both Scrum and Waterfall) to the infrastructure (hardware) development projects.
As long as such ideas come from Waterfall-like, strictly defined stage by stage methodologies, it seems to be nothing bad. Having in mind that software is not infrastructure (or hardware) is usually enough to take care about specific issues which are cross-industrial relations, technical norms, good practices and local law regulations.
The problem begins when someone wants to involve the team into Scrum, but the aim of the development activities is to deliver… technical solution based on hardware (servers, network equipment, storage, etc.) and infrastructure (rack cabinets, power and network cabling, etc.) to run some software on top of it. It is not only impossible, it is even a contradiction of reality.
Yet, I was asked several times if it would be possible to employ Scrum for infrastructure related changes. My answer is – generally no, because there is no place for improvisation during infrastructure development and infrastructure is by definition rather not too flexible: 30 meters of copper cable is exactly 30 (not 25 and not 37). So, it is rather hard to change once agreed requirements on-demand during actual development. However, we should always look for inspiration and a strong side of Scrum is – effective communication.