Fundamentally Agile is a very flexible and effective methodology that allows teams to continuously provide a working model of their respective project. When compared to the Waterfall methodology, Agile may seem like a flawless approach to team development and management, however this comparison to Waterfall fails to capture Agile’s flaws. Ideally, by understanding Agile’s feats and flaws, teams can make the most of the methodology.

Agile works best when all members deliver their respective parts of the project on time. This creates pressure on the developers to reach that time quota, as a result they may be more inclined to ‘cut corners’ so to speak while developing their part. Creating faulty code (or a general product) may lead to future issues, which would likely lead to sprint backlog bloat, so the development methodology must balance the value of the work being created and the time being spent to create the aforementioned work.

On the topic of time management, Agile does not offer much flexibility while creating sprints. Sprint length is determined towards the beginning of development, this itself is an issue as developers lack the foresight to allocate enough time in a sprint to take on larger-scale projects. Sprints encourage segments of digestible work for the developer, as Bryar and Carr mention in the article Have We Taken Agile Too Far?, “rather than take the time and uncertainty to develop a new capability, they go with the skills they currently have” (Bryar & Carr). Due to time constraints, developers settle with what they’re most comfortable with, as opposed to seeking potentially more effective solutions. This damages the final product as it heavily depends on the developers’ current experience and does not promote research.

One solution to this issue would be shifting to the Epic-model. Here developers won’t face an imminent time constraint that sprints impose, rather they will take a task (a story) and aim to complete it before the team moves on to the next step (the epic). This type of work structuring does not intrinsically have a set time limit but can be integrated within the Agile methodology. The goal of combining these two types of work structuring is to create a process where developers can have assigned tasks that are components of a larger task, AND to have a flexible time limit before moving on to the ‘larger task’. Another solution would be to fundamentally change how Agile works within a team. Currently, there are very few exceptions to change the duration of a sprint period, so to shift to a variable duration of each sprint would change how Agile works. A downside of doing this would be removing the consistency between sprints, but the benefit of that is that developers may be able to take on more work or do more research into their respective tasks before delivering their first working model. As a development methodology Agile should benefit the developers, therefore shifting from a rigid (preset) working period may increase the quality of work.

-AG

Source:

https://hbr.org/2021/04/have-we-taken-agile-too-far

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

While attending my previous university, Becker College, I was introduced to Scrum, Agile, and Kanban with very surface-level information. As we progressed through this current semester, my knowledge of both Scrum and Agile increased, with my knowledge of Kanban tailing behind. So I seek to answer the question of ‘What is Kanban’?

Kanban, similar to Scrum, is a type of work structuring that places importance on visual responsiveness and flexibility. Scrum and Agile run on the idea of sprints, which Kanban does not naturally have, but rather it opts to focus on a time cycle. Time cycles measure how long it will take a single task to move through all stages of development. A potential flaw here would be that if the team agrees upon many stages of development, such as adding multiple testing stages, then the average time cycle will take longer. By not imposing a static time limit, such as those provided by Sprint structuring, it encourages developers to put as much effort as possible into their respective task(s). The key to an efficient team would be to optimize these time cycles and get their average down to shorter periods while maintaining the quality of work.

Within the development process, each task is represented by a card and will move through the Kanban board as it advances in the development cycle. This board helps create the visual responsiveness that Scrum lacks. If a card is stuck in one phase of development, then fellow developers may take notice and help push it to the next stage. While visual responsiveness does help to grant a sense of worth seeing tasks being completed, it best serves as a collaborative tool between developers which further increases team efficiency.

Kanban would be my preferred choice of work structuring as I find that the Kanban board is an incredibly useful tool to both track and collaborate with your team. However, one glaring issue I do have with Kanban is the lack of a direct CD (continuous delivery). Scrum will have the Sprint Review and Retrospective which gives the development team a chance to show their current working model of the project and get suggestions for it. Kanban lacks this dedicated period to show the project and communicate with their partner. This runs the risk of high-effort work being rendered useless as it’s not what their business partner had in mind. Additionally, with the lack of a Retrospective, the team will not have a dedicated period to reflect on their progress and comment on places they may optimize their work. A solution here would be to create sprint-like periods where no work is due, but at the end of the period, developers will have both a review session with their business partner and a retrospective within the team. This increase in general communication will ensure the product will be created effectively and will meet all requested specifications.

-AG

Source:

https://www.atlassian.com/agile/kanban#:~:text=What%20is%20kanban%3F,of%20work%20at%20any%20time.

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

When our class was being introduced to GitLab, and how to post topics on an issue board there were a couple of terms present within the menus that we didn’t go over in class. These terms are story, epic, and initiative, all of which relate to each other. Conveniently all of these terms build off the formers’ progress, and can easily be slotted into a DevOps-esque working environment.

The first of these terms, a story, is what we are most familiar with as it’s another term for an item selected from the Sprint Backlog. A story is a unit of work that can be completed in a one to two-week span. These often come from user feedback, meaning that the product has seen some use outside of development, however stories can originate internally (just like items on a Sprint Backlog). Stories are supposed to be smaller so developers can take multiple during one sprint with the goal being a handful of stories contributing to an epic.

The next term, an epic, is composed of several stories and aims to explain something larger during the development cycle. For example, if you are developing an app that doesn’t have features such as colorblind compatibility, text zoom, and a narrator, then each of these additions could be a story (can be an epic itself depending on the workload). The epic here would be ‘Improving accessibility’.

The final term, an initiative, similar to the former is composed of the prior terms, in this case an initiative is formed of several epics. These run for a minimum of half a year and can continue well past one. These serve to highlight the direction in which the project is aiming to head towards. Continuing the example from the previous term, if we add epics such as ‘Marketing towards non-likely users’ and ‘sign-on bonuses’ it can fit into an initiative that may be ‘increasing user engagement’.

For the purpose of this class, stories are going to be what we encounter the most, with maybe an epic or two depending on the scale of a project. What I’m curious about is whether these terms can be applied to the capstone project course. That course specifically will focus on working on a much larger scale project, so keeping track of tasks via stories/epics/and initiatives could prove to be effective. A reason why I understand these terms not being taught within the course is due to scaling. We focus on learning agile development as it is much more flexible for both smaller and larger projects, meanwhile an epic-based development process may only see great benefits from working on a larger project.

-AG

Source:

https://www.atlassian.com/agile/project-management/epics-stories-themes

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

While searching for a first topic to write about, the question in mind I wanted to answer was “What is the formal definition of the processes we have been following” and “How does it all relate to what we’ve learned”. This question was answered by the following article which introduced me to the term DevOps, which is abbreviated for Development and Operations.

The following article grants a brief definition of what DevOps is, but most importantly shows the core values that all tie this subject together. Most of these core values we went over in great detail within our class, such as Continuous Integration and Deployment, while others were completely new to me such as Infrastructure As Code (IaC). This simply put focuses on how we interact with Infrastructure and looking at areas in which it can increase efficiency through automation.

Beyond showing the core values, this article speaks on the best ways these are applied. Some of these topics are implied such as collaboration through Agile Development and Continuous Integration and Development, but there was one I did want more clarity on and that is automation. Fundamentally I understand that teams can use automation to increase efficiency, however it does seem counterintuitive in an environment that promotes teamwork. On one hand, you can increase efficiency by letting automation ‘do its thing’ with little supervision, but that may create future errors. These errors and subsequent corrections will reduce efficiency later in development. If you allocate one (or more people) to frequently supervise the automated process, then there’s less of a risk of something going wrong, but you lose the efficiency that one (or more) people could’ve provided. By arguing this I’m not stating that automation does not have a place within DevOps, but that it may be a dangerous inclusion if not accounted for correctly.

Overall I found this article useful in expanding my knowledge of what we’ve learned throughout the semester, the visual(s) provided showing each component of the DevOps processes did help too. One thing that I would suggest for future semesters is maybe looking into how automation can be integrated into DevOps and appending it to your current lectures/activities? I think the curriculum for CS-348 is very good as of now, but adding a unit about automation could maybe help answer some of the questions I asked and potentially could help future students be ready for what they may see in the workforce (beyond college). Lastly, the source in which I retrieved this information seems to be a post on LinkedIn by a company named Quality Matrix Group, so there seems to be plenty of credible information within the post.

(Bonus points for them being based locally in Westborough MA!)

-AG

Source:

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