Sprint 3 – Retrospective

Sprint 3: 04/08/2020 – 05/04/2020

Sprint 3 preparation started on 04-08-2020. Since Sprint 3 was the final Sprint we were planning to get work done as much as possible. We proposed too many issues that were all appropriate, but we wouldn’t be able to finish them all on time, so we all agreed to keep the most important ones. Our top goal for this Sprint was to have the UpdateGuest service work as a whole.

These are the issues we came up within our Sprint 3 planning (we had more in our backlog):

  • Create MongoDB database for UpdateGuestService
  • Implement WebUI in Angular App
  • Decided which type of Angular form to use for Web UI
  • Learn about Angular Testing
  • Create endpoints in backend
  • Learn how to create tests for backend endpoints
  • Learn Docker
  • UpdateGuestWebUI: Create Docker Configuration
  • UpdateGuestService: Create Docker Configuration
  • Implement requested endpoints from registrar team
  • Decide what needs to be tested in the frontend
  • Implement endpoints in Frontend
  • Implement Angular form in WebUI.

 During Sprint 3 I worked in multiple issues and supported the team with issues discussions and merge requests’ review:

1 – This issue was part of Sprint 2, but we had some minor changes that needed to be done before we merged the merge request.

2 – We had to decide which Angular Form we were going to use, and as a team, we decided to use Reactive Forms.

3 – This is issue was more about learning. The first thing learned was that the latest version of Docker cannot be installed in a Windows Home edition unless you are using it as an enterprise. Docker in Action was a great resource to learn Docker.

4 – I have reviewed, approved, and merged the merge request for this issue.

5 – I created the Docker configuration of the UpdateGuestWebUI using the NGINX proxy server, which by default will run at PORT 8080, using the Docker container IP.

6 – We had a couple of merge requests for this issue. I have reviewed the merge requests of my teammates and implemented the Age&Employment component.

What we needed to do less

We should not focus only on the issues we get ourselves assigned to. Reviewing each other’s work is very important.

What worked for us as a team:

  • Reviewing each other’s work helped a lot with our progress because of the feedback we gave and received.
  • Helping each other through Gitlab Discussions and during our class meetings.
  • Checking GitLab constantly as we decided on our working policy helped us be on the same page.

What we need to improve 

There is always something that needs to be improved, especially when the team is determined to constantly make progress and succeed. In our case, we should improve the way we manage our time. 

Conclusion

I think we finished Sprint 3 successfully. We managed to work together even better than Sprint 1 & 2. The reason for that is because we were able to communicate, discuss, share, and collaborate with each other the whole time. In the end, we all feel satisfied and accomplished with the progress our team had.  

Share What You Learn

I can not overstate how much a generous spirit contributes to good luck. Look at the luckiest people around you, the ones you envy, the ones who seem to have destiny falling habitually into their laps. What are they doing that singles them out? It isn’t dumb luck if it happens repeatedly. If they’re anything like the fortunate people I know, they’re prepared, they’re always working at their craft, they’re alert, they involve their friends in their work, and they tend to make others feel lucky to be around them.

—Twyla Tharp, The Creative Habit

Sharing What You Learn pattern shows how important it is for an apprentice to share their knowledge so that the superiors know how far they have gone, and other apprentices can learn from them. An apprentice is a person who is constantly learning. The best part of being an apprentice is when you start knowing a lot of things, and people come to see you as a source of information. That is the moment when you start feeling somehow accomplished. Before an apprentice gets there, he/she must focus on improving his/her knowledge and learning to communicate effectively with the team. No one has ever said that the journey is going to be easy. On the contrary, it is very challenging at first.

What I found interesting in this pattern is that an apprentice is for sure not a master, but it’s very common that between a couple of apprentices working together, one of them could know a little bit more than the others. Just because an apprentice doesn’t know very much, doesn’t mean that they cannot share what they have learned. Precisely for that, their explanation could be very clear and concise. The best part of the apprenticeship is to learn and to share with another apprentice what you have learned so far. However, there is always a bad side, which is not appreciating what people share. It is important to note that there is an ethical aspect to education and that such experiences are not to be discussed. We need to think before we share something because it could be a secret, or it could hurt others. We should not exchange any lessons if any of our team members get harmed. Furthermore, it is not good if someone finds out that you are not modest enough in the way you share the information. As a conclusion, sharing what you learn is very important not only for people who are listening but for the person who is sharing as well.

Dig Deeper

In practice, algorithm problems do not arise at the beginning of a large project. Rather, they typically arise as subproblems when it suddenly becomes clear that the programmer does not know how to proceed or that the current program is inadequate.

Steven S. Skiena, The Algorithm Design Manual

We live in a world where various complicated software projects have different time frames and require a variety of tools to complete tasks. Employers are also reluctant to employ so many professionals to fill all their positions. The problem is that developers learn only what they need to get the job done, and they are not thinking of tomorrow. Sometimes they have to make decisions without even understanding what the issue is and copy some toy examples that would help them solve the issue. In a short time, they become part of the new technology, but they don’t know anything else other than that part of the technology. Moreover, they tend to have trouble keeping the code in good shape, even though the instructions they use cut corners and simplify complicated things in particular. It means that they are constantly wallowing in a perfect way of studying a thousand instruments or something that needs deep knowledge. People sometimes criticize the developers for getting a poor CV, but they forget that developers can learn so little unless they get put under serious tests.

This pattern made me realize that I need to dig deeper into tools, technologies, and techniques. Resources that developers need to be familiar with include debuggers that allow them to see wire-level debuggers that display network traffic and readability. When you can read all descriptions and coding, nothing can hold the process of learning and continuing to work. One method of using this prototype is to collect knowledge from primary sources. Many fake posts can lead you to the wrong path. Do not just take the opinion of someone, figure out who came up with the ideas first, and understand the problems they were trying to solve. Furthermore, as an apprentice, you shouldn’t look for code to copy but you should be focusing on gaining new knowledge from reading different tutorials. Gaining deep knowledge is hard, but by applying this pattern regularly, you will be one of the people who know exactly how everything works. It is better to succeed than to fail…

Sprint 2 – Retrospective

Sprint 2: 03/04/2020 – 04/08/2020

As we successfully ended Sprint 1, on 03/04/2020 we started planning our Sprint 2. As a start, we decided what issues we should create, how many issues we should complete in Sprint 2, how are the issues going to be assigned, and what the weight would be for each of the issues. Our top priority for this Sprint was to get our service implemented.

These are the issues we planned on working on Sprint 2:

  • Questions for Thea’s pantry staff
  • Documentation: Create a Clean Code documentation
  • Determine what REST API endpoints we need to create
  • Create MongoDb database for UpdateGuestService
  • Implement WebUI in Angular App
  • Learn about Angular testing
  • Create endpoint in the backend

Other than these, we also had to work on the “Design Frontend Architecture” issue on Sprint 2, since we were not able to finish it on Sprint 1. The information we had gathered on Sprint 1 was not enough to design this document. However, after we decided on what our components would be, this issue was successfully completed with a pull request being merged on time.

During the Sprint 2 I worked in multiple issues and supported the team with issues discussions and PRs:

  • #1 – We decided to create this issue to store any questions we thought would be important to ask Thea’s pantry representative. As a team, we came up with good questions, and we were happy to get them answered before we started the implementation.
  • #2 – After we discussed with all members of the team what IDE we all should be using, we decided to use the Visual Studio Code.
  • #3 – This issue’s purpose was to create our own Clean Code documentation so that we could standardize our coding behavior. We discussed in class and decided to read and follow the first 5 chapters of the Clean Code book instead.
  • #4 – I haven’t contributed to this issue, but I have read and understood everything discussed on this issue.
  • #5 – I have been working on this issue since it got created. I have been constantly editing it according to my teammates’ suggestions.
  • #6 – I have helped to implement the WebUI in the Angular App. We were able to design a nice layout of the page, but there is no functionality added to it. We will continue working on it until the whole team approves the merge request.
  • #7 – I have reviewed the merge request of this issue, but not constantly.

In this second retrospective, my team and I need to reflect on these points:

1- What we need to stop doing

We need to stop working on the same branch. Even though we can split work, it is better to have separate branches and merge small changes and working code constantly, so that we do not access remote branches to see the changes.

2- What we need to do less

We should not focus only on the issues we get ourselves assigned to.

3- What we need to keep doing

We should continue reviewing each other’s issues and merge requests.

We should continue discussing, reaching out for help, and help each other.

We should continue checking GitLab on Tuesday, Friday, and Sunday to be on the same page with the team.

4- What we need to improve 

We need to improve the weighting estimation for issues we create, to be able to finish them on time.

Conclusion

We successfully closed Sprint 2. Even though we didn’t close all the issues we planned, we did close most of the issues in this Sprint. As a team, I think we worked better on this Sprint than we did on Sprint 1. We were able to communicate, discuss and collaborate when it was needed. Although we moved to zoom meetings, communication was not a problem, contrariwise I think zoom meetings and GitLab discussions were very effective. The end of this Sprint will be a good start for Sprint 3. It’s time to make the UpdateGuest service functionality our top priority!

A Different Road

Just because they’re not on your road doesn’t mean they’ve gotten lost.

-H. Jackson Brown Jr., Life’s Little Instruction Book

“A different Road” pattern shows us exactly how to follow our map and recall what we know. For some time, we might have walked through a road, and then realized that this route is not an acceptable option for us because of our drawn map. It has happened that we have found a way that is more in line with our current values. Based on this pattern, if we permanently leave the road, we will still have values and principles established along the way. This pattern shows different examples of people who decided to move on into something else and come back to bring new ideas to a company. It is okay to set people free if they have different ideas and let them come back along with the new interactions they have discovered. Unfortunately, traditional software companies are not so welcome. Such detours are also seen as questionable shortcomings in your profession you must explain later in the future. You would hope that your reason for why you left and why you came back will become important within your belief system. However, this shouldn’t be an issue for someone who wants to pursue their dream in a way or another.

What got my attention in this pattern is that we shouldn’t be afraid to do something else with our life, no matter the risks. The skills we have gotten during our journey will not leave, and at one point they will be useful wherever we go. As a software developer, with the experience, we will enrich everything we want for our future. Leaving behind the software development journey to become a professor or an instructor could be an option in our lives. We may like it or not, in the end, it’s all about trying to find where we and our knowledge best fit. I have always thought that leaving a company and coming back after a while wouldn’t be so good but based on this pattern it wouldn’t be so bad. However, there are several reasons why we would and wouldn’t want to go back to our previous employer. But let’s be positive and do what we feel it’s right. If what you were doing didn’t feel right in your career, you have the chance to return to a higher level and be where you always wanted to be in your previous company or move on to another one.

Sprint 1 – Retrospective

Sprint 1: 01/22/2020 – 02/19/2020

During the month, I started to work as part of the UpdateGuest time for the LibreFoodPantry project. The Sprint started with sharing and learning general knowledge about the project, what are the services to be offered, and some future perspective. As I learned the service that I and my team will be supporting, we began to fill the backlog with to-do tasks. We operated as a Scrum team, managing a Scrum board in GitLab, and separating stories based on requirements.

We started this sprint by learning new knowledge. As we decided to with the MEAN Stack, we needed to gain knowledge in all technologies that will be used: MongoDB, Express Framework, Angular, and Node.js. So we created stories to track our learning timeframe and weight the knowledge we gained.

During the Sprint I worked in multiple stories and supported the team in different topics:

  • #1– I created the Angular App, the Mock version of our UI service. I supported the team with discussions on how the App should be implemented and organized.
  • #2 – I supported to edit and fix an issue we had with .gitignore file. Together with the team, we discussed how to fix this issue and concluded with a good result.
  • #3 – I created the Document and designed the Frontend Architecture for out UpdateGuest. This document will support the implementation of the service. This document will be edited during Sprint 2
  • I supported the team with PR reviews, issue discussions, and research when we had knowledge gaps.

The end of the first Sprint consists of secure knowledge and the beginning of work with UpdateGuest service.

In this retrospective, I and my team need to reflect on these points:

  1. What we need to stop doing
  2. What we need to do less
  3. What we need to keep doing
  4. What we need to improve

1- What we need to stop doing

We should stop Approving PR by only one person. Each member of the team should approve a PR – so we know that we are all on the same page.

2- What we need to do less

We should be careful when we create new stories and check if there are no duplicates.

If there are duplicates, before closing the story we should let the creator of the story know first.

In the case of merging a PR, the creator of the PR should merge, or if another person do it, we should let the creator know first.

3- What we need to keep doing

We need to keep working with stories that we have on the Sprint backlog.

We need to discuss issues that we may have during the sprint and approve each other work.

We should keep reviewing each story before we mark them as DOne and close them.

We should keep solving debatable conversations and conclude in a good result that works for everyone.

4- What we need to improve 

We should have better communication for each story, issue or blocker during the sprint. Class meetings are not enough to solve issues. For each story, we all need to discuss and communicate with each other, and to consider all opinions before we conclude to a solution. Communication is the key to success for a team.

Conclusion

As a team, we successfully closed Sprint 1. We closed most of the stories in Sprint’s backlog and supported each other to move to the next sprint. We had a Sprint review for what we did, and a Sprint planning for Sprint 2, so we are prepared for the next step. So, let’s start implementing our ideas!

Use Your Title

I’m promoting you from Senior Engineer to Lead Engineer. The pay is the same but people will disrespect you less.

—Dilbert’s Pointy-Haired Boss

“Use your Title” is a very effective pattern for those who feel like the title they have is everything in life. We all have our own goals in life, and we approach differently to achieve them. For some, a software engineer position is all they have wanted to achieve in life, and there are others who would not feel accomplished until they become seniors or leaders in the industry. On the other hand, it happens to have an unimpressive title, even though you have given more authority in your position than your title or job description says. In this case, people get discouraged and lose hopes that one day they would get what they deserve.

In my opinion, we should “Use our Title” in a way that benefits us professionally. Titles are only made to feed our egos. What is more important is that we should never stop learning or stop searching for better opportunities that would complete us professionally. Let’s think of it as climbing mountains. The second highest mountain in the world is K2. If a person’s goal a year ago was to climb that mountain, he/she would feel accomplished when he/she gets there, but then he/she would feel the need of having another goal to achieve and would end up climbing Mount Everest. This tells us that even when we get to have the title we always dreamed of in the industry, there’s more we can achieve.

In this pattern, I found interesting the part that suggests writing down a long and descriptive version of our job title. I think this would help us reflect on what we do at our workplace, if the title matches with the authority we have given, and maybe find the need to update the title with superiors’ permission. I, myself am going to try and see what I find out when it comes time to update it.
As a conclusion, make sure your skill level matches your job description and title, and no matter how far you go with titles, remind yourself that your apprenticeship is not over.

Sweep the Floor

In the craft tradition, newcomers start as apprentices to a master craftsman. They start by contributing to the simpler tasks, and as they learn and become more skilled, they slowly graduate to larger, more complex tasks.

—Pete McBreen

Sweep the floor pattern shows that an apprentice can work very closely with experienced professional people of any industry, but they cannot be equal with them since the first day they start working on the company. First contributions to the company by an apprentice are usually small and simple tasks, because the team you are part of, doesn’t know where you fit better, nor do you. As bad as this may sound, “sweeping the floor” is a very good start, because you show to your superiors that you can do small things with high quality, and in the future, you can do greater things with the same quality.

What got my attention is Paul’s experience in a software company. He was aware that he couldn’t write code at a certain time, so he accepted to contribute to the company differently, by even sweeping the floor for real. He was only 17 when he first started, but slowly he started doing more technical assignments, like updating the content of the website or working on the backup. These tasks helped him a lot to gain the trust of the team. Since he was able to do the small tasks right, later Paul would be the same passionate person to do something huge in the company. But let’s not forget that it doesn’t matter how small or big your assignment is if you do something with passion and get the best out of it. As it says on the pattern: If no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in the dirt. Every role is important, and no one should be ashamed of their job!

In my opinion, being an apprentice is very useful after you graduate. Courses you have taken during college, will not be everything you will need when you become an apprentice. Being able to start from the dirt, will help you understand step by step how things work in the company. Not everybody is ready to start from the dirt though, especially people who have some experience in the field. However, depending on your commitment to learning everything, in the future, you might be able to do great things on your own. As a conclusion, take the opportunity to Sweep the Floor, and make sure you prove to yourself and to the team that you’re worth doing something greater every day.

Confront Your Ignorance

If we value independence, if we are disturbed by the growing conformity of knowledge, of values, of attitudes, which our present system induces, then we may wish to set up conditions of learning which make for uniqueness, for self-direction, and for self-initiated learning.

-Carl Rogers, On Becoming a Person

Every day of our lives, we find ourselves surrounded by people who know more than us. It is normal to not know everything. This is why we shouldn’t go hard on ourselves when we meet people who expect us to know more than we do. The best we can do is to confront our ignorance, which means to identify gaps in our knowledge and try to fill those gaps continuously. The “Confront Your Ignorance” pattern shows us different ways to approach when we find those gaps in our knowledge. Some of these approaches are: to read the introductory articles and FAQs, to love what you do in order to understand it better, to work with others who have more knowledge than you in a specific topic so you can learn from them, to learn in public and not in secret. As good as this pattern can be, sometimes the apprenticeship can become a problem for the team at work.

This pattern made me realize how important it is to confront and expose my ignorance. Sometimes I get too hard on myself, such that I forget that I am in a learning process and it is okay not to know everything. From now on I will write down everything I find it hard to understand and start working on getting better on those. It could be a skill, a technique or any topic, but that would be a good start towards a great future full of knowledge.

What got my attention is the fact that “Confront your Ignorance” and “Expose Your Ignorance” patterns are very close to each other. By doing a list of the things we don’t know, and the things we should know in the future, we’ll be able to learn where our gaps are, but exposing them to the world help us learn even faster, and get help from the others as well. Facing your ignorance alone leads to stubborn knowledge that never takes action, but reveals your confusion without seeing it as a question that must be answered as soon as possible. As a conclusion, confronting your ignorance is very important in our daily work, especially when our purpose is to be successful in our professions.

Learn How You Fail

Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and constant searching for new solutions.

-Atul Gawande, Better

Learn how you fail is the first step towards learning how to win. The objective is to gain self-awareness of the reasons which lead to failure, and then make better decisions by reducing the inclination towards idealism. Being conscious that you cannot know everything, is the only way to become aware of how you fail. Knowing your own limitations, allows you to deliberately identify obstacles and concentrate on the goals you can reach.

Yes, you will fail! What’s more important is that you will win, once you know why you failed. The way to get the best out of it is to create a system to prevent the failure from happening again after you have figured out what went wrong. Creating a checklist or a type of protocol to prevent it from happening again when you find the weak point is another option to not go through failure again.

In this pattern what got my attention is the last sentence, which says “if you’re brave enough, get a friend to review your code, and see what else she can discover”. This is very accurate because everyone who writes code knows that there will be errors and it will take time to fix them. Even though you fix the errors you get, someone will find something else for you to fix, especially when you work in groups. This can be very tough because you feel like you are falling down. The reason why this happens is that we feed our brains to always win, and never lose. We reach the goal because we know how to do everything, and there are times when we do not reach the goal because there is something, we had no clue about. Is it time to step back? No! We should go through the failure, learn why you fail, and try again if you think you’re capable to fix it. As a conclusion, it can be very painful to learn how you fail, but in the end, you will have the skill to accept whatever life throws your way.

Create your website at WordPress.com
Get started