DEV Community: Grace Harders

Agile and Accessibility: A Powerful Partnership

Grace Harders — Tue, 08 Jul 2025 21:32:12 +0000

When I say "agile and accessibility," some developers may pause. Have you ever heard a story about a developer delivering a product and later discovering that it has major accessibility issues? Cue the firestorm of bug fixes at the last second.

There are numerous myths and negative stereotypes surrounding the implementation of accessibility in software projects. This negative connotation can stem from an issue with the agile process. If your team doesn't prioritize accessibility from the start, fitting it into your agile workflow later can feel painful, inefficient, and worst of all: SLOW. What if I told you that I learned how to change that?

This year I attended an amazing talk at AxeCon - Speed without Sacrifice: Building an Accessibility-First Culture in Agile Teams by John Sweet and Andrew Walker. In this article I'll detail what I learned from this talk and the major takeaways I think we can implement in our company.

1. Will accessibility slow our agile process?

This question is posed frequently by developers as we are pushed to "move fast and break things" in agile development. The truth is that, yes, if implemented poorly, adding accessibility WILL slow you down. We can avoid slowing by implementing accessibility from the beginning and throughout our agile cycle.

Frequently, accessibility requirements appear late in the development cycle, but we can change that. We can add accessibility to our designs, way before any engineer starts coding. If designers AND engineers are trained in accessibility, then the entire team can think of possible accessibility issues before they appear in production.

In the Axecon talk, it was noted that we want our products to be "born accessible". If our product is accessible from the start, then our process will continue like a fine-tuned machine. Developers, product managers, and designers can be aligned on accessibility requirements from the start. This approach will eliminate wasted time by developers in that "firestorm of bug fixing" I mentioned at the beginning of this article.

2. Train your staff

Training your staff in accessibility will look different for every company. If your company has the financial resources to invest, an accessibility expert could be hired to train your staff. Other options are enrolling your staff in online courses or holding office hours with accessibility experts to encourage discussion and collaboration.

Regardless of resources, every company should develop a standards library to state how different components can be added into designs. At the company I work for, Asurion, we have a UI library that sets the standards for our various UI components. The components are already accessible, so accessibility integration becomes a breeze. The challenge is promoting and enforcing these design standards throughout your company.

In Conclusion

To create accessible products, you don't need to compromise on agile practices! Instead, bring in accessibility standards from the beginning to ensure smooth product delivery and happy engineers.

TLDR:

Accessibility should be incorporated from the beginning of development
Look into training opportunities for your staff
Create accessibility standards across your company

It's Time to End the Biggest Programming Myth

Grace Harders — Fri, 08 Sep 2023 17:12:41 +0000

What comes to your mind when you think of a stereotypical programmer? In 2023 this question could be answered in hundreds of ways, but when I was younger I had a set perception that is shown in movies/tv shows. Programmers are (mostly) depicted as being:

Alone/antisocial
Hiding from the world (typically in a basement)
Unable or unwilling to connect with others

Now that I work as a software engineer I know how diverse programmers can be but the stereotype still exists. Granted, there may be people who fit this description working in the field, but for the most part the other programmers I've worked with have been friendly, helpful, and social. I want to break down this myth of programmers as isolated people because I've found in my career that it is SO much better to leverage those around you.

If you've read the above and still think "no - this is bogus. Programming is a solo sport!" I hope that by the end of this article I can change your mind. While one COULD shut out everyone - and maybe be successful - you'll find that your career can flourish by working with others.

Some Benefits of Working Collaboratively

Pair Programming

If you work on any sort of team you've probably heard the phrase "pair programming" more times than you can count. If you haven't, let me quickly explain what it is.

Pair programming is when two or more developers work together to solve a software program whether it be a code or infrastructure issue. One person will "drive" or click around while the other people listen and give advice on how to solve the problem.

Pair programming has some huge benefits:

Removing blockers
Some team knowledge can only come from those you work with. The questions of "where does this piece of code live?" or "why are we doing this in this way?" can quickly remove blockers and help with your productivity levels.

Learning and Teaching new things
One of the first things I've learned in the field is if you hear someone say "that's just how we do things around here", QUESTION IT! Technology is constantly changing and evolving so it is important for developers to be constantly learning. This also means that no matter your skill level, there is something new to be learned.

More senior developers may learn about new technologies from recent college graduates. Junior developers can learn about coding standards and how to solve complicated problems from their more senior developers. The experience of always learning means that it is NEVER a waste of time to spend time pair programming with another developer.

Typically you'll come out of the session learning something new whether it something large like how to completely refactor your code or something small like how to better write inline for loops.

Building Team Trust

The last benefit of working collaboratively that I'll discuss is building team trust. Team trust can be commonly overlooked in favor of louder more pressing issues - deadlines, releases, etc - but that does not make it less important. If you have a team that doesn't trust each other it can be incredibly hard to develop efficiently.

Team trust can be built in interactions between coworkers. If pair programming sessions and PR reviews are respectful and helpful then more junior developers will be more willing to ask questions. This will then remove blockers and help the developers learn and grow. If everyone is encouraged to speak in meetings then people will feel more encouraged to speak up if there is a small problem. This can save time in the long run.

These interactions with coworkers may seem small in the moment, but in the long run building team trust will help grow your team as a cohesive unit - tackling problems together as efficiently as possible.

To Wrap Up

I graduated college with a desire to be a frontend developer but I had very little practical experience. Through working on a team and pairing with senior developers I was able to learn so much and begin my career. If you're interested in learning new things I would recommend leaning on your coworkers and busting the myth that programmers are solitary creatures!

Don't Become A Code Monkey!

Grace Harders — Tue, 20 Sep 2022 20:17:51 +0000

When starting a software project it can be easy to jump in headfirst without a plan. We at Asurion are here to give you some of our advice on how to avoid some of the pitfalls developers can fall into in their project structure. We discuss technical ideas, how to avoid burnout, and the importance of team health.

This podcast episode features four Asurion developers:
Manju Bellamkonda
Grace Harders - A software engineer with a passion for frontend development, developer health, and creativity. You can find her personal developer blog at dev.to/grace_harders
Luis Santiago - A Software Engineer at Asurion. Always eager to learn.. You can find his YouTube channel here: www.youtube.com/channel/UCMTu...
Robert Tate - A Software Engineer at Asurion. Also a big fan of D&D. You can find his personal blog at dev.to/roberttate.

You can follow Developers at Asurion at this dev.to link: dev.to/devsatasurion.

The Why and How of Team Retrospectives

Grace Harders — Mon, 25 Jul 2022 18:21:39 +0000

In my time as a developer, I've seen all my teams adopt practices from the Agile methodology. This included the adoption of many "agile" meetings - standup, backlog grooming, sprint planning, and retro.

When I first heard of the idea of having a retro meeting, I was hesitant. I remember thinking "What is the point of blocking out this time that could be spent coding?" I quickly changed my opinion after attending a few retros. I learned how important it is to create a dedicated space for team feedback and how team health can be impacted if this space is not allocated.

🤔 What is a Retro?

Retrospective meetings are a team-wide meeting in which everyone can feel free to give their feedback on the running of the team since the last retrospective. There is usually dedicated time to discuss what went well and what could improve. At the end of these discussions, action items are taken by team members to improve the team flow. These action items can be reflected upon at the beginning of the next retrospective.

❗ Before I start discussing my thoughts, I want to note that there is no "correct" way to run a retro. I've seen different teams use different styles successfully depending on their communication styles. Flexibility is key here.

The Importance of Feedback and Vulnerability

Let's examine the "why" of a retro. Why do we implement team feedback sessions and what are the important learnings that come from them?

In this article "How to Build Confidence While Showing Vulnerability" the author Dan Cable notes a few benefits that come from having open team communication. The first is that open discussions normalize and encourage learning. If we approach retrospectives from a "what can we improve on" mentality, people will feel more likely to say what is working/not working for them. People will feel more comfortable exploring alternatives in order to find the best solution to a team problem.

Another benefit that Cable notes with displaying vulnerability in a leadership role is better team engagement in other aspects of work. If the team feels heard, they are more likely to be excited about their work and show better cooperation.

🏃 How Should Retros be Run?

1. Plan your goals

Before running a retro, it is important to do some preparation to make the best use of your team's time. You should start with a set of goals in mind to better customize the retrospective to your team's needs.

In my retrospectives I like to check our team "health", encourage everyone to give feedback, and inspire teammates to take ownership of tasks. These goals shape the way I run and participate in retrospectives as I want to make sure everyone feels heard and included.

2. Schedule!

Retros need to be frequent enough that people remember what they want to talk about. If over a month passes, team members may forget important items or feel that they cannot talk about anything specific because the retro spans such a broad length of time.

I recommend scheduling a retro every two weeks for an hour. This frequency does not have too long of a gap between meetings without draining too much time away from development.

3. Make sure EVERYONE is heard

One of the reasons I like retros so much is that everyone is given a chance to participate and give feedback. Every team member should be encouraged to share their thoughts on how the team has been doing (both positive/constructive criticism). I have found that in this situation some team members may feel shyer so it is important to encourage everyone to give honest feedback without any repercussions. If you are a manager leading the retro it is also important to prepare YOURSELF for feedback and not become defensive if someone says something critical.

4. Actually do your action items

It is one thing to voice concerns and opinions about team health, but it is another to actually implement the ideas that arise from the retro discussion. Action items should be clearly marked on the retro board and can be turned into Jira tasks or noted in public channels for further discussion. Everyone on the team should be aware of and responsible for these tasks.

If you are finding it difficult for the team to take responsibility for these tasks, then you might want to assign "task leaders" that will keep track of progress. Then at the start of every retro review last week's action items. Was progress made? How is the implementation of this action item going?

Good luck and have fun planning your team retros!

TLDR:

Retrospectives are an important part of team health and maintenance and should be prioritized
Make sure to plan your goals for the retrospective
Follow through on your action items!

Finally please let me know your thoughts! Have you had successful teams that did not use retros? What do you think is the most important "health check" a team can do?

Resources used:

Cover art - https://www.vectorstock.com/royalty-free-vector/retro-neon-city-background-neon-style-80s-vector-22323112
How to Build Confidence About Showing Vulnerability - https://hbr.org/2022/07/how-to-build-confidence-about-showing-vulnerability
Retro definition - https://www.atlassian.com/agile/scrum/retrospectives#:~:text=A%20retrospective%20is%20anytime%20your,retro%20on%20just%20about%20anything!