Regardless of this being our first sprint I believe we were successful at laying out the groundwork and finding each other’s rhythm and perspective. I do think that our team could mature from the information we generated while working on processing what we needed to do. It was interesting to work with gathering the information we needed and not jump into the work itself. At times I as well as others started on tasks that were not planned or even required out of eagerness to see concrete completion. I am a big fan of lists and found it refreshing that the solution to an organized workflow was just to stick with it. Software development is most definitely not work for the anxious and it offers some lively wrestling with the meaning of the word done.
What did not work well was following our own paths and disregarding the set steps to the objective. At one point we had to look at the issues and rush through them because we worked on things that weren’t necessarily important at the time, or outside the project’s specifications.
What I think worked well was communication. We all talked through the process in other to understand each other’s perspective. Sometimes we had contentious ideas on how to go about specific things. We did not shy away from friendly confrontation and always found a middle ground.
Issues I was Assigned to:
Building a container, was an issue that I assigned myself to because I thought that I could use the experience I had researching it for software architecture as well as other tasks that were closely related. I used the docker files from previous projects of similar scopes to produce development environments suitable to each of the tasks we needed them for.
Contact the I AM team to determine security key format, in this issue we had to gather information on a fellow team’s project. After communicating with them we reiterated what we thought would be the case. Their project required acquiring knowledge on a technology they had no previous experience with, so we thought it would be best to wait until their second sprint when our fellow team would mature the use of this new technology so they could give us an educated use guideline.
List dev environment tools, this issue was a collaboration by all. It required us to think about certain tools that we like working with and decide whether to set them as default tools to the docker containers in all projects. I personally think this issue was important to have us feel each other’s work antics and to have a hands-on direct collaborative first encounter and produce a list that we were all invited to read, change, discuss and concretize its idea by cross-referencing this issue with the building a container issue.
Clone the API project we constructed last semester into the new API repository, this issue required us to search on previous work and define the scaffold by which we would build our design. APIs are something new to me and I believe to most members of the team, but I think this can also be an advantage because it hasn’t been that long since we looked at it. The sample API is for reference only and should be removed as the actual API is written.
Determine .yaml files for methods; break down into smaller issues, this issue started with a different name and is a good example on how we evolved as work started getting under way. Some of the issues we had with naming issues was that we did not have matured the idea of the project’s purpose enough to be more succinct in setting our actions. Some issues had very broad names which the lack of description rendered their completion troublesome. We decided that a study should be done to break this issue into tasks with a set definition of done. I believe this issue helped us forecasting work for the coming sprint and gave us enough space to now have a much less crowded sprint planning. Another thing I think would have helped would have been having backlog refinement meetings to come up with new issues or being less abstract about the issues we already have.
technology blog 