Category Archives: Scrum

Scrum On

Software Development Methods

Wow, look at us, huh? Almost a month later, another post appears! This month (I guess I’ve moved to monthly blogging… We’ll tighten it up, I promise) has been mostly about the different ways to go about developing something. Neat, huh?

So far, we’ve talked about waterfall, agile, and the latest, scrum!

SCRUM

Scrum builds upon each previous development methodology, and is a natural extension of Agile. It is not, however, ‘better’ than agile, but simply different. No one methodology is the best, but some perform better than other in certain circumstances. Scrum is the latest methodology that my class has been learning about, and as such I decided to take some time to further look into it.

Scrum in 20 minutes is a video I came upon while looking for examples. It explains the process of scrum, why it is used, and how it is different to other methodologies. As well as this, the video contains a few examples of how using scrum has been beneficial.

One of the reasons that I decided to watch this video was that it simply looked professional. It was well polished, and felt like a finished product. A lot of the times, when I go looking for academic supplemental material, I’m presented with a sea of the same animated characters, slideshows, and whiteboard-style videos, so this one was a VERY nice change of pace. More of these, please! (I have some words with whoever invented PowToon).

This video really helped me to see how Scrum is applied to a real life example. I also appreciated the refresher on the process as a whole, but having real-life examples of a full sprint, planning, and what each of the team members’ roles contribute was really helpful in better understanding Scrum as a whole.

Something that I realized while watching the video, was that Scrum does not have to be software development specific. I play a lot of optimization games, and something like scrum just feels extremely organized, and is something that I feel is worth applying, at least in terms of concept, to more of my life than just this one small facet. Organization and goal setting is important in almost everything we do, and Scrum is just one way to do that, but it has been refined over multiple years of trial and error.

I am excited to apply scrum to future projects, and look forward to the increased organization that a solid planning methodology will bring to the table.

This concludes my mandatory blog post of Quarter 2 for the semester.

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Working in Agile and Scrum Teams

Source: Hapticmedia and The Scrum Guide

Agile is a methodology that allows for iterative development that is constantly being improved upon for the best product and efficiency. Those who use Agile follow the manifesto, consisting of 4 values and 12 principles of best practices. 

The values are: 

  1. Individuals and Interactions Over Processes and Tools
  2. Working Software Over Comprehensive Documentation
  3. Customer Collaboration Over Contract Negotiation
  4. Responding to Change Over Following a Plan

The first value relates to prioritizing how the team is working as a whole rather than following a strict set of protocols that may hinder productivity. The second value focuses on getting a working product to show the customer over spending too much time on documentation that does not progress the project. The third value involves the customer in the development process, allowing for constant feedback and a product the customer will love. The fourth value is similar to the first, reacting to changes the team needs to make to be more efficient and create a working product is more important than sticking to a plan created in the beginning. 

A type of the Agile methodology is called Scrum. Scrum breaks down a project into small “sprints” where the team works on a small increment of the whole project. In each team there are the Developers, a Product Owner, and a Scrum Master. The Product Owner acts as the communicator between the developers and the customer and maintains a priority list of what needs to be done. The Scrum Master oversees the developers and ensures they are being as effective as they can be. During each sprint, there are 4 main components, the planning meeting, the daily scrum, the sprint review, and the sprint retrospective. The planning meeting happens at the beginning of the sprint and is where the team decides what they will accomplish this sprint. The daily scrum is a daily meeting where everyone decides what they will do that day and what they will do better from the day before. The sprint review is a meeting with the customers/stakeholders where everything that was accomplished is presented. The sprint retrospective is a meeting between the scrum team where they discuss what went well overall and what needs to change for the next sprint. 

Agile is a very effective methodology for software development. Over 85% of developers use it and it improves delivery time and team morale. It also allows for all team members to be on the same level where everyone is important and always making valuable progress. I hope to be in a team that uses Agile because it is the most effective compared to other methods of software development, like Waterfall. I am looking forward to experiencing the Scrum process first-hand in the Software Development Capstone next semester and I have high hopes of what it will do for my long term career.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

My first sprint was a trial of figuring things out. Had to get accustomed to my team members and the program that was already created before. I was assigned to the reporting system and going in with my teammates and I didn’t know how far along the project had been. We had to first get settled and understand what updates needed to be done to complete our first sprint. Our sprint planning went well we understood the issues left before from a different class could be used for our sprint in this class. We all selected an issue that each one of us would resolve including some minor ones that came later on. I was chosen to Determine the startup procedure for MongoDB and RabbitMQ in the development environment. 

At first, I was confused with understanding what I had to do but after reading the comments made I began to understand what needed to be done. It was more of a test by creating another docker-compose file to run the Rabbimq without the backend. I created a devDocker-compose to achieve my goal. I then created another index.js file. I did this to run the developer versions or production of the up scripts. I did minor updates during the sprint including updating devcontainer so it would work better on Macs. There were several things we had to update so we split up the work and committed the corresponding ones to the main. I helped my teammates in their projects as well by working in their branches and accepting their merges when needed. As a team, we worked united and we always made sure we were all on the same page. During this sprint, we learned new things that we could incorporate into our team including updating each other on what we are working on today to be on the same page. We never let any team get lost and we were always there to pick each other up. One moment I could recall is that one of our member’s computers was having issues and we all as a unit came to find the issue which we did. Even for minor mistakes like commit messages, we made sure to edit and fix them to pass the pipeline. 

The pattern I would choose from the Apprenticeship Patterns book would be to expose your ignorance. It’s great to work alone and do your own thing but if you get stuck don’t be scared to get help from teammates instead of figuring it out alone. It’s great to get feedback and ask questions to everyone. This pattern is key for the growth of a developer and being able to be humble when addressing gaps of knowledge. You don’t have to act like you know everything because of pride or embarrassment but be willing to learn and be curious without fear. During this sprint, if I didn’t ask for help in certain scenarios I wouldn’t have known how to continue my project but being able to discuss boosted my work progress. When you are first joining a team you want to be reliable instead of a burden but asking questions as a whole will strengthen your team. During this spring I wouldn’t have hesitated to ask more questions that I had figured out on my own.     

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

Takes on how to become an effective team

URL: https://www.youtube.com/watch?v=7zDX8VqvBa0

I came across another interesting podcast episode from Beyond Coding. This time, the episode I watched focused on Effective Product Teams, featuring Anne Kooijman, currently a Product Owner at Coolblue. The conversation between her and the host covered various topics related to team management and ways to build an effective product team.

The reason I chose this resource is that it provides real-world solutions to straightforward questions. The host, Patrick Akil, mentioned that he recently took on an assignment as a Project Manager. He asked many interesting questions, some of which I had myself.

A couple of specific points caught my attention, and I’d like to share them with you. The first was Anne’s perspective on what is required for a team to deliver quality work. She said, “Give them the necessary tools and the theoretical background.” I found this fascinating because you shouldn’t give developers half-baked solutions or dictate how to solve a problem. Doing so might make it harder for them to translate someone else’s idea into code. Instead, provide them with the necessary knowledge and tools to figure out solutions on their own and let them do it.

Another topic Anne discussed was how companies sometimes deviate from the core principles of Scrum and the potential outcomes of those deviations. She pointed out that there’s no issue with straying from what the “constitution” of Scrum dictates if it leads to improvements. This is intriguing because Scrum is meant to provide a framework, not a rulebook. Different teams consist of different people who may respond differently to certain changes. Personally, I imagine that I wouldn’t react well to constantly changing sprint durations.

They also discussed goal-driven teams and how having goals is essential for team effectiveness. This resonates with me, as it aligns with a practice, I adopted this semester. This isn’t meant to criticize how others manage their responsibilities but to connect the podcast’s ideas with my own experience. For the first time this semester, I decided to only consume entertainment during my free hours once all my tasks were completed. It sounds simple and cliché, but it works—just like Scrum. Teams need a singular goal, and the focus should remain on that goal.

This brings us to the final topic: timelines, and how even flexible and inconsistent timelines can be better than having none. This concept challenged something I’ve always believed—that if you’re going to do something, do it right and to the best of your abilities, or don’t do it at all. However, I realized that some flexibility in timelines is necessary to allow for adaptation and growth.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Masters in Scrum

One method I’ve encountered repeatedly in both my coursework and during discussions with peers is Agile—specifically, the Scrum framework. To better understand it, I recently read an article titled “Scrum Mastering the 3 Pillars, 5 Values, and 7 Key Principles of Agile Project Management”, which provides a clear breakdown of how Scrum works and why it’s so effective in software development. I found this resource insightful, and it’s something I can definitely apply in my future

The article explains the fundamental elements of Scrum, which include the 3 Pillars, 5 Values, and 7 Key Principles that form the foundation of this Agile framework. The 3 Pillars—Transparency, Inspection, and Adaptation—ensure that the process is open, regularly assessed, and flexible. The 5 Values—Commitment, Courage, Focus, Openness, and Respect—help create a collaborative and supportive team environment. Finally, the 7 Key Principles emphasize continuous improvement, self-organizing teams, and the importance of simplicity in problem-solving.

I selected this article because, as a beginner in computer science, I wanted to understand how project management frameworks like Scrum can be applied in real-world software development. Being new to coding and programming, I often feel overwhelmed by the amount of information and tools available. Scrum, with its structured approach, offers a clear way of organizing tasks, fostering teamwork, and ensuring that progress is continually monitored. Learning about Scrum is relevant to my future career because it’s widely used in the tech industry, particularly for software development and managing complex projects.

From reading the article, I gained a solid understanding of the core principles that make Scrum effective. The 3 pillars stood out to me, especially Transparency. As a student, I can relate to the importance of transparency in team projects where communication is key to understanding who’s doing what, when, and how. Inspection and Adaptation also made me realize how crucial it is to frequently check our progress and be willing to change course when necessary, which can save a lot of time and effort in the long run.

The 5 Values were a reminder of the importance of collaboration and maintaining a positive, respectful team environment. These values are essential, not just for Scrum but for any professional setting. I particularly appreciated the focus on Courage, which resonated with me as I’m still learning how to approach new and challenging problems in my coursework.

Finally, the 7 Key Principles reinforced the idea of simplicity and the need to avoid overcomplicating solutions, something I’ve noticed in my own work when I get caught up in trying to build complex solutions rather than focusing on what’s truly necessary.

I plan to apply the principles of Scrum, especially the importance of adaptation and simplicity, in my future projects. Whether it’s a group coding project or individual work, Scrum’s emphasis on regular inspection and continuous improvement will help me ensure that I’m always learning and adjusting as I go.

Resource:

“Scrum Mastering the 3 Pillars, 5 Values, and 7 Key Principles of Agile Project Management”

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

To Be Agile

I recently came across a blog post on LucidSpark titled What Is Agile Methodology? that explains the basics of Agile and its role in modern software development. Agile is a project management and software development approach that emphasizes flexibility, collaboration, and customer feedback. The methodology breaks down large projects into smaller, manageable chunks called sprints—usually lasting a few weeks. This approach allows teams to adapt quickly to changes, make continuous improvements, and deliver working software regularly. The blog goes on to explain the Agile Manifesto, which highlights values like individuals and interactions over processes and tools, and customer collaboration over contract negotiation.

I chose this article because it offers a clear, easy-to-understand explanation of Agile, a methodology that I’ve heard about a lot in my software engineering classes and in discussions about software projects. I wanted to learn more about it and see how it’s used in real-world development, especially since I might be using it in some of my future group projects. The post helped clarify some of the concepts I’ve learned in theory and gave me a better understanding of how Agile works in practice.

One of the most interesting takeaways from this article was the emphasis on adaptability. In traditional project management, there’s often a lot of upfront planning, but Agile is all about being able to adjust quickly to changes—whether that’s changes in customer requirements or new technologies. I realized that in software development, the ability to pivot and change direction is just as important as having a solid plan in the first place. This idea of “failing fast” and improving iteratively really resonated with me. I’ve noticed that when I work on assignments or personal projects, sometimes things don’t go as planned, and it’s frustrating to try and stick to a rigid approach. Agile’s flexibility seems like a better way to handle those situations.

Another part of the article that stood out was the focus on collaboration. Agile teams work closely together and communicate regularly, which is different from the more isolated approach I’ve seen in some projects where team members work separately and only come together at milestones. The post explained how frequent communication, daily stand-ups, and collaboration with customers can help create better products and avoid misunderstandings. This is something I want to keep in mind for group projects, especially in coding assignments where communication can make a huge difference in the quality of the work.

In my future career, I plan to apply what I’ve learned by adopting some Agile practices in my own projects. I want to be able emphasize collaboration and open communication in group assignments, which could lead to more efficient and effective teamwork.

Resource:

https://lucidspark.com/blog/what-is-agile-methodology

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Scrum

Pushing the Ball Forward Together

Photo by Ollie Craig on Pexels.com

Hello Debug Ducker here and recently I studied a framework used by Software Developers referred to as Scrum. Scrum is a framework that is meant to help teams find adaptive solutions for complex tasks. In layman’s is, it is a way to get hard things done small pieces at a time.

If you are wondering if Scrum is an acronym, well no it is a reference to a scrum in rugby in which teams in rugby work together to move the ball forward, which relates to teams working together to move the product forward.

The idea of Scrum is based on empiricism which is a theory that knowledge comes from experience and lean thinking to which means to focus on the essentials. The Scrum framework consists of the Scrum Team which encompasses the Product Owner, Developer, and Scrum Master who have different accountabilities on a project.

There are also very important pillars to take into account when talking about sprint which are Transparency, Inspection, and Adaptation, which can’t work well without each other. Inspection and adaption work as there is a lot of ongoing feedback during the process.

I was interested in the topic as I have recently learned about it in my software processes class and wanted to share my thoughts on it. As my understanding of it goes, it is based on reducing complexity by having different roles and small teams to handle the task. It also has steps that should be followed that are in specific time boxes, time boxes being the maximum amount of time the step can go on. The Scrum involves a time length for the task, referred to as a Sprint, that goes on specifically for 1 month or less.

I can see myself using this framework in the future, as it helps make those complex tasks easier to handle, especially in group projects. If a task is too great, then perhaps Scrum should be used to make sure the task is not as bad and easier to handle for the groups’ sake. Even though Scrum in this instance refers to Software Development, I can see it being used in other possible fields that involve working together, but that’s just me. There is more to Scrum than just what is referred to here, there is a free guide online that I recommend any viewer interested in software development to check up known as the Scrum Guide that can guide you through it. The link to is down below.

The Scrum Guide

 That will be all from, have a nice day.

The 2020 scrum GUIDETM. Scrum Guide | Scrum Guides. (n.d.). https://scrumguides.org/scrum-guide.html#the-sprint

What is Scrum?. Scrum.org. (n.d.). https://www.scrum.org/resources/what-scrum-module

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Capstone: Sprint Reflection 6

Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.

I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.

I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.

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

Sprint 5 Learning Reflection Blog (4/12/17)

I can’t believe this is our last sprint! It went by so fast; it feels as though we are just starting. Overall it was definitely a good learning experience being able to collaborate with a real organization. Our group had a good conversation with our professor about this whole sprint experience with the AMPATH group and it kind of prepares us for what it would be like working for a company in the real world as a full-time job. Over the duration of 2 months we only were able to resolve one issue. By face-value it might sound bad, but we spent the majority of the time trying to understand the language of Angular2 and the framework of how everything operated. If you think about it, my experience with this is pretty similar to what it will be like when working for your first company; most of the time will be getting used to the coding language and the framework. Prepare to be doing that most of the time before you even begin coding anything!

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