Skip to main content

Sprint 6 Retrospective

At the very beginning of this sprint, on April 25, Mia was able to push the portion Dan worked on (“Tabs2”) so that we could all see it. Up until this point, the rest of us were not on the same page. We were looking at a previous one we had come up with. We were instructed by Mia to hang tight until she was able to push it.

Ryan and I were both unsure whether she would be able to, so we talked about doing it from scratch. That night, I started the process, but I didn’t get far before Mia let us all know that she was able to get it pushed. At that point, the majority of the component was done. I noticed that the button to create new slides was broken. It was a small fix, but I was able to fix the bug.

Most of this past week was preparing for the presentation. I feel somewhat that I was under utilized and that I could have done more. It is not that I did not want to do the work. I offered often to do more. Once I was able to see the component, most of it was done.

I suggested starting development for another component both before the first was completely complete and after. I was discouraged by my team from doing so. I feel like if we had, we could do at least one more component. I feel that even if we got a start and was unable to finish on another, it wouldn’t be much of a loss.

In the last retrospective, I felt different and that we should just focus on one thing and do it well. I did not realize how far along we were. (Again, I was not able to see it.) I feel that we could have easily done another component in this last sprint and a half. However, hindsight is 20-20, and I didn’t know then what I know now. This was the first time any of us had done something like this, so none of us knew what to expect.

Despite my regrets for not being able to do more, I feel this overall has been a positive experience for this entire capstone. I will be able to take what I have learned here and apply it to the next scrum team I work with. We have not been perfect in communicating, but we have done a pretty good job overall in keeping each other updated. I think we all have seen where we have fallen short, and I think we can use our failures as learning experiences.

Some of our problems came when one of us would run into a problem and the rest of us could not see what they were dealing with and, at the same time, be relying on that work. It would create a bottleneck. It was very frustrating for me to not be able to help in any way when it came to this. I am not the kind of person who likes to sit idly by when I feel I could be of some help.

What I can say about my team is that none of them are slackers. It isn’t often when I feel that I am not the one shouldering most of the work in a group project. This was a welcome change of pace, even if I wanted to contribute more. I found that in a group like this, I should have taken initiative sooner and more often. That lesson will be crucial to success in my next venture.

Comments

Popular posts from this blog

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect.  They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about.  He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things. He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this fi

OOP Basics

For this week’s blog on software design, I chose to watch a video presented by Dr. Steve Bagley on some fundamentals of object oriented programming (OOP). I’m embarrassed to say that although I am taking several upper-level computer science classes, I am unsure I would be able to give a good definition of what object oriented design was. To be fair though, it has been several years since I have taken CS 101, and it seemed like such a foreign concept at the time. I felt silly learning about something so elementary again, but it made a lot more sense when I’ve had as much exposure to OOP as I have now. For the video, he uses a game of “Pong” as an example of how OOP might use objects to represent the “ball” and “paddles.” From there, he talked some about inheritance and touched on a few more topics, albeit briefly. The main reason why I didn’t understand the benefit of this way of programming is that I didn’t know how else you would do it. I didn’t realize that without declari

Apprenticeship Pattern "Nurture Your Passion"

In this week’s post, I will be discussing the apprenticeship pattern “Nurture Your Passion,” as presented by Adewale Oshineye and Dave Hoover. I chose this chapter because I think I have felt like I’ve been just getting by for a while now. The  problem it identifies as, “You work in an environment that stifles your passion for the craft.” I don’t think that’s quite fair to my school or professors. I think that in any discipline, if someone is only studying for the tests or working on the assigned projects and calling it a day when they have passed them in, they are not truly adopting the apprenticeship mindset. Without a constant push forward, I will stagnate. I may get an “A” on the exam or project, but if I forget the material the next day, there is no point. The pattern suggests finding something that sparks interest and pouring myself into it. I have been wanting to do this for a while, but I have made excuse after excuse of not having enough time. The next sentence in th