1990+ Waterfall Method
What is the waterfall project management methodology?
Waterfall project management is a sequential, linear process of project management. It consists of several discrete phases. No phase begins until the prior phase is complete, and each phase’s completion is terminal — waterfall management does not allow you to return to a previous phase. The only way to revisit a phase is to start over at phase one.
Waterfall process model is probably the most popular methodology of software development. Teams and companies all over the world use it to manage their projects. However, there are still programmers who want to know more about its features.
Waterfall is often called the traditional methodology of software development. It originated in the 1950s. The methodology was initially used in hardware development, but after the invention of software development, it was applied to this industry. Today Waterfall remains one of the most popular process models. It is strongly criticized by some programmers that prefer to use Agile methods. However, most software development companies still use Waterfall because it is well known.
As you can imagine, proper planning is a must in the waterfall system. A project’s requirements must be clear up front, and everyone involved in a project must be well aware of those requirements. Each team member should also understand what their role will be in the project and what that role entails.
Phases of waterfall project management
The specific phases of the system vary somewhat from source to source, but they generally include:
1. Requirement gathering and documentation
In this stage, you should gather comprehensive information about what this project requires. You can gather this information in a variety of ways, from interviews to questionnaires to interactive brainstorming. By the end of this phase, the project requirements should be clear, and you should have a requirements document that has been distributed to your team.
Using the established requirements, your team designs the system. No coding takes place during this phase, but the team establishes specs such as programming language or hardware requirements.
Coding takes place in this phase. Programmers take information from the previous stage and create a functional product. They typically implement code in small pieces, which are integrated at the end of this phase or the beginning of the next.
Once all coding is done, testing of the product can begin. Testers methodically find and report any problems. If serious issues arise, your project may need to return to phase one for reevaluation. In this phase, the product is complete, and your team submits the deliverables to be deployed or released.
The product has been delivered to the client and is being used. As issues arise, your team may need to create patches and updates may to address them. Again, big issues may necessitate a return to phase one.
Waterfall model is based on three main principles: low customer involvement, strong documentation, and sequential structure. Let’s look at them in greater detail.
• Project progress is easily measurable as all involved understand the schedule and key deliverables in advance of the project’s start.
• Alignment between clients and project developers occurs at the earliest stages of the development cycle. As such, clients can take a more hands-off approach as the project progresses by taking part in reviews and status updates without having to continually collaborate with developers.
• The methodology allows for some flexibility. For example, testers can prepare relevant scripts while development is underway using the documentation created in earlier stages.
• As the design is generally a separate stage, Waterfall allows for the intricacies of complex projects to be properly planned out prior to the beginning of development.
• The risk of having to spend time tinkering with pieces of code to add it into the large project application is reduced as all stakeholders in the project are fully aware of the project’s demands and the technologies used in its creation from the offset.
• Waterfall, by its nature, requires project planners to gather specific details and documentation from the off, which can prove intimidating to clients who have little experience in software development. As such, the methodology raises challenges in terms of helping clients understand what they are actually getting and how the information provided helps the project reach its goals.
• Changes in project requirements are often difficult to implement, particularly once development is underway, as the entire project is carefully planned based on the documentation and requirements gathered in the early phases.
• As testing tends to occur as a single stage at the end of the development lifecycle, early bugs go undetected, potentially affecting later code to the point where they create large problems.
• Projects can end up being delayed if a particular stage is not completed within the expected timeframe, which prevents the next stage from proceeding.
• Developers can often not go back to the previous stage if an issue is discovered when using the Waterfall methodology. In some cases, a single problem can cause the entire project to go back to the first stage.
2000+ Agile Method
What is the Agile project management methodology?
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
The term agile (sometimes written Agile) was popularized, in this context, by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.
There is significant anecdotal evidence that adopting agile practices and values improves the agility of software professionals, teams and organizations; however, some empirical studies have found no scientific evidence.
Agile project management method is an iterative, team-based approach to development. This approach emphasizes the rapid delivery of an application in complete functional components. Rather than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, planned at the start of the sprint. Deliverables are prioritized by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritized and the information is used for future sprint planning.
As work is completed, it can be reviewed and evaluated by the project team and customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of customer involvement throughout the project, but especially during these reviews.
Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Let’s look at them in greater detail.
• Clients are engaged throughout the entire development lifecycle, offering a greater understanding of the work being delivered and allowing for faster decision-making where required. Further, this engagement allows clients to take greater ownership of the project, thus making them more invested in its success.
• The flexibility of Agile allows for changes in project requirements to be implemented more effectively, thus preventing these changes from holding up other aspects of the development cycle.
• The iterative nature of Agile allows developers to create more basic versions of software that can be enhanced through later development work, thus allowing clients to begin marketing software earlier and provide it quicker, with later developments enhancing the product for the early user base while making it more attractive to latecomers over time.
• The increased collaboration at the heart of Agile fosters transparency on the parts of both client and developer.
• Testing is usually implemented into each Agile sprint, meaning bugs are spotted earlier and thus don’t cause problems later on.
• Not all clients wish to engage in development processes as frequently as Agile requires, which can lead to frustration on the client’s part, resulting in dwindling interest as the project progresses.
• Agile methodologies can sometimes be more difficult to explain that the Waterfall model, particularly when it comes to the concept of sprints and how the various traditional stages of development intermingle when using Agile.
• Costs can spiral if certain requirements are not completed within their assigned sprints, with too many missed requirements leading to new sprints being created that delay the project. Further, increased client involvement can have the downside of creating constant changes that lead to higher costs.
• Poor project management and anything less than a full commitment from all stakeholders can scupper Agile development, as disengagement leads to delays. For example, many projects employing Agile find they run into difficulty if the various teams involved in the project are not located within close proximity to one another, thus making the communication that lies at the core of the methodology more difficult.
• The focus on creating working software quickly can lead to poor documentation of what the end user actually needs to know to use it.
2020+ Data-driven Method
What is the data-driven project management methodology?
Software is eating the world, but we are not data-driven in understanding software development.
Data-driven method gained popularity in the last years with the help of Git popularity, when Github, Bitbucket and Gitlab convinced millions of engineers to store code in the could and open the opportunity for companies like Waydev, to track the output of the engineers and help managers make decisions based on real data and not by their gut.
The actual way, and how most of the engineering managers track their teams is by Agile method or Waterfall method but the data-driven method don’t replace any of this methods and comes with a real-time view of the actual work.
Either if you use an Agile method or a Waterfall method it will be impossible to see how the work is performing until the end of the sprint, at least one week, with a data-driven method you can see how the team is performing, day-by-day and come prepared in your daily sprints with concrete feedback on the work of the team.
Below it is an example from Waydev, the Work-log feature where you can see the output of each engineer, in real-time.
At the core of these features they use core metrics like new work, churn, legacy refactor, helping others and impact.
All the players in this market have different features of tracking the output, but all of them are focusing on the most important aspects of having a successful team. The most common features are for daily-standups, one-to-one meetings, history of the work and benchmarking your starts with the industry.
I don’t see how an engineering manager would not start using valuable data in his decisions. My suggestion is to try any of these products and choose to use one which fits better for your needs, like this you will see how much the productivity will grow.