Learning the differences between Waterfall and Agile and choosing the methodologies best suited for the next project!

For this week I have decided to write about 2 different methodology, Waterfall and Agile. Which one is the best and when can we use each of them? I read a blog about both these methodologies and I am going to explain which one is the best to use on different cases.

In the world of project management, two prominent methodologies, Waterfall and Agile, offer distinct approaches to achieving project success. Imagine making a ham sandwich to grasp the fundamental differences between these methodologies. In Waterfall, you follow a linear process, just as you would follow a recipe step by step. Each stage, from gathering requirements to maintenance, proceeds in a clear sequence. However, like making changes to your sandwich after it’s complete, altering anything in Waterfall can be challenging. This approach demands a clear vision from the start and is ideal for projects with well-defined requirements and minimal changes expected, such as building a bridge.

On the other hand, Agile is akin to a group of friends embarking on a road trip with flexibility in mind. Instead of a fixed plan, Agile projects are divided into short sprints, typically lasting two to four weeks. After each sprint, the team evaluates their progress, incorporates feedback, and adjusts their course. Agile’s adaptability is perfect for projects with evolving requirements, quick adaptability, and a need for continuous feedback, as seen in software development.

Both Waterfall and Agile have their advantages and disadvantages. Waterfall offers well-defined project phases, clear documentation, and straightforward cost estimation. However, it struggles with making changes and may not suit projects with uncertain requirements. There’s also a risk of a mismatch between the initial design and user needs.

Agile, on the other hand, excels in accommodating changes, iterative improvements, team collaboration, and dynamic resource allocation. It is, however, susceptible to chaos without proper management and might lack comprehensive documentation. Setting a fixed price or timeline can be challenging, and there’s a risk of scope creep.

Choosing between Waterfall and Agile depends on your project’s nature. Waterfall is best for projects with clear requirements, usability tied to the entire deliverable, strict phase dependencies, and linear progress. Agile shines in situations where requirements may evolve, quick adaptation is essential, continuous feedback is necessary, and flexibility is key.

Selecting the right approach is not about determining which method is superior but rather about choosing the one that aligns with your project’s unique requirements. To excel in either Waterfall or Agile, consider using project management tools like Motion, which offers features that cater to both methodologies. Motion’s intelligent calendar and task manager assist with scheduling and prioritizing tasks, while its flexibility makes it adaptable for Waterfall’s structured phases or Agile’s iterative workflows.

In conclusion, project management is not a one-size-fits-all endeavor. Waterfall and Agile are two distinctive methodologies, each with its strengths and weaknesses. The key to success lies in understanding your project’s needs and selecting the approach that best aligns with those requirements. With the right tools and a clear understanding of these methodologies, you can navigate your project to success, just like choosing the right footwear for your journey – be it hiking boots or running shoes, tailored to the path you plan to tread.

Resources: https://www.usemotion.com/blog/waterfall-methodology-vs-agile

From the blog CS@Worcester – Coding by asejdi and used with permission of the author. All other rights reserved by the author.

This week in class we discussed the process of scrum. Scrum is an agile framework that can be applied to any project or product development effort. It promotes flexibility by encouraging openness, inspection, and adaptation. This loose framework allows teams to adopt it and make changes that benefit their team’s workflow. Unlike the waterfall development approach, where each step must be completed before moving to the next, a scrum team works in small increments over a smaller period. That period consist of the sprint, sprint planning, daily scrum, sprint review, and the sprint retrospective. The scrum event that piqued my interest after reviewing it in class was the daily scrum.

The blog, “Ten Tips for More Effective Daily Scrums” by Mike Cohn,  brought up some interesting and important points. The ten points that were mentioned were: (1) talk almost exclusively about the work of the current sprint, (2) limit discussion to what was and will be accomplished, (3) talk about impediments, not “blockers”, (4) give people something to say about their work not directed toward the sprint goal, (5) give team members a way to indicate when someone is rambling, (6) have people point to what they’re working on, (7) update the sprint backlog but don’t let numbers become the focus, (8) vary how the daily scrum is conducted, (9) keep everyone guessing as to who will speak next and (10) make it painful to ramble too long. 

During the summer, I had the chance to work on software for our university. It was my first time experiencing the scrum workflow. Our team implemented some of these tips during our daily meetings, mainly points 1, 2, 3, and 6 so it was interesting to hear the author’s perspective on what other methods make a daily standup more effective. The points that cater towards diminishing rambling were a fascinating read. While discussing methods to indicate when a member is rambling, examples of using buzzers, holding up rubber hats, and using dolls were mentioned. Although strange to me, those methods show that different teams use what’s best for them. Cohn’s ninth point about keeping everyone guessing as to who will speak next discussed more methods to make the meeting fun to help avoid tuning other members out while they are speaking. While working on software in the summer, I didn’t think about fun ways to improve daily scrum because it was all so new to me. It makes sense to implement something to make the meeting more engaging because, like he said, I did find myself zoning out at times. 

Because I have such little experience with a scrum team, I enjoyed reading about possible ways to improve a team’s process .It helped me realize just how different another team’s methods could be and what I could possibly implement in the future.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

In the dynamic world of software development, finding the right approach to tackle complex projects and manage uncertainties is an important task since we always need to figure out ways of maneuvering around problems or solving them if need be. One such approach having came across in my searches that has gained recognition for its adaptability and risk management capabilities is the Spiral Model. This Software Development Life Cycle (SDLC) model is something that provides a systematic and iterative method for building software, allowing developers to navigate through the challenges of large and intricate projects.

In the blog post, it delve deep into the intricacies of the Spiral Model, it tries exploring its phases, characteristics, advantages, and disadvantages.
By the end, you’ll have a comprehensive understanding of this powerful SDLC model and its potential applications, helping you make informed decisions about its use in your software development projects. from what i’ve uncovered as to why the Spiral Model is often referred to as a “Meta-Model” and discuss the scenarios where it shines, it’s most likely because of it’s nature to incorporate multiple approaches, being able to seamlessly integrate concepts from other SDLC models, utilizing a step wise approach almost similar to the classic Waterfall method- with every loop representing some kind of a step or phase that’s completed in the development process.

Following that, is usually the Prototyping model/technique; like the name implies we make a prototype model right in the beginning to have something of a baseline to draw on- the prototype is developed at each beginning phase, providing a tangible solution to resolve any risks that may crop up. the iterations in the spiral model can be thought of as evolutionary biology through which the complete systems we have are built.

The primary focus of the spiral model is usually risk aversion and management- by addressing risks at each and every phase- it makes sure that any risks or uncertainties software development cycle is usually kept at a minimum. last but not least is the adaptability of the spiral method- it’s iterative and incremental approach can be useful for any changing requirements or unexpected events that may crop up

I selected this resource because the Spiral Model is a fundamental concept in software engineering. Understanding different SDLC models, their advantages, and disadvantages is crucial in the software development field. The Spiral Model’s focus on risk management and adaptability piqued my interest as it aligns with the evolving nature of software projects.

https://www.geeksforgeeks.org/software-engineering-spiral-model/#

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

This week in our Software Process Management, we delved into the world of Scrum, an agile project management framework that’s been gaining a lot of attention in the software development industry. Scrum is all about fostering collaboration, flexibility, and adaptability in a project, and we explored the crucial roles that customers and developers play in planning and completing each sprint.

Let’s start with a quick overview of Scrum. It’s a framework that emphasizes incremental and iterative progress. Instead of a lengthy and rigid project plan, Scrum divides the work into smaller, manageable pieces called sprints. Each sprint typically lasts around two to four weeks, during which a specific set of features or tasks is tackled. This approach allows teams to be more responsive to changing requirements and deliver valuable software faster.

Now, onto the roles:

1. Product Owner: In Scrum, the customer’s voice is represented by the Product Owner. This role is pivotal in ensuring that the team is working on the right things. The Product Owner collaborates closely with stakeholders to define the product’s vision, prioritize features, and create a backlog of tasks. They act as the bridge between the customer and the development team, answering questions and providing feedback.
2. Scrum Master: The Scrum Master is like the team’s guide, facilitating the Scrum process. They ensure that everyone understands and follows the Scrum framework, including the roles, events, and artifacts. Scrum Masters remove any obstacles or distractions that might hinder the team’s progress.
3. Development Team: As a computer science student, this is where you come in. The Development Team consists of professionals who do the actual work of creating the product. This can include software developers, designers, and testers. The team is self-organizing and cross-functional, which means they work together to complete the tasks committed to during the sprint planning. They are responsible for delivering a potentially shippable product increment at the end of each sprint.

In Scrum, collaboration is key. Customers and developers regularly interact during various ceremonies like sprint planning, daily stand-up meetings, sprint review, and sprint retrospective. This close collaboration helps to ensure that the product being developed aligns with the customer’s needs and expectations.

The sprint planning meeting is where the Product Owner presents the prioritized backlog items, and the Development Team discusses what can be accomplished in the upcoming sprint. This collaboration ensures that the team commits to a realistic amount of work and that the customer’s priorities are respected.

During the sprint, the Development Team is focused on delivering high-quality work. The daily stand-up meetings keep everyone in sync, and any impediments are addressed quickly.

At the end of the sprint, the team and the customer come together for the sprint review to demonstrate the work done. This provides an opportunity for feedback and adjustments based on the customer’s input.

Finally, the sprint retrospective is where the team reflects on their processes and identifies areas for improvement, making each subsequent sprint better than the last.

In conclusion, Scrum is an exciting and collaborative approach to software development that empowers both customers and developers. It ensures that the product remains aligned with customer needs while fostering a dynamic and adaptable working environment. As computer science students, this framework equips us with valuable skills for future software development projects. So, embrace Scrum, work closely with your team, and be prepared for a dynamic and rewarding journey in the world of software development.

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.

In the ever-evolving landscape of software development and its processes, version control systems play a pivotal role in ensuring code integrity when it comes to GIT, collaboration, and project management. Among these, GIT stands out as a distributed version control system with a rich history and a plethora of capabilities.

Going and delving deep into the fundamentals of GIT, i wanted to see the brief history behind GIT-i uncovered the facts of it being created by a man who went by the name of Linus Torvalds(the same guy who created the Linux kernel operating system). We explore how the GIT application revolutionized software development by supporting a non-linear process of operating within coding projects, being able to facilitate large project management as well as enabling code tracking. The blog post i went on was mostly a comprehensive guide to using GIT, the characteristics it has, the main components, commands which we’ve already covered in previous classes and activities alongside it’s various applications in other domains.

This seemed like a good choice considering it proves a sort of holistic view of GIT, of course another core feature that we use for software process management course- but more precisely being able to understand version control systems which is very crucial in the modern-day software development industry- providing valuable insights in terms of how GIT aligns with the key principals associated with software process management.

This resource does deepen my knowledge and understanding GIT’s role in software development and the uses/features- from the distributed model, branch management, better data integrity as well as being able to maintain parallel developments even in large code projects is an important takeaway from all of this. it can also be used for a variety of situations, whether it’s an open-source project, managing a product or handling real-time web pages and applications.

Since GIT is a useful application that i think will be an important part of future coding endeavors- i do expect to use it as a core tool taking into account it’s capabilities, the previously mentioned efficient branching to the merging and its distributed nature making it an essential resource and asset for maintaining quality code and ensuring good collaboration between team members. Knowing of it’s advantages and disadvantages helps to make informed decisions based on the situations one may encounter when using the application. To conclude with, GIT is a pivotal element in the world of software development. This resource provides a comprehensive guide to GIT’s features, characteristics, and applications- making this a highly powerful tool.

https://www.educba.com/introduction-to-git/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

This week in class, we went over the process of Scrum. Essentially, it is a loose framework on how a team should be working if they want the greatest potential from that work. I say ‘loose’ because it is loose, other than providing how the process should go, it allows teams to not only follow this framework, but adapt it and make it unique for their team and their work. I like this methodology for this reason. 

Scrum states that a team consists of developers, a product owner and a scrum master. Each has their own roles and responsibilities in the process. The process has five parts. The main event is the Sprint, which is a one month process where everyone is working in order to achieve a goal. Before this can happen, there is the Sprint planning, which is planning the Sprint and figuring out what needs to be done. Everyday before people start working, there is the Daily Scrum, a short meeting about what needs to be done that day. At the end of the Sprint, there is the Sprint review, going over the results and progress of the Sprint, and the Sprint retrospective, reflecting on the Sprint, as a whole and on individual parts, so that the next Sprint is better. Each part, and the roles, are described in detail in the Scrum guide.

In this blog post, Gregory Crown and Robert Pieper talk about how Scrum could be used outside the realm of software development, like marketing. I chose this particular post because not only does it connect to what we’re learning in class, it talks about how Scrum can be used outside of software development. In the post, they specifically talk about how marketing can use the framework of Scrum, and how it benefits from it. Pieper says that if it is a complex activity or problem, Scrum can help. He describes complex as something requiring a lot of opinions. He uses a water bottle as an example, saying one stakeholder may not like the color, another may ask what the purpose of the rubber thing at the bottom of it is, etc. Essentially, if you show the benefits of something, and there are a lot of different opinions on it, you can benefit from Scrum. He describes it in a very nice way, saying, “if you’re in a subjective environment where you’re getting a lot of opinions, use Scrum.” He says that if what you’re working on is something that just meets requirements, and then moves on, you don’t need Scrum. 

Personally, I agree with what he says. On paper, Scrum is an excellent framework for a lot of things. It has the layout on how to do things, but allows people to fill in the rest, however necessary for things to be done. It is a clean way of doing things, strict yet flexible. This shouldn’t just be a computer science thing either, if others can benefit from this, do it.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Considering Visual Studio Code is a staple, core feature of our class, i wanted to see if there was anything more to this application that would be the fundamental base block for our classes. From what i’ve learned, it’s a highly versatile and widely embraced code editor in the realm of software development-having been developed by Microsoft; being a FOSS(Free and open source software) which caters to the needs of developers on platforms like Microsoft/Windows, macOS and Linux, being significant in being able to provide a unified environment for coding, editing and troubleshooting any problems that may arise.

Some of the key features of the VS Code program includes the aforementioned cross-platform compatibility- being available for Windows, Linux and macOS, language support in that a variety of programming languages exist and extensions can also be installed for other programming languages that aren’t currently supported, a robust community that contributes to the vast selection of extensions that exist- alongside users being able to develop their own extensions- making this even more of a dynamic ecosystem that prove of mutual benefit for all.
VS Code also has built-in features- ranging from a console to Git support to a debugger. Besides those practical features, it’s the more broad applications- as VS Code finds a utility amongst most data experts, machine learning practitioners, system and cloud developers, and those working with various cloud providers.

I chose this text since it proves a valuable insight into the utilities of the Visual Studio Code program that we use daily in our class- in software process management having a variety of development tools at your disposal is somewhat critical as well as being to understand the capabilities and advantages of a tool like Visual Studio Code can and will prove useful in ensuring effective software development in most projects-as well as it’s versatility as a tool- performance and versatility are key considerations when choosing development tools, and these factors are closely tied to software process management’s goals of efficiency and effectiveness.

Taking this into account, i see these development tools not just as a means/way to write and edit the code for the projects but integral components that can streamline the software development process , this can align with the more efficient code practices in software process management that place emphasis on version control, debugging and code quality assurance. This knowledge reaffirms that selecting tools like VS Code is not merely a technical decision but one with broader implications for team productivity, code quality, and project success.

https://shiftmag.dev/vs-code-171/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

Overview

The objective of any scrum project management framework is to provide structure, fluidity, values and principles when completing a project. But all members of the project must equally pull their weight as well as know their role for the use of scrum to be efficient. A famous saying that relates to this is that “a team is only as good as its weakest link”. This phrase can be applied to basically any team, or group of people pulling for the same cause, in life. I think a scrum team is no different. This article I read by Dave West goes in detail about each role in a scrum team and how they tie in to each other for the team to collectively succeed.

Scrum Team Roles

Previously stated in class, the three roles of a scrum team are: the development team, the product owner, and the scrum master, with each role being just as important as the other. Starting with the development team, the developers are the ones responsible for working on the product. They are the ones bringing the blueprints and requirements, brought from the product owner, to fruition, essentially doing the dirty work of the team. The product owners show them what needs to be done and the deadline by which it needs to be done, and the developers take it from there. They self-organize and make their own decisions on how to complete the task. The development team could be of any occupation from writing, designing, programming, etc. The prime responsibility of a product owner is understanding business requirements and customer feedback. Based on those two things, the product owner is able to set the focus of the team based on meeting deadlines and release dates. It can sometimes be stressful and overwhelming for developers and product owners having to avoid falling behind. This is where scrum masters come in. The scrum master is the overseer, the piece holding everything together. The scrum master must have knowledge in development and product ownership. The development team and the product owner must be able to count on the scrum master for help and support. The scrum master is responsible for the scrum working as one and keeping the values strong in the team, sort of like a coach. The scrum master is usually the most active member of the scrum team.

Conclusion

As previously stated, I think for scrum to work, all members should be on the right pace. The minute that one role falls behind is the minute the framework fails. With much communication, and all members collectively on the right track, scrum is a very strong framework.

Article I Used

https://www.atlassian.com/agile/scrum/roles

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.

article link at the end

Overview

This week we began learning about different types of software methodologies, mainly focusing on SCRUM. Scrum, being one of the most popular software development organizational processes, has many factors to consider and to improve on. One of these pieces is the Scrum Meeting, a 15 minute or so meeting with your co-workers and “boss(es)” discussing the day’s work. However, such meetings can easily devolve or change into different forms; certain groups function differently. For example, one team of developers may find it beneficial to have shorter 5-10 minute meetings where there is less communication from each member. Another team may prefer longer meetings with each developer participating in a detailed discussion. But what should it really be about? How should people really be involved? This is where Mike Cohn’s article Daily Scrums: Synchronization Meetings, Not Status Meetings comes in.

What Not To Do

Cohn, a specialist in agile processes and helping companies utilize teams effectively, believes that many companies do Scrum meetings incorrectly. Most current scrum meetings involve each developer giving a report to their scrum master, whilst the other developers sit and wait their turn. Instead, he states that “the daily scrum meeting is designed for team members to synchronize their effort” (Cohn). This opposes the idea of such meetings being used to simply share what one is working on, and move on for the day.

Cohn’s Beliefs

Cohn believes that daily scrum meetings should have members enthusiastic about the project they’re working on with their team along with the progress being made. Such developers should also be sharing their progress and thoughts not only with the scrum master, but with the rest of the team as well. This encourages a broader discussion with more voices and teamwork involved. 

Cohn encourages Scrum Masters to participate in daily meetings, as they can then hear about impediments while also showing support for their team. Lastly, Scrum meetings should have brief updates that focus on what has been accomplished rather than what one spent time on.

Thoughts

I chose this article because it gives a truer, more refined approach to Scrum compared to the ones mentioned. Since I am a beginner to the idea and process of Scrum, I did not know of some of the problems with current iterations of daily scrum meetings. 

This article has been very helpful to me as it introduces what daily scrum meetings should be like. In the past, I had a misunderstanding about how Scrum meetings went; which lined up with what Cohn advised not to do. Although I have not had any real-life experience with Scrum meetings, I feel better prepared as for what to expect in future jobs. I will most likely be using this newfound knowledge in future projects, whether internship or job, big or small. I understand now that it’s best to look forward to scrum meetings as a time to come together and share, and to leave with excitement about progress.

Article: Daily Scrums: Synchronization Meetings, Not Status Meetings

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.