Recently our class discussed inclusive language and delved into tools that are able to root out non-inclusive language. I tried to find an article or blog that gives a set of examples to watch out for. I found a blog post that gives guidelines, examples of non-inclusive language, and provides examples of how companies are adapting to make their language more inclusive. The blog post is called, “Inclusive Language in Technology” by Barathy Rangarajan, DreamWorks Animation.

            The blog post starts with giving a definition of inclusive language. It highlights the difficulty in changing language across repositories and identifying what is seen as non-inclusive language. Before diving into those offensive terms, they give four guidelines when writing code or documentation. These guidelines were: avoid using terms that have social history, avoid using idioms and jargons, write inclusive examples, and if you’re unsure, ask. I personally liked the inclusion of idioms and jargon being something to watch out for and how important it is to ask if you are unsure. Usually, idioms and jargon are just ingrained in the language we use based on where we are. Being aware of that when writing code or documentation for people who may not understand felt important. Understanding that these terms can be tricky to identify as non-inclusive, it’s important to ask those who might know more.

The post then gives a set of terms deemed non-inclusive, organized by different categories. These categories were, socially charged, gendered, ableist, ageist, and violent language.  I won’t get into detail about each, but I recommend you take a look to familiarize yourself with the terms and alternatives. There were some terms I was not aware of.  

The final portion of the article is the how companies have made changes to be more inclusive. They described how Autodesk, DreamWorks, and Sony pictures are addressing non-inclusive language. Some involve hiring based off race and gender, promoting resource groups, and setting a baseline initiative to produce inclusive code in the future and update older code. In one of my previous posts, I talked about setting ground rules that the team can agree on when conducting ourselves during development and discussions. I feel this is also relevant when it comes to inclusive language.

The blog post shed some light on the best practices and popular terms used when addressing inclusive language. In the future I will strive to be self-aware about how I write, ask question when I don’t know, and use what I’ve learned in day-to-day interactions along with writing code.

Link to the blog: https://www.aswf.io/blog/inclusive-language/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Similar to my last blog, I wanted to focus on how to implement certain aspects of Scrum in an effective way. While exploring articles related to sprint planning, I came across a crucial aspect not covered in our class, technical debt. The article “How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work” by Cate Lawrence, provides strategies for making sprint planning less overwhelming while also highlighting the importance of preventative measures for technical debt. In this blog, I will focus on the technical debt portion of the article. Technical debt is a term used to describe future complications, that are time and resource intensive, that arise from expediting development instead of properly completing the product. It is the tradeoff between immediate gains versus long term consequences.

The article provides three steps for incorporating technical debt into sprint planning. The steps are:

• Make technical debt visible

Recognizing potential issues and highlighting them for the team is important. Letting those issues accrue and not addressing them seemed like the opposite of the Scrum values. You should be adapting to unexpected issues or requests, not planning to have issues in the future.

• Determine the business impact of each debt item

I could see how it may be enticing to take shortcuts during a Sprint. Convincing the team or management to not take these shortcuts and to tackle these issues will only help development, but it may be hard to do. Instead of focusing on all the technical issues in front of them, highlighting how the debt will come calling in the future felt like the appropriate response.

•  Bring it to your sprint planning meeting

After visualizing the issues and showing why it would be best to deal with them now, including them in the next sprint plan is the final step.

Though not the main point of the article, it highlighted that technical debt was a neglected topic in sprint planning. I chose this article due to the steps, but also because it felt like something everyone should add to their Definition of Done. Even if everything “works” correctly with the code, knowing that there could be further problems due to the expedited nature of the sprint, the code should not be seen as done. It should not be ignored and should be addressed immediately or in the next sprint. Hopefully, these steps and the discussion on technical debt in the article will be helpful. In the future, I will try to address these types of issues using the steps, but also incorporate this into the team’s Definition of Done.

Link to the Article: https://stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

During our classes we discussed the definition, theory, values, team makeup, events, and artifacts of Scrum. I decided to focus on one of the events of Scrum within the Sprint called the Daily Scrum. The Daily Scrum was briefly described and we discussed how the Daily Scrum allows the team to inspect progress toward the Sprint Goal and to adapt the workload as necessary. What we didn’t do was discuss the best way to go about that. I wanted to understand the best practices for proper communication with team members in accordance with Scrum values. The blog “Ten Tips for More Effective Daily Scrums” by Mike Cohn helped with this by giving 10 helpful tips for how to conduct a Daily Scrum. Cohn specializes in agile processes and techniques and makes a living by helping companies build high performance teams.

After reading the tips, I could see that most of the points were prioritizing focus, one of the main values of Scrum. Most of the tips give solutions or show problems that arise that stop the Daily Scrum from focusing on the Sprint Goal. The problems it shows are what I assume to be problems that happen repeatedly for people new to Daily Scrums. They don’t talk about the current Sprint, talk about work done unrelated to the Sprint Goal, focus on unrelated details, and ramble. I liked how the author handled the issues. He pushes the idea that you should set ground rules or guidelines that everyone understands before conducting the Scrum. Having words or phrases that let the team know you might be rambling or for letting a person quickly explain that non-Sprint Goal work was done seemed like a very good way to professionally conduct a meeting. I would think it’s hard to tell someone that they are rambling more than they need to. To have a buzzer or code word established must help communication without hard feelings and allows everyone to be on the same page.

 I also appreciated prioritizing the use of certain words. Saying “impediments” instead of “blockers” or asking about what a person “accomplished” instead of what they “did”. I wouldn’t normally think to prioritize certain words while conducting a meeting, but his explanation on how it changes the team’s perspective on the work during the Sprint was enlightening.

This blog showed me that when communicating with your group, whether in a daily Scrum or not, there are simple ways to optimize communication. The tips given weren’t groundbreaking, but I can see various ways this could be used when communicating with others. Going forward, I plan on setting an outline of ground rules that the team agrees on so we can effectively communicate.

Link to “Ten Tips for More Effective Daily Scrums” by Mike Cohn – https://www.mountaingoatsoftware.com/blog/ten-tips-for-more-effective-daily-scrums#author

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.