Working in a Hybrid Environment
A developer quality I was never informed about, but have come to learn the importance of, is the ability for a developer to work in different kind of settings. Having the kind of adaptability and flexibility to be able to work with a development team or individually, as well as being able to work together in-peron or remote. In this case study, I want to talk about a project I had the pleasure of working on during my time at Utah Valley University with some colleagues as we all learned how to build a software application in a mostly remote, hybrid agile work environment.
The Course Objective
I was part of a Software Engineering class during my studies at Utah Valley University and during this course we were given a semester long project of creating a software application and assigned a team to work with. My team was created and we were given the project of creating a piano lesson tracking application in Python. Our entire group had previous experience in Python and all had our own unique strengths and weaknesses with the language, which allowed us to become a strong team together.
What made this project unique from other projects I worked on throughout my life as a student, was that this project was intended to be worked on mostly remote. Because of this, us, as fresh developers new to the industry, were given the feat of learning how to not only work on a dev team together, but how to use the tools that are utilized on remote dev teams including GitHub, Microsoft Teams, and more.
And so, with this all figured out our objective was clear. Work together as a remote software team to create this application. Now, it was time to divide and conquer, and learn how to conquer in the process.
One of our provided example images of how our end product was supposed to look and function.
Our Process
As the semester began our first steps as a team was to wireframe the project and create the initial layout of the application. To begin, we met over Microsoft teams twice a day to scrum and discuss what we accomplished, what we were planning to accomplish, our blockers, and our progress towards completing the sprint goals, and then meet in person once a week in class to briefly go over progress and discuss things in person if needed.
With our communications established our next task was to divide out tasks for creating the initial frame of the application and create the components and base level features of the application to be modified and given more functionality at a later time. With this in mind, we set our goals and assigned our tasks for each member of the team for the sprint and went to work.
For my portion of the initialization of the build, I created our app title screen, the button that redirected the user to the login page, and then the basic login page. Additionally, I created the chart layout that would hold the dates, songs practiced, and the minutes practiced. To help create more of the user interface in our assigned coding language, Python, we imported tkinter, Python’s standard Graphic User Interface (GUI). This allowed the creation of the user interface and would allow for ease in creating functionality between components in the interface
End of the First Sprint, Start of the Second
Before we knew it we reached the end of our first sprint and accomplished our goal of creating what was essentially the shell of the app. It had all the visual pieces, our next sprint was focused on giving it its functionality to create, save, and modify data. From a database of users and creating new users, to dates songs were practiced, what songs, and for how long. As well as the overall time practiced and the time remaining until the user receives a reward for their hard work.
Blockers
Something we quickly became familiar with as we started this next sprint was the “joy” of blockers. Blockers are things that prevent you from progressing towards accomplishing your sprint goals as planned. We quickly became familiar with blockers, but this is not a bad thing! Blockers are often looked at in a negative connotation because of what they do. But what they also do, that is often looked over, is provide an opportunity for growth. When we started this project, we all were on essentially a similar base level of Python understanding. But we weren’t familiar with TKinter, and we certainly weren’t familiar with Python’s provided module for our data process, Pickle.
But, part of the point of blockers is being able to meet together as a group to discuss the blocker, and what measures can be done to overcome the blocker and most importantly, learn from it. As a software development team learning together as classmates, the blockers of not understanding these modules really helped us all grow unlike anything a student casually learns sitting in class. It didn’t matter whether we immediately knew the solution or not, we still had a deadline to meet so we had to learn to seek out answers through additional resources. For me, the blockers we faced during this project helped me learn how to better search issues through reliable code forums and resources, most importantly and reliably, how to read through language documentation.
Screenshot of our prototype sketch of the home page
The End of the Semester
As the semester went on, our development team began to flourish as a team. We became very comfortable working in the agile workflow. We were understanding how to effectively hold scrum meetings, how to properly update our sprint goals, and grew closer together because of it and because of the feats we accomplished overcoming blockers as a team. In addition to this, we also became more proficient in our coding, learning how to push and merge code using source controlling software like Git and GitHub. I especially learned the importance of commenting as you code, leaving a trail for yourself, but just as importantly, leaving a trail and documentation for your team to understand as everybody takes on different iterations and tasks.
The semester quickly came to an end and our software development team was a huge success. We successfully created what our client wanted in their piano application built solely, and remotely, in Python. It had all the basic functionality a user would expect from an application, and went above and beyond, having logins for students as well as teachers, and custom home screen based on that user type. Users could access their account from the top right corner with their user icon, they could edit and modify data with ease, and all around, have a successful experience in their piano practice application.
Not only was the project a success, but I felt like I came out of that class a whole new developer. This was an introduction to some of my first hands-on experience and exposure to development and it opened my eyes to the capabilities of a remote team. I learned how to keep myself and my team accountable in a constructive and effective way, I learned the essentials of agile development, scrum, and sprint planning. I became so much more confident with GitHub, and became much better at learning how to find answers I’m looking for to the questions I don’t understand, because more often than not, as a developer, you’re not alone! There are so many incredible resources and helpful documentation out there, and now I can confidently navigate my way towards my answers. All in all, this project was a huge success and because of this I learned how to be a better developer, a better team member, and a better asset to any team I come across, in-person or remote.
Snippet of our final main code for our Python application, to see more of the code and to test it for yourself, click here to check out our GitHub Repository.
Mason Dietrich is a student in the Digital Media program at Utah Valley University, Orem Utah, studying Web & App Development. The following article relates to the Final Project in the CS 2450 class and representative of the skills learned.