Daily Scrums are an essential part of Agile project management—they help teams sync up, identify blockers, and adjust priorities. However, it’s easy for these daily check-ins to become mundane and repetitive, losing the energy and engagement they are meant to foster. If your Daily Scrums are starting to feel more like a chore than a productive, energizing meeting, it’s time to make some changes. Here’s how you can transform your scrums into sessions that are not only informative but also enjoyable for everyone involved.
1. Add a Fun Start
Start on a light-hearted note to break the ice and lift everyone’s mood. Try incorporating quick icebreakers to help team members feel connected, such as:
Random Fun Question: Begin with a question like, “What’s the most interesting thing you learned this week?” or “If you could have any superpower today, what would it be?”
Rotating Facilitator: Let someone different lead each day. This rotation keeps the meeting dynamic, encourages participation, and allows everyone to bring their own flavor to the Scrum.
2. Shake Up the Format
Sometimes, the simple act of changing how you hold the meeting can add some much-needed excitement. Consider these alternative formats:
Walk-and-Talk: Hold the Scrum while taking a walk, either virtually (for remote teams) or in person. The change of scenery and movement can boost energy levels.
Theme Days: Occasionally, hold themed stand-ups. Encourage team members to share updates like characters from a favorite movie or even use funny props. Themes can make the stand-up more memorable and spark creativity.
3. Focus on Impact, Not Just Tasks
Move beyond the standard questions (“What did you do yesterday?”) and make discussions more impactful:
Shift the Focus: Instead of asking what tasks were completed, try questions like, “What’s the most valuable thing you’ll work on today?” or “What’s one thing that could make a huge difference if we solve it today?”
Celebrate Small Wins: Take a moment to recognize individual or team accomplishments from the previous day. Highlighting wins helps create a positive atmosphere and boosts morale.
4. Productive Blocker Discussions
Instead of simply stating blockers, turn it into an opportunity for meaningful problem-solving:
Blocker Bingo: Create a playful “Bingo” card with recurring blockers. As the team works together to eliminate these blockers, mark them off—it adds a touch of fun and motivates the team to tackle obstacles.
Action-focused: Ensure blockers aren’t just noted but acted on. Assign a quick follow-up plan for each blocker to keep progress going.
5. Keep It Timeboxed and Energizing
Scrums should be short and to the point, but that doesn’t mean they can’t be fun:
Countdown Timer: Use a countdown timer with sound effects to add urgency. This helps keep everyone focused and adds a playful sense of pressure.
Music to Gather: Play an upbeat song as everyone joins the meeting—this small touch can set a positive tone for the rest of the Scrum.
6. Change Up Dynamics Occasionally
Introducing variety in the Scrum’s structure can help fight monotony and spark fresh thinking: Silent Scrum: Once a week, try a written Scrum where everyone posts their updates in a shared document or messaging channel. This can offer a different perspective and give people a break from speaking. Pair Sharing: Break into pairs for updates and come back together to share highlights. This variation promotes deeper discussions between team members and creates a more intimate space for collaboration.
7. Encourage Recognition and Gratitude
Acknowledging each other’s efforts goes a long way in creating a positive team culture:
Kudos Round: Dedicate a minute for team members to give shout-outs to others for help, great work, or going the extra mile.
Highlight Team Achievements: Show progress using visuals, like a chart or dashboard. This helps everyone see how their work fits into the bigger picture and fosters a sense of shared purpose.
8. Prevent Fatigue
Avoid routine fatigue by being mindful of how frequently and strictly you conduct scrums:
Skip Days: Consider replacing one day a week with an async update, especially when the team is in a smooth flow and less in need of daily verbal check-ins.
Shorten Updates: Encourage concise updates, focusing only on what’s necessary. This helps maintain momentum and prevents the meeting from dragging on.
9. Gather Feedback and Adapt
Regularly check in with your team to see what’s working and what isn’t:
Feedback Fridays: Set aside time at the end of the week to gather thoughts on how the Scrum process can be improved.
Anonymous Feedback: Use a survey tool to gather suggestions—this can help you get honest input, especially if team members are hesitant to speak up.
Conclusion
Daily Scrums are intended to be a powerful tool for team alignment, but they don’t have to be monotonous. By incorporating fun elements, adjusting the format, and focusing on value-driven discussions, you can make these daily meetings something your team looks forward to. A bit of creativity and openness to change can transform the Scrum from a routine check-in into an energizing collaboration session that brings out the best in everyone.
Try experimenting with some of these ideas and see what resonates best with your team. Who knows, you might make Daily Scrums the highlight of the day!
As a nearshore software development staff augmentation company with over 20 years of experience, Scio understands the challenges faced by mid-sized tech companies (30-200 employees) in the software development industry (SaaS, Mobile, or On-premises). Recently, our team participated in the Agile Austin virtual event, a valuable forum fostering collaboration and knowledge sharing within the Agile community. This experience provided us with fresh perspectives directly applicable to your team’s success.
Shifting the Agile Paradigm: From Methodology to Mindset
One key takeaway emphasized the importance of viewing Agile as a core company principle, rather than simply a defined methodology. Think of it as a cultural shift, not just a process change. Agile principles such as iterative development, continuous improvement, and collaboration become ingrained in your team’s DNA. One of our Scio Project Manager, Jesús, found a quote from Bob Galen, particularly resonant:
«While intricate solutions hold a certain allure, their complexity can present risks.»
Bob Galen, KAA 2024 Keynote Speaker
This sentiment underscores the crucial role of resilience within Agile environments. Complex methodologies can be cumbersome and hinder adaptability, a key strength of Agile.
Jesús also presented the concept of a «help-o-meter» – a tool that fosters a growth culture by tracking instances of offering and seeking assistance within the development team. This straightforward practice not only strengthens team dynamics and promotes a collaborative spirit, but also encourages knowledge sharing and continuous learning.
Prioritization and Psychological Safety: Cornerstones of Effective Agile Teams
Another member of our team, Angeles, Scio Business Analyst, highlighted the significance of prioritization within Agile teams. By clearly identifying the features that deliver the most value to your customers, you ensure a laser focus on what truly matters. However, the benefits of Agile extend beyond project management frameworks and feature sets. Establishing a culture of psychological safety empowers team members to openly communicate concerns, take calculated risks, and contribute their best ideas. This fosters a more creative and innovative environment, leading to better problem-solving and ultimately, a more successful product. Additionally, tracking Key Performance Indicators (KPIs) allows for data-driven decision-making and facilitates continuous progress. Regularly measuring progress against defined goals allows you to identify areas for improvement and adapt your approach as needed.
Building Successful Agile Teams: Communication, Collaboration, Adaptability
The Agile approach thrives on effective communication, collaboration, and adaptability. Daily scrums become a platform for active participation, transparency, and shared goal alignment. Team members openly discuss progress, identify roadblocks, and work together to find solutions. This fosters a sense of ownership and accountability, leading to a more engaged and productive team. By nurturing these core elements, Agile teams thrive in a constantly evolving environment and consistently deliver value to your customers.
Scio: Your Partner in Agile Success
At Scio, we leverage our extensive experience in nearshore software development staff augmentation to help you build successful Agile teams. We provide highly skilled and experienced developers who seamlessly integrate into your existing teams, fostering an Agile environment that drives results. Our dedication to clear communication, collaboration, and cultural understanding ensures a smooth transition and a successful partnership.
Contact Scio today to discuss your specific needs and explore how we can help you build a high-performing Agile team that consistently delivers value to your customers.
In the world of project management, the Scrum methodology has proven to be a powerful framework for agile and iterative development. But what if I told you that some of the most valuable lessons I’ve learned about Scrum didn’t come from a conference room or a software development project, but rather from climbing mountains? In this blog post, I will share the unexpected parallels between Scrum methodology and mountaineering, unveiling the valuable insights gained from conquering peaks and navigating the challenges along the way.
1. Embracing Iteractive Progress
In Scrum, iterative development lies at the core, breaking down complex projects into manageable increments. Similarly, climbing mountains requires breaking the journey into smaller, achievable goals. Just as Scrum teams focus on completing sprints and delivering value, mountaineers concentrate on reaching intermediate points and base camps before progressing further. Embracing iterative progress allows both Scrum teams and climbers to maintain momentum, assess risks, and make necessary adjustments along the way.
2. Team Collaboration and Communication:
Scrum methodology thrives on collaboration and effective communication within cross-functional teams. In mountaineering, successful ascents rely heavily on teamwork and clear communication between climbers. Just as Scrum teams hold daily stand-up meetings, mountaineers regularly gather to discuss routes, conditions, and strategies. Both settings emphasize the importance of sharing information, addressing challenges collectively, and maintaining a cohesive team spirit.
3. Continuous Adaptation and Risk Management:
Mountaineers face ever-changing conditions and unexpected obstacles on their journey to the summit. Similarly, Scrum teams must adapt to evolving requirements, unforeseen challenges, and shifting priorities. Both endeavors require effective risk management strategies, anticipating potential hurdles, and adjusting plans accordingly. By embracing flexibility, Scrum teams and mountaineers navigate uncertainties and make informed decisions to maximize their chances of success.
4. Iterative Feedback and Learning:
Scrum methodology encourages frequent feedback loops, enabling teams to reflect, learn, and improve their processes continuously. Similarly, mountaineers rely on post-climb evaluations and
debriefings to analyze their performance and identify areas for growth. Both Scrum teams and climbers value constructive feedback as a catalyst for continuous learning, enabling them to refine their approaches and optimize their future endeavors.
5. Focus on Incremental Goals:
Scrum methodology emphasizes setting achievable goals for each sprint, ensuring incremental progress towards the overall project vision. Similarly, mountaineers focus on reaching intermediate waypoints, base camps, or notable landmarks before advancing further. Breaking down the journey into smaller, attainable goals fosters motivation, builds confidence, and provides a sense of accomplishment. It also allows for a reassessment of progress and priorities at each milestone.
6. Resilience and Perseverance:
Climbing mountains and implementing Scrum methodologies both demand resilience and perseverance. Scaling steep slopes or navigating treacherous terrains requires physical and mental strength, as does tackling complex software projects. In both cases, setbacks and challenges are inevitable. However, it is the ability to persevere, adapt, and overcome obstacles that leads to eventual success.
Conclusion:
As surprising as it may seem, the lessons I’ve learned about Scrum methodology from climbing mountains have been invaluable. The parallel experiences of embracing iterative progress, fostering team collaboration and communication, adapting to risks and uncertainties, learning from feedback, focusing on incremental goals, and demonstrating resilience and perseverance are common to both endeavors. By drawing inspiration from mountaineering, we can enhance our understanding and application of Scrum principles, injecting a fresh perspective into agile project management. So, whether you find yourself in a Scrum team or planning your next mountaineering adventure, remember that the journey itself holds valuable insights that can elevate your performance and propel you towards greater heights of success.
Even if it looks otherwise, the software industry is not immune to the effects of recession cycles. During times when spending decreases and businesses become more cost-conscious, budgets for software development projects often suffer, having a significant impact on companies that rely on project-based revenue streams and their employees. And as we’ve seen so far in 2023, an unstable global economy has affected the Technology sector like never before, pushing software businesses today to navigate a very difficult situation where taking the necessary steps to shield themselves from the worst consequences of an economic downturn is critical.
Above all else, a very effective approach for software companies is to be agile and create systems and processes that enable them to adjust staff levels quickly when needed, focusing on minimizing disruption to any ongoing development project. After all, building a flexible team structure with both full-time and contract workers who can respond to current demands ensures that a company remains fully staffed, and resources remain able to be scaled up or down according to the current economic needs of the organization. And implementing effective training methods play an important role here too, guaranteeing that everyone is equipped with the necessary skills to bring a positive outcome for any project even if the team composition has changed. In other words, readiness is key when it comes to dealing with financial unpredictability and having a versatile workforce ready at all times is a big part of this success.
However, in tight budgets, companies often have to make tough choices, cutting back on staff and resources, making it difficult to build adequate teams with the right combination of skills. And if this situation continues for a long period, it can become increasingly tough for teams to maintain their momentum and stay on top of any new trends entering the market, with current staff members often having to take a bigger workload to fill in gaps that larger teams would otherwise occupy. It’s pretty likely that, during economic downturns, a lot of software organizations find themselves limited in the available talent they can hire.
With this in mind, having the ability to scale the size of a software team can be an invaluable asset for any company. Such teams can come together quickly when needed, enabling companies to pivot and take on unique and complex projects that would otherwise be too difficult to tackle. At the same time, this approach allows developers to focus on specific tasks with laser-like precision, resulting in an improved project and output. So, during economically-uncertain times, the most successful software companies can decide about their ideal team size, as opposed to teams limited by what’s available at any given moment. But what is the best option to maintain flexibility in tough times? What choices are available?
Thinking outside the box
In recent years, outsourcing software development has become increasingly popular thanks to the economic uncertainty that has prevailed since the start of the pandemic. Outsourcing allows organizations to take lesser risks, reduce operational costs and, more importantly, attain the necessary flexibility to scale staff up or down depending on the needs of a project, without the cost and commitment associated with hiring additional employees or establishing new departments in the company. Furthermore, it can be easier to forecast expenses when using an outside partner because project costs are fixed and known in advance, as long as a quality vendor is chosen. With companies now looking to stretch their budgets as much as possible to compete during every recession cycle, outsourcing provides an easy option for them to cut costs simply by working with external partners that specialize in the desired tasks.
However, not all types of outsourcing are equal; the specific service must be tailored to match the individual circumstances of a company. Offshore outsourcing, for example, can offer low-cost highly-skilled coding, but working with remote locations (often in different continents) imposes delays, language barriers, and different cultural expectations that can lead to negative outcomes. On the other hand, more localized models such as freelancing might provide heightened responsiveness at somewhat higher rates but with less potential to scale up quickly which, as we already mentioned, is of utmost importance during a recession.
This is where a Nearshore partnership model comes in. By partnering with a Nearshore such as Scio, software companies can benefit from an increased resource pool compared to employing an onsite team, providing additional strategic advantages. Things like access to skilled developers and IT engineers, expanded working hours due to the similar time zones, as well as the excellent user experience achieved by having a more diverse staff are some examples of advantages that companies can get to maintain their competitive edge in difficult economic times, thus allowing them to succeed despite the challenging environment. This is especially true when it comes to the aforementioned flexibility needed to keep the momentum of a project with very specific requirements.
The core benefit of working with a Nearshore partner, in short, is that team size can be dynamically adjusted to fit the specific needs of any project, which eliminates the problem of needing to find and build larger than necessary teams in-house. This means far less time wasted on locating and planning hiring cycles due to sudden additions or deletions from a team, and the ability to rapidly expand or contract their workforce without incurring the traditional drawbacks that come with making similar adjustments. And the ease of access to overseas markets, coupled with localized teams, means businesses can quickly scale up or down without worrying about talent availability, high attrition rates due to tedious onboarding processes, and language barrier issues. With Nearshore teams available at short notice, companies no longer have to strain their resources trying to keep track of volatile demands, enabling organizations to be better equipped to take full advantage of their resource expenditure.
But what if team flexibility is not enough?
In an economic cycle of growth and recession, Technology companies must do their part to protect themselves, and one of the biggest challenges is staying on top of trends, as consumer needs in the software industry are constantly changing and evolving. Adopting or developing new products or services that can help grow their business during both times of growth and recession should play into their strategic planning, of course, and companies should be open to making changes in their business practices, automating redundant processes and streamlining tasks where possible, making adjustments to their product lines if those become over-saturated or if more cost-effective alternatives are available.
And embracing new technologies should never be out of the question, especially with a trustworthy Nearshore partner at your side, which could help increase productivity by taking care of development and training staff on the relevant skills you need. Identifying innovative new ideas for existing services can also help generate new sources of revenue and put the company in a better position when the economy recovers. Staying diversified by offering services across multiple industries can provide stability even in times of economic uncertainty. Lastly, maintaining strong communication with customers allows you to anticipate their needs and prepare for whatever economic situation may arise while also building consumer loyalty which is beneficial both during times of growth and recession.
In short, the world economy is often subject to unforeseen changes, from threats of recession to pandemics. Software organizations must be prepared when unpredictable times arise, no matter how much the market fluctuates. Taking every precaution possible when anticipating economic hardship ensures that a business or organization can weather any storm, making changes as necessary, such as adopting a more flexible approach to staffing, to stay up-to-date on industry trends. Preparation leads to success, so software development organizations must take every precaution possible if faced with an economically trying year to remain strong during the entire season.
The Key Takeaways
Historically speaking, the tech industry has remained strong in the face of recessions, but that might not be true anymore in 2023.
To weather these economically-uncertain times, one of the key approaches is having flexibility in your staff, enabling you to increase or decrease team sizes as the situation demands.
To this end, partnering with a Nearshore company, instead of building on-site teams, is the best approach to accomplish this, enabling a company to access talent as a project and the economy permits.
However, secondary plans, like having a long-term strategy, keeping on top of trends, and being smart about your development partners, might also help to armor a software organization against any economic downturn.
When you are trying to bring a new application to life, code reviews are an essential part of the development process. They help ensure the quality of the code, identify potential problems and bugs early enough to squash them and provide the perfect opportunity to get feedback from your peers. This is a source of insight and helpful criticism that can help a developer grow.
After all, in big collaborative projects such as software development, no part of the process is made in isolation; receiving advice is an important part of every good team, cultivating a better collaborative environment, and establishing a sense of trust and camaraderie among the team. Code reviews, for example, are one of the most important steps in this process, but how they should be conducted, and by whom, are questions to keep in mind when trying to guarantee the quality of any product.
Naturally, this task tends to fall on the shoulders of the more experienced developers of a team, as seniors should know what they are doing and what to look for, but is their input the only valid one? Or should junior developers be allowed to do code reviews for their more experienced teammates? What benefits can a team have by giving the least experienced members such a responsibility?
We want to make the case that allowing junior developers to review the code written by a senior collaborator not only helps them grow their skills, but it’s a procedure essential to ensure quality in the codebase. Any team that doesn’t employ this strategy might be missing a great opportunity there, but what’s the reasoning behind it?
“You can’t win against someone who makes a bet for fun”
In professional poker, winning against amateurs is not exactly guaranteed. Of course, luck is involved, but the technique is important too. Knowing how to read the tells of your opponent, having a good idea of which cards are currently in play, and learning to push your bets at the most strategic moments are part of the toolset of any professional player. And all this can be disrupted rather easily by an amateur with less experience at the game because they are harder to estimate and bluff.
This interesting irony was noted by movie critic Gene Siskel, an experienced player when he lost against his equally famous partner Roger Ebert at a bachelor party: “You can’t win against someone who makes a bet for fun”. In other words, professional player has very specific expectations if they are going against another pro, and their decisions come from a place of knowledge and experience where possibilities tend to be more studied and controlled. So, if you are an experienced developer reviewing the code written by another experienced developer, what exactly do you expect to see? Is that different from reviewing the code written by a junior programmer? Of course, the answer is yes. This phenomenon is called “the expert blind spot”:
“The experts will have difficulty to understand why the beginners don’t understand. For them, the concept feels obvious. The learners, on the other side, won’t be able to ask the good questions either, since they’re not aware of what they don’t know. How to ask good questions if you have no idea what kind of answer you want?”
Although the expert blind spot is usually used in the context of teaching, the difficulties a veteran might have to pass along his knowledge in the context of code reviews are similar to our earlier poker example. A senior reviewing the code of a senior tends to have certain expectations about it, which is both a benefit and a risk: certain things might be taken as “obvious” and not be considered until it’s too late.
After all, anyone who has ever worked on a complex project knows the frustration of feeling where something might be wrong but can’t quite see it. That’s why it’s always a good idea to take a look at it with fresh eyes. In that sense, junior developers can bring a lot to the table when it comes to code reviews, free from all assumptions and rigid pathways that might trip up even the best programmers.
A good way to conduct a code review
However, that is not to say that junior developers should bear the entire responsibility of code reviews; guidance and backup are still needed to ensure they are properly conducted during the sprint. In the words of Carlos Estrada, a Lead Developer Application at Scio:
“It’s generally a good idea to have a junior dev participate in code reviews, it’s useful for them to see what changes a senior does, and learn to find and track changes, but they cannot be the ones to approve the review. There have been a few internal projects I supervised where mostly juniors were involved, and when the time was short, the juniors had to do it themselves, learning from the comments I have left on earlier reviews.”
In short, junior developers are the backbone of any software development team. They may not have as much experience as their senior colleagues, but they can make up for it with a desire to learn and master the craft, which makes them a perfect addition to a thorough code review:
As already said, by conducting code reviews, junior developers can see for themselves how code written by a veteran looks; which good practices are implemented, proper comment discipline, and readability, which can help them become better programmers.
A junior reviewing code can spot mistakes that a veteran might otherwise overlook due to the expert blind spot; a fresh perspective, free of all the expectations and assumptions a senior can unconsciously have, can sometimes obtain a better insight of the code.
However, not all code review processes are created equal, and for one to be effective, it should follow a few simple steps that ensure the resulting review is useful. Many veteran developers may know these steps by heart, but to a junior starting to learn the value of these exercises, the following procedure is always recommended:
First, developers should submit their code for review early and often.
This allows for more frequent feedback and helps to prevent errors from becoming entrenched in the codebase.
Second, all reviewers should have a common understanding of the project’s goals.
This helps to ensure that everyone is on the same page when it comes to evaluating the code.
Finally, reviewers should focus on providing constructive feedback.
By indicating what works well and what could be improved, reviewers can help developers produce better code with fewer errors.
So, to recap, code reviews are an important part of the software development process, and juniors can learn a lot from participating in them. However, they need guidance from seniors to make sure that the code is correct and meets the standards that these projects strive for. And the final approval always must come from a senior member of the team, keeping an eye on the process, and making sure everyone can learn from it. After all, experience builds on the chance to bring new perspectives and let them teach new things.
Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!
The field of software development has a lot of roads, some are more challenging than others. And for Nati Lara, a Front-End dev currently living in Denmark and mom to a toddler, these experiences have been incredible. How does remote work and software impact her job as a mom and developer?
By Scio Team
Whenever someone asks me what I do for a living and I tell them I’m a software developer, the response almost always is “You must be very smart!”, because this preconceived notion of this job is that only the more intelligent persons can do it and, well, no.
It’s like when I see a carpenter doing their thing, and I say to myself “I could never do that”, but if it really interests you and you want to make your ideas into reality, it’s within everyone’s reach.
I started programming back in High School when a teacher helped us learn to use Delfi by designing a simple website. It was a very interesting exercise, having to do an entire page by myself; it was the final project of the semester and everyone did whatever they wanted, but I got really into it.
It was a gripping challenge because the teacher didn’t explain much, so we had to make with whatever solution and tools we had on hand, and I liked that a lot. Delfi already has some basics, so we didn’t have to start from scratch, writing zeroes and ones, which changed my ideas of programming. I used to think it was a black screen with green text on it like in the movies, so it was a different experience.
I used to like computers a lot as a kid, my parents got their first one when I was 10 years old, but I didn’t know anything that had to do with programming. I was curious about interfaces, not as much as the inner workings, and that’s what I specialize in today.
That’s why I do Front-End in iOS, I like things where I can see the result. I don’t get too much into Back-End stuff, where I don’t have a clear vision of how things are working, I prefer working on things where I can see the immediate result.
As a developer, the best feeling I get is when I can put my ideas in motion, and make something useful out of them, building a work of art without using my hands directly, so to speak. I like working with others, knowing everything about every part of a project, and contributing in a specific direction. The client I’m currently working with makes vegan and vegetarian food; the chefs here run the kitchen and develop recipes that avoid meat, trying to show that the absence of it still results in a good dish.
Their clients subscribe to the app I’m maintaining, and they get pre-made meals for three days, all vegan. There are many ideas involved with this project, like showing how much CO2 is being saved by avoiding the consumption of meat. I like it because, beyond the food, it tries to show the individual impact we have, and it even changed my conception of vegan and vegetarianism, which has changed since I work here and now I want to do my part.
The road here wasn’t a straight line. I originally studied Art and Digital Animation, because even though I always had some affinity for STEM stuff, I also liked creativity, drawing, and graphic design, but I didn’t want to go completely in that direction. So I tried something that had a bit of everything, but I ended up realizing that I liked it a lot, but maybe I wasn’t as good at it.
At some point, I started developing web pages with a friend that wasn’t very good at programming, but skilled at designing, so we started taking freelance jobs where I did the technical stuff and she did the visual part of the project.
That is how I ended up pursuing a Master’s degree in Software Development because I found it the best way to keep in touch with both worlds. I’m a developer, and I like having an opinion on everything visually going on during a project; when doing a website, I like to make sure everything lines up, looks good and works well. Even if I don’t consider myself the best designer, I like to pay attention to the details of it by programming.
For a degree like this, a proportion of 30% women does not sound like a lot, but it is, even if women are the most prone to abandon it before finishing. In Digital Design it was more balanced, around 50/50 or so, but here it was a noticeable difference. I think this ratio holds in most engineering careers, and in our culture at least, more women go for careers in Humanities like Arts or Social Studies, and a lot less in STEM.
My dad was a teacher, and he always raised us close to the sciences, so it wasn’t an issue for me, but my parents did prevent me from trying things like sports, especially soccer. I mean, I still don’t play it, but I also never had the opportunity, even if my dad somehow planted the seeds of interest in sciences like math.
As a female developer, though, I have never felt out of place or made feel less, although I’ve never worked full time in Mexico. I currently live in Denmark, and so far I have been the only woman in the Tech team of both companies I have worked at.
There were more women at school, that’s for sure, but right now we are fifteen people in the Development department, and to be honest, I like it that way. A lot of owners and entrepreneurs are feeling the pressure of attracting women to close the gap between male and female developers, so it has been easy for me so far to find a place to work. Being a woman in this industry is an advantage some of the time. There’s nothing to be intimidated by.
It’s even funny sometimes. At work parties, I’m the only one trying to dress well and use make-up, and my friends like to joke about it, saying that my job is making sure everything looks great, so of course, I do those things.
That being said, it’s curious to notice that, at companies like Scio for example, most women tend to gravitate towards analytical and QA stuff. I wonder why that is. I’ve never met another woman doing Test Automation or things like that; last year a girl started working with us in Full-Stack but doing Data Analytics, and everyone else has always been men.
It’s something I talk about a lot. I have many friends dedicated to Humanities, and we always discuss the differences between our fields; in the case of one of them, her office is almost purely women, with one or two guys here and there. I guess there are many reasons for it, and I have wondered before why it’s so important to close gaps in certain areas.
I don’t see a field dominated by either gender as something inherently wrong, if these differences were dictated by more biological, natural affinities, like women being more social or men being more analytic. But when those exclusions are cultural when we try to separate genders from childhood by allowing kids to play with certain toys only, we are creating inequality, and something should be done about it. And this is a change that we are not going to see in the next year or two, but it will take maybe an entire generation to change these points of view.
Now, in the actual job, do these differences matter? Maybe I have different aesthetic sensibilities and ideas of how things should look, so I can tell my coworkers an application needs, but I’m not sure that’s because I’m a woman, or because I have a background in Design. Who knows?
Being a developer has also brought other advantages for me. I have a son currently four years old, and working in software gave me a lot of leeways to define my schedules and limits, define my own way to work, and leave enough time for my family. I feel like I’m more productive, with better control of my time, and applying a developer point of view to raising my kid, where I accomplish big things by dividing it into smaller tasks, finishing each, and going from there, has helped me a lot.
Also, I’m used to staying up very late at night, so being a developer has also helped me a lot with that. Working in software, then, is very freeing and flexible, and I’m glad I could do it even before I was a mom. I don’t have to go to the office all the time, I can get along anywhere and the pay is not bad at all, so my quality of life is something I’m really happy about.
