Sprint 6 Retrospective

Sprint 6 lasted from April 24th to May 6th. This sprint, my group and I had a main goal to focus on completing a powerpoint of our final project to present to the class on May 15th. Unknowingly, we instead spent most of our class time trying to merge and integrate our project with everybody else’s, which in turn broke some of our features and we never fully completed this integration.

While my teammates worked through those issues, I spent a lot of time trying to merge my completed dropdown button feature on to the main branch. This was also unsuccessful, partly due to merge conflicts since minor fixes and contributions were being pushed at the same time I was trying to push my own changes. My feature has been working on my own local branch for quite some time, in fact it was easier to develop the dropdown button than it was to merge it with everybody else’s project.

Working with professor wurst, I created a new branch that included my feature since attempting to push to the main branch wasn’t working. I tried creating a new folder, pulling the most up to date branch on a clean slate, then rewriting my changes in class which only took me about an hour. This plan was also unfortunately unsuccessful. Ultimately, as the deadline for the end of the sprint drew closer, we had to compromise on some of our more ambitious goals in order to start work on the presentation, which was meant to be the focus of the entire sprint.

I was still able to write about the ins and outs of my dropdown button, and I included screenshots from my local running branch. Thankfully, I believe I will have much to talk about. I will explain in depth some of the code lines and how they tie together with the modules and components necessary to make the whole thing work. I also want to include references to where I got the idea for the dropdown, since I stumbled upon a very helpful website that included HTML sample code for me to modify and trim down to fit our projects needs. I lastly will talk about how our work can be improved in the future. Our project contains a lot of filler text and our buttons don’t do much besides display text on the screen. To fit more specific needs, the text can easily be changed and more functions in the HTML can be added without necessarily changing the buttons around. Some ideas would be displaying various messages, videos, or information otherwise that would fit a more specific need depending on who will actually be using the app. Ill include a link to the presentation below this paragraph.


Overall I think we will get a good grade on the project, on our presentation, and on the class as a whole. I enjoyed this class more so than some of the others I took this semester, and I feel that I had more motivation to put in more effort into this class than some of the others.

Sprint 5 Retrospective

Sprint five lasted from April 8th to April 22nd. This sprint, we were focused on completing any big steps left that the project required in preparation for the upcoming sprint, where we will focus on our presentation. For the next sprint, we also have allocated enough time to polish minor details if necessary or finish any uncompleted project features.

My role this sprint was to implement a button that offered more buttons when pressed. This is useful in cases where we have multiple links or related content that can be categorized under a common theme.

To start, I created a new routing module and component for the new button. Yesenia helped me a lot with this task, since she set up the components for the existing buttons. She provided me with the correct commands, ng generate module file-name –routing and ng generate component file-name/sub-file-name. We worked together by bouncing ideas off as we pieced together the HTML and related programming for the new button. By the end of class, we successfully created a new button named dropdown that would rout to a new page, indicating the linked connection was successful.

This was not the full intention however, instead of bringing the user to a new page, the button should display three more options, each of which could have the capabilities to send the user to a new page. I created the three links, but I couldn’t figure out how to hide/show them upon triggering the dropdown button. I deduced that I would mostly have to play with the component.html file, I used the following link as a model of what I wanted to do.


In that link, scrolling down to the section titled “Drawer with explicit backdrop setting” I was able to look at the existing HTML and trim it down to fit the needs of the project. Mat-form-field and mat-option was specifically what I needed and what I used. With few modifications, and again some bouncing ideas from yesenia, I currently have the feature up and running. Some small things that I would like to get done if possible would be changing the color of the dropdown text to match the other buttons, as right now it is very distinguished looking. Also the manner in which the new options appear is not what I originally thought of, instead of creating a pop out list, I was thinking the buttons would appear on the sidebar beneath the dropdown button and would shift all other buttons below it down. The link below shows what I was originally thinking, but I couldn’t make that work as easily.


The reason why I decided to use the other link directly over this one is because I didn’t understand how the provided javascript worked enough to implement it in our project. I’m sure if I dedicated to it, I would be able to get the feature exactly how I want it, but this is not necessary and Ill only change the existing feature if we have extra time.

The focus for our next sprint will be coming up with our presentation and trying to merge our project with some of the other groups projects. We want to be able to combine our side bar with the team working on the search bar without stepping on toes. Tim is currently working on that, I may need to copy and paste some of my work in order to make sure its implemented in the current master branch.

Individual Apprenticeship Patterns – Concrete Skills


This pattern works with the situation that an upcoming software engineer has some knowledge, but not much experience applying that to practical situations. This is also under the assumption that the learning engineer is seeking out work with a suitable team of coworkers, or applying to a new job.

Following this, the pattern advises becoming proficient at skills that every team needs. This typically means executing simple manual tasks, allowing the apprentice to contribute before moving to a more direct role in the group. It is important to get to the point where work can be done without supervision or help from the rest of the team, so they can focus their time on other work. This type of work includes “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.”

On the other side of the coin, hiring managers are taking a risk by hiring a student or apprentice since they might require more help early on. To help combat this, concrete skills are an immediate and significant answer. Being prepared before getting hired allows instant benefit and payoff to the group that decided to take that chance, proving the worth and capability of the applicant.

This also helps when constructing a resume beforehand. Highlighting the areas that offer those quick benefits will help make the resume stand out, resulting in a higher chance to be contacted. Following this point, it makes sense to do extra research on the position first in order to train for the concrete skills that will be necessary once hired.

Although I feel that this can be challenging, they are very good practices. It can be frustrating if things don’t turn out perfectly, and an application is denied, but especially in cases where a dream job is on the line, the extra effort is very worth it. Even if the applicant is not hired, they likely can use or relate the concrete skills they’ve learned in at a different company.

Sprint 4 Retrospective

Sprint four lasted from March 27th to April 8th. I was sick for the first class, but it wasnt hard to catch up on what the rest of the team was planning for the rest of the sprint. By the end of it, we’ve made a lot of progress, our group currently has a working prototype for our final presentation. After this sprint, or the next, we should be able to focus more on putting our presentation together since our project will likely be working and polished by then.

Recently we’ve brainstormed a list of improvement ideas to work on, polishing the project while we still have time. Some of the improvements include changing the header colors around, making the words bigger and easier to read, adding more buttons, and doing more with the title on the page. Many of these features are quick fixes, typically each one will take less than an hour. This sprint is likely going to change dynamically as we think of good ideas or quick changes.

We decided not to implement a login feature, or rather, it has a low priority and we will do it last if we have extra time on our hands. Additionally, the way we divide up work will be different than described in my last retrospective. Each button in the navbar is more of a placeholder, not exactly designed to perform a specific task other than change the text in the middle of the screen. Instead, each member will be given minor to moderate tasks to complete like the ones we planned out in our last class.

First we made sure to download the required angular material, our group member quoc took the liberty of creating a skeleton project and pushing it to gitlab. We all downloaded the skeleton, and have since made improvements on the style and layout of our navigation bar. Of the features we brainstormed, in class we quickly completed centering the text, which makes it much easier to read. Currently, we are also quickly working on changing the color values, which will also be completed soon.

My role in the group is to figure out how to have a nested button within one or multiple side bar buttons. The idea is that we could have a category named button that also works as a drop down bar, offering a few different buttons based on the category. My assignment seems not difficult, but also not as easy as changing color values, which is why some group members have multiple low effort tasks while I only have one moderate effort task.

Completing this by the end of the next sprint, along with everybody else’s contributions, results in a very usable product for our final presentation. To accomplish this, two tutorial videos were posted to the team backlog on github which each group member is assigned to complete as homework, though ideally the videos will help shorten the amount of time our contributions will take. I’ve linked both tutorial videos below:

Apprenticeship Pattern – Create Feedback Loops


This pattern encourages the reader to pay close attention to minor details along the way when evaluating a success or failure. Apprentices commonly find themselves in complacent situations in an average team, so naturally improvement stagnates and it becomes hard to keep yourself on track. The problem is, “the less skilled you are, the worse you are at assessing the skills of yourself and others.” This indicates that it is especially hard to get started again once caught at the bottom of the barrel.

The pattern advises seeking out feedback and constantly adjusting yourself accordingly. This will help you more accurately predict success or failure and help you more efficiently improve. Being open with your work is the focus of other patterns, all apprentices should strive to be as “teachable” as possible.

The chapter classifies feedback under two categories; reinforcing and balancing. Reinforcing feedback encourages more of something, while balancing feedback encourages less of something.

In my personal case at work, I can apply feedback to the pitch I give to the average customer. For the most part, my pitch is designed to be friendly and get the customer the product they are looking for quickly. In that time, I work to fit in other deals or offers I think the customer might be suited for. This could mean higher quality products, the benefits of the best buy credit card, or becoming a member of our total tech subscription service.

At the end of the month, we are provided feedback on how much we sold and how many cards or subscriptions we put out. Some months are luckier than others, but certainly every associate starts to get better and better over time. If an associate doesn’t raise enough revenue after a few months, they receive coaching on their style of pitch. Reinforcing feedback in this case would encourage an associate to mention the subscription service to more customers, thus increasing the chances of closing one. Balancing feedback would prevent swearing and acting rowdy with coworkers in front of the customers, in an attempt to be more approachable.

Sprint 3 Retrospective

Sprint three lasted a week longer than the other sprints due to spring break, resulting in a lot more work getting done compared to other sprints. Starting on March 6 until March 26, in our sprint backlog we planned on covering some posted videos and coming up with things to do as we went along.

The videos were posted in a slack channel by the owner of the AMPATH project, Gregory Schmidt. Greg commentated a walk through of what the app should look like, helping us get familiar with the various stages of the user interface. This also helped us understand what was being done on the backend when searching for patients or clicking on a patient profile. Greg also posted a shell of the project using a site called zeplin, which we all signed up for to view gregs content.

Once our research was done, we decided to clean up the backlog process a bit by moving everything we had on trello to a github project. The layout of both sites is similar and easy to transition to, we just copied and pasted the relevant planning information. Each team in the class picked a certain feature of the app to work on, we chose to tackle the navbar functions.

Since each member watched the youtube videos, we added a few things to our ongoing tasks while we moved them to github. Since our project is a mobile angular program, we found a link (provided below) with a lot of useful information. The site includes examples of how to get started on our navbar, we added that task to our planning board and aim to make a lot of progress towards a built prototype during the next sprint.


In our last meeting, our group brainstormed some ideas of what our navbar would look like, what it will do, and who will be using it. Currently we only have a few sketches, but it seems like we’ve decided for sure that we are going to include a home button and a sign in button. We discussed each group member working on at least one button, therefore we would have 5-10 buttons and the work is evenly distributed. One concern of mine is thinking of that many buttons to develop, the project seems not complicated enough to warrant that much work.

The home button is a simple starting point, it simply takes the user to the upper most page. The sign in button idea is still a work in progress, but hypothetically it should prompt the user for some information and filter a list with data pertaining to that user. In the hands of doctors or clinicians, this would display patients names with an appointment date and the condition of the patient.

Further ideas revolve around the concept of filtering down a patient list based on specified parameters, however this idea is still foggy and might not come to fruition. The same function could be done by searching for a patients name in the search bar, a component taken by another team. We still have time though, and we are fairly ahead of schedule considering the remaining work load of the project. By the end of the semester, the 15th of may, we should have a working navbar with multiple useful buttons on it.

Sprint 2 Retrospective

This reflection is based on the work done from 2/20 to now, 3/5. In this time, our team has only met two times and I missed one of those meetings, so not a whole lot actually got done together during sprint two. We met in class and made progress on 2/20, I was absent from the meeting on 2/25. On 2/27, class was expectedly canceled with the optional choice to meet in class anyway, which we decided against. We figured we could wrap up anything that we needed to work on in the upcoming Monday’s class. Yesterday, on 3/4, Worcester State canceled all classes and events due to inclement weather, and the end of the sprint is next class at 3/5.

Our workload was fairly light anyway, we only had two sprint backlog tasks; make sure every team member could build and run the project, and learn more about angular testing. We could independently conduct research into testing, and we are encouraged to branch out to find potentially helpful content, so the snow day didn’t slow us down significantly.

To study angular testing, our group particularly focused on the two programs karma and protractor. Using the trello project management board we set up in the last sprint, two links were shared for the group to look over. For karma, I used the following link:


This website explains in general terms how karma works. It loads multiple browsers and tests given code on each one, displaying the results conveniently to the developer. We will have to practice hands on with karma once we get some code and tests. For protractor, we used the following link:


All the information on protractors site is very hands on and literal. It explains steps and shows exact commands and lines for example, it should be easily set up and modified to our project. Since we downloaded the latest version of node.js in the last sprint, and have experience using npm, protractor will be a useful resource.

Our more major goal for sprint two was to have every member a working build of the AMPATH project in an IDE of choice. Right now, everybody besides me has a running project since I missed the last meeting. I will need to communicate with them for help troubleshooting and follow the same steps they took the next time we are all in class together.

At the same time, during our next meeting we will be planning for sprint three. We don’t have much on our plate currently since we’ve been making pretty good progress so far, so I’m not sure what to expect for sprint three. I think Professor Wurst will be giving us more concrete things to do, which we can add to our trello board.

We’ve also been keeping up to date on slack, every group member answers automatic check-ins two times a week. This keeps us all updated on what we’ve done since the last check in, what we are planning to do before the next check in, and state any obstacles blocking our progress.

Sprint 1 Retrospective

My software development class is structured to feel more like a real work environment. In this way, we practice completing tasks on schedule in a “sprint” format. This means each student is assigned a development group and communication is emphasized heavily. We began the semester by signing up and downloading the required tools.

We made sure everybody joined the same slack channel, so we could share information and update each other as we continue the project. On this slack channel, we are required to periodically enter what we have done, what we are doing, and any roadblocks we encounter in order to keep the rest of the team informed on our progress. Various slack channels are also set up so that we can ask questions to other groups who may have similar obstacles. Interestingly, we found that collaborating through the other channels was the most effective way to solve our recent issues.

We also used a website named trello.com to organize our project and condense it into workable tasks. This includes a product backlog for general goals, a sprint backlog for tasks and stories we aim to finish before the end of the sprint, a “doing” column for tasks that are currently underway, and finally a “done” column for completed tasks. We spent some time making sure the organization was set up correctly and that everybody was joined in on it. In class today, we prepared new objectives for the next sprint and archived old completed tasks.

In the first few days of this sprint, we also made a repository following the project we will be contributing to this semester, AMPATH/ng2-amrs. Everybody in our group cloned the project from the repository, so we each have the ability to view a local copy. Looking further into the README file, we gained an understanding of how to build, test, and access the server associated with the project.

Next we had to make sure we had a proper development environment to run the project. This included getting everybody the latest version of NPM, Gradle, Insomnia, open MRS, and an IDE of choice that runs typescript, for that I chose Jetbrains Webstorm with a student license. This task took us the most time and still is not finished, only one group member so far is able to run the project successfully. Some of the software we installed, namely Gradle and Insomnia, we may not end up using, so ultimately I think we can get better at limiting redundancies by further defining what is required to complete a task.

By the time our next sprint is over, we aim to have every member able to run the project, then we can start contributing to it. It seems that each group member has their own issues with starting the project, which will slow us down since we may have to work through new problems for each member. We also have sprint backlogs set up to become familiar with the programs Karma and Protractor to help us test the new angular code.

Why Doctors Hate Their Computers Summary


In the article link listed above, surgeon Atul Gawande describes his frustrations with a recently developed new software which he and many others must adapt to. Initially one might assume this person just isn’t good at using software, like your grandmother trying to send an email. However, professionals in the medical field are typically especially adept at technology, their patients lives depend on their ability to update themselves on the latest development in the industry. That being said, the problem must lie in an inefficient new system.

The earlier stages of the switch to the new software are especially problematic. Firstly, medical professionals in all areas are required to spend a lot of time at training sessions when they could be spending it for their patients, which costs efficiency right off the bat.

Next, as everybody learns how to use the system, multiple problems can occur. It can take hours for somebody new to complete a complicated task, or minutes for one who is experienced in it, so the most obvious option is to get help from the IT department. The system is also new as a software product, new software products contain unknown bugs and glitches. I assume there is a rigorous testing process for any new tech when patients lives are effected by them, still, the software can be found at fault in the early stages. Both of these scenarios contribute to hundreds of tickets flood the IT departments inbox. In response, the hospital hires more IT people to help but ultimately a backlog keeps issues in waiting. Some of these issues can be especially serious in the medical field.

These early problems are expected, with the assumption that after a few months the system will be seen as an improvement. In this case however, even after getting use to the system, Gawande and his colleagues notice setbacks compared to the old software. For example, it added the ability for everyone across the organization to edit the “problem list.” The list use to be a quick way for clinicians to assess their patients at a glance, now it is filled with redundant notes from each person who accesses it. The same diagnosis is listed three times by three different people, long descriptions make it difficult to read the few things that actually matter, all contributing to more inefficient overhead. Furthermore, filling out diagnosis sheets has become more time consuming with the addition of new required fields. Whereas it use to take one click to order a mammogram, now it takes three.

What can be done about these inefficiencies? The article elaborates by explaining the concept of the “tar pit.” This describes a state of software development where a program becomes so large, it must be rigorously defined and spelled out for every specific situation so that it can encompass each scenario the same way. Users find themselves slowed down by these specifics, but cannot escape them, much like a tar pit. The result is that professionals spend so much time working through the system, they spend less time actually doing their jobs.

Software progress trends like these have serious consequences, professionals in this situation are more likely to experience burnout. Burnout is a state of emotional exhaustion, depersonalization, and personal ineffectiveness, this is caused by the pointless bureaucratic work that professionals must endure with their daily career. This eats up much more time than they are willing to give up. In 2014, only a third of physicians stated their work schedule “leaves me enough time for my personal/family life.”

Individual Apprenticeship Patterns


Of the list provided above, I will go into detail summarizing specific patterns I find to be interesting or relevant.

I will begin with the pattern titled “Be the Worst.” The title is somewhat misleading, since the objective is actually to improve yourself at every opportunity. If you find yourself as the biggest fish in the software development pond, this pattern encourages you to find work in a bigger pond with bigger fish. Now, you can learn more from them and work your way up to being the biggest fish again, then repeat the process. From the standpoint of prioritizing knowledge above all else, this pattern makes sense, however, I don’t think I have the courage to follow it.

I can relate this to my current job at Best Buy. When I was first hired, I knew nothing about TVs, security cameras, and appliances also I didn’t know as much as I needed to about routers, car improvements, and drones. I struggled for the first few months as I awkwardly tried to give customers the answers I thought of on the top of my head. That period of employment sucked and I knew as I learned and practiced talking, I would get much better at it. As a result, my sales would improve, my job gets easier, and the customer buys something they actually need.

This pattern would encourage me to quit my job and go work at staples or another retailer where I knew nothing about the products, so that I may learn them all over again. This comes with great awkwardness, and the customers can always tell when I don’t know what I am talking about. This move seems absurd, certainly not worth it unless it came with a higher pay, to which I’d talk to my manager at Best Buy for a raise first. If this experience is like dealing with a new group of software developers, it would be a very difficult decision for me to leave my current group.

Another relatable pattern the article mentions is “Expose Your Ignorance.” This is about humbly accepting that you need help and actively seeking it despite looking stupid. It is very easy to feel ashamed for not having knowledge, based on the fear that it is very easy for people with knowledge to look down on those that don’t. Nobody really wants to raise their hand in class, a setting designed for answering questions, in fear of their question indicating they are ignorant. This is very destructive, very common behavior and overcoming it is necessary to learn more efficiently.