Week 6 - Charting a Path
Andrew Hogan
June 20-24
Embedded Files
Reviewing the Charter
Reviewing the Charter
This week were meetings. So many meetings. The kinds of meetings that remind you of your SATs and sitting silently in a classroom for hours on end. There were long meetings containing every agile team within EPIC, and there were long meetings with just my individual team. At least I wasn't testing, nor was I the one directing the sailing of this ship.
The purpose for all of these meetings is to allow individual agile teams to plan the next program increment - which usually spans about two months given the length and number of sprints. As discussed last week, a Program Increment within a Scaled Agile Framework (SAFe) is generally made up of 5 sprints, including a short 1-week sprint for the purpose of laying out the roadmap for the next increment. Depending on the needs of the organization, this can be modified.
For three days, my team, the Unified Workflow team, would spend several hours a day grooming the backlog and deciding on the appropriate route to take for the next increment. For our individual meetings, we discuss much of what we would like to complete within the next several weeks, assign story points for tasks via planning poker, and provide updates for our timely availability to work for the team. The lattermost point was interesting to me as I assumed many NOAA Affiliates worked within their roles full time, but it turns out "full time" for them presents a diversity of roles across the organization. For instance, I learned my peer advisor also works within another lab of her own with another team. (So many teams... I think I'll just keep this one for now.)
Now that I have acquired a bigger picture of how team members operate within NOAA, I've come to experience one of the many costs of working on an Agile team.
Lost At Sea
Lost At Sea
For the benefit of keeping many agile teams flexible comes the expense of team makeup. Some of the senior members of the Unified Workflow team are being transferred to different teams to assist in their work for the next program increment. They're not "gone" in the sense I'll never see them again, but their role on Unified Workflow is drastically decreased as they will be primarily working on other agile teams, like Short/Mid Range Weather. Their availability for the Unified Workflow team ranges from absence to minimal.
It feels like my already little world of Unified Workflow just became smaller, but I'd like to thank Arun, Rahul, and Ryan for actively participating in my internship experience and providing me with advice and direction I can take with me after my time with NOAA.
Getting Out of My Own Way
Getting Out of My Own Way
I have been assigned a task to work on a method for importing a list of files recursively from a Unix filesystem.
Now that I've gotten many distractions and hinderances out of the way, I feel I can properly focus on this task that I was assigned last week. I started looking at it, wanting to feel confident that I could learn and do a little research into my task along the way, and I never imagined such a tiny script could cause me so much stress.
My trouble with developing my skillset is I don't seem to get out of my own way enough. I have this problem where if something doesn't make sense to me right away, I tend to shut down. I either get despondent or anxious, but usually both. Although I feel confident in the basics of Python, the real challenge is going beyond them to truly understand the intricacies of a language as well as the system you operate with, resulting in many of what I consider to be that beautiful code you would see in some tech drama, like the Matrix or Westworld.
So far in my internship, I noticed myself hoping for tasks that I felt were within what I felt was my skill level. Aptitude and performance felt more important to me than my development as an engineer. It can feel like a scary balance as I'm caught between expressing my competence and benefitting the group.
Page updated
Report abuse