The Toyota Production System in software development: Lean, Agile, and Effective.

The Toyota Production System in software development: Lean, Agile, and Effective.

by | Sep 30, 2022 | Product Development, Project Management

Curated by: Sergio A. Martínez

Software development is a notoriously unpredictable process. Even the most experienced developers can find themselves facing unexpected challenges and surprises which can lead to frustration, as new requirements pop up, deadlines change, and unanticipated bugs can throw everything off course, especially as projects grow in size and scope, and a tighter collaboration and approach is needed.

The-Toyota-Production-System-in-software-development-Lean,-Agile,-and-Effective-icono

As a result, in such a volatile industry, it’s important to avoid waste whenever possible; anything that doesn’t add value to the end product, from inefficient code to unused features, should be left off, as it helps to keep development costs down and ensures that the final product is as high-quality as possible. 

However, due to how unpredictable software development can sometimes be, a good approach is to use lean practices. Lean practices in software development aim to create more value for the customer while minimizing waste. This is achieved by constantly improving the process and eliminating anything that doesn’t add value, helping to reduce the risk of errors and defects by catching them early on.

Our current model of lean development comes from the Toyota Production System, a manufacturing approach that seeks to make the whole process as efficient as possible in seven key areas: overproduction, inventory, motion, defects, over-processing, waiting, and transport. And although the material processes involved in manufacturing cars and developing software look very different from a distance, applying this same logic brings even better outcomes; common lean practices include things like continuous integration, continuous delivery, and test-driven development, in addition to reductions in the cycle time and batch size, so developers can ship working software more frequently and get feedback earlier, allowing them to make course corrections sooner, leading to a more efficient process overall. 

As a result, lean practices can lead to significant improvements in software quality and developer productivity by promoting continuous improvement and efficient use of resources. By identifying and removing unnecessary steps, lean practices help to improve quality and speed while reducing costs. In an industry where time is always of the essence, lean practices can play a vital role in helping developers deliver high-quality software on time and within budget.

Lean Manufacturing and Agile Methodologies, hand in hand

The Toyota Production System in software development Lean, Agile, and Effective. 3

“Both approaches have their strengths that complement each other very well. On one hand, lean manufacturing is all about efficiency and minimizing waste, and on the other, Agile focuses on flexibility and responding quickly to changes”, says Luis Aburto, CEO, and Co-Founder of Scio. “Together, these two methodologies can help to create a process that is both efficient and adaptable; for example, Agile can help to identify areas where lean manufacturing could be improved. And lean manufacturing can help to streamline the Agile process and make it more efficient, enabling developers to create a process that is both responsive and efficient – the perfect combination for today’s ever-changing landscape.”

But what do these lean practices look like in an Agile environment? By adapting the Toyota System into a software development process, we can come up with a series of key areas or steps where it’s possible to avoid waste, and thus create products that accomplish the goals of the client, the team, and the project in the least wasteful way possible. Such key areas are:

1. Unnecessary Features.

There is an oft-cited study by the Standish Group that famously says that “45% of the features in a given application are never used”. If that number seems too high, you may be right (it was based on four internal applications, which is a small sample), but trying to keep requirements in check is a key point of lean development. If your requirements team tries to anticipate everything a client might want in their product, it’s easy to add features that will not matter to the final user. An Agile methodology, then, which prioritizes the most critical features, is the best strategy to save resources otherwise wasted on elements nobody needs or wants.

2. Unnecessary Value.

Following the last point, there is such a thing as unnecessary value, also known as “gold plating”, which is devoting too many resources to polish a product in places where it’s not necessary, risking the cost-effectiveness of a project. “Good enough” is not a bad approach, especially in software where a finishing point tends to be nebulous at best, and continuous support, debugging, and updating is a normal part of the job.

3. Unrealistic Expectations.

Most of the problems of these last two points stem from overestimating the resources, time, and effort needed to accomplish a project, and thus overpromising on a result. Trimming down requirements to their most basic and critical not only helps a team to get going with development but also ensures they can make the necessary progress on each sprint, focusing on a narrow set of variables easy to control and correct. Going beyond that only ensures problems down the road.

4. Unnecessary Innovation.

Ready-made solutions to challenges and obstacles in development are not forbidden; getting stuck “reinventing the wheel” is an easy way to waste resources and delay a product in search of a completely new approach that might or might not have benefits in the long run. No-code solutions to prototype applications, AI-based tools to look into coding solutions, and the like are tools that can have a marked positive outcome when striving for timely delivery each sprint.

5. Unnecessary Downtime.

Waiting for a team, or even a single developer, to deliver to another to continue development is seldomly a process that results in efficiency. One of the key points in Agile methodology is to structure development to avoid this downtime, with short overlapping steps that ensure no one gets stuck and delays the contributions of the rest of the team and splitting development into blocks where “the business owners can identify the next set of features while the development and QA teams can implement the last requirements.”

6. Over-relying on QA.

Going back to our “good enough” philosophy, achieving this result doesn’t mean that developers can let their guard down concerning bugs and errors in the codebase of the product; good lean development has quality implementation at each step of the process, with QA as a continuous process that audits development at each step. Code reviews, unit testing, and constant communication are key to reducing the time and resources necessary in QA to achieve the best possible product.

7. Underused Creativity.

The Agile methodology knows the value of creativity and problem-solving as a tool during development, letting each member of the team add their knowledge, experience, and insight into the perfect solution for any programming challenge. Treating development as a machine where every cog has a specific function, without context, collaboration, or communication, is a sure recipe for negative outcomes if the individual developer doesn’t have the flexibility to bring any useful input they might have.

Bringing Agile talent to your team

The Toyota Production System in software development Lean, Agile, and Effective.

When it comes to software development, the lean approach is all about doing more with less, having the goal is to reduce waste and increase efficiency by streamlining the development process and choosing the right talent and collaborative environment that can be conducive to that, with Nearshore augmentation offering an alternative that brings the best of both approaches.

One of the benefits of Nearshore development is that it is easier to implement a lean software development process. This is because the team is already in place and there is no need to go through the hassle and expense of setting up a new office or hiring additional staff, saving on time and resources when starting a new project. In addition, nearshore teams are typically more flexible and responsive than offshore teams, making it easier to implement changes rapidly. 

“As the software development landscape evolves, more organizations are turning to lean and agile methodologies to streamline their processes and deliver better results. And while these approaches can offer a number of benefits, they tend to work best when teams are nearshore”, explains Luis Aburto. “Nearshore teams tend to have a better understanding of the local market and what customers are looking for. This knowledge can be invaluable when it comes to developing software that meets the needs of the target audience. Additionally, nearshore teams are typically more responsive to changes and feedback, which is essential in an agile environment.”

As a result, lean software development processes can be more effectively implemented with a Nearshore team in place. This can lead to quicker turnaround times and reduced costs, making it an attractive option for businesses that are looking to improve their bottom line. In addition, it is important to build flexibility into the development process, being willing to adjust plans on the fly and make changes when necessary. By remaining flexible, developers can ensure that their projects stay on track, even when faced with unexpected challenges.

The Key Takeaways

  • The unpredictability of software development can create situations where avoiding “waste” (of time or resources) is the main obstacle to productivity and the effectiveness of a development cycle.
  • The “Toyota Production System” can offer some guidance for a lean development approach that can help alleviate these challenges.
  • Lean development is as its most effective when paired with an Agile methodology, feeding each other to achieve peak effectiveness and the least waste during any given project.
  • Working with Nearshore talent to augment your staff is also a great option to avoid waste, as an organization doesn’t need to commit time or resources to build a team and start development right away.

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 Bus Factor and Nearshore talent: A net positive outcome

The Bus Factor and Nearshore talent: A net positive outcome

by | Sep 2, 2022 | Nearshore, Outsourced Engineering Team, Project Management, Software Development

Curated by: Sergio A. Martínez

When you’re cooking up a new software application, it’s important to think about the future. We have talked before about measures like futureproofing, refactoring, and how to deal with technical debt to maintain an application in the long run, but let’s look today beyond the product, and think instead about the team in charge of helping it become a reality. And “the Bus Factor” is key in all of this.

What does "Bus Factor" mean?

What does “Bus Factor” mean?

Chances are you won’t be the only one working on the project; at some point, someone will need to pick up where you left off. It happens all the time, as it is not very realistic to expect that the same people that build a piece of software will be around forever to take care of it when the need arises. 

That’s why it’s important to have a robust risk assessment approach to development, identifying anything that could jeopardize the success of a project. This includes both technical risks, such as the possibility of errors in the code, and non-technical risks, such as changes in market conditions. Risk assessment is an important part of project management, helping to identify potential problems early on and develop plans to mitigate them. There are several different methods for conducting a risk assessment, but all involve breaking down the project into its component parts and evaluating each one for risks. 

And when it comes to assessing risk in software development, the Bus Factor is an important consideration to ensure a project not only gets finished but also can be trusted to work in the long run. Simply put, this factor indicates the number of people who would need to be proverbially “hit by a bus” before a software project would be severely impacted and stall. If your Bus Factor is 3, for example, that means that losing 3 people is all you need for the project to fail, so measures to bring that number up become necessary to guarantee a good outcome in development.

As a result, it’s essential to pay attention to the configuration of a team when developing software. By ensuring that team members are aware of the codebase, that collaboration is encouraged, and that everyone is on the same page, you can help to reduce the risk of potential problems down the line.

A bus is always around the corner

The Bus Factor and Nearshore talent: A net positive outcome

So, with proper risk assessment, software development projects can be more successful and less likely to encounter unforeseen problems. That’s why it’s important to increase your Bus Factor; if too few people know how the code works, if the tasks are too partitioned, or if there’s no good collaboration between team members, then the project is at risk. A low Bus Factor can lead to problems when people leave the team, get sick, or are otherwise unavailable, bus involved or not. 

“Losing key people during development can be devastating. They can take with them valuable knowledge and expertise that can be difficult to replace, as well as disrupting the workflow and causing delays”, says Adolfo Cruz, PMO Director and Partner at Scio. “However, the worst part of losing key personnel is the impact it can have on morale. When experienced and talented individuals leave, it can be demoralizing for those who remain and damage an organization’s ability to attract new talent. It’s a ripple effect that extends far beyond the immediate impact on the project.”

So, when it comes to increasing your Bus Factor, there are two sides to take into consideration. The first one, the technical part, is simple enough: losing people can make it difficult to make changes to the codebase, since there may be no one who understands how it all fits together, and some good practices in project management are important to reduce this risk as much as possible. For example:

  • Use comments liberally. Some programmers believe that comments are essential, while others feel that they only clutter up the code. After all, well-written code should be self-evident, and easy to understand, but in a complex project with many people involved, it never hurts to explain what the code is doing and why. If you need to bring someone entirely new to the project you can easily waste time trying to reverse-engineer some vital functions of the application. So even if the code looks obvious, leaving comments just to be sure it can be understood in the future goes a long way toward ensuring a project can be maintained properly. 
  • Write clear and concise documentation. On the same token, this will help others understand the design decisions behind your code. Without clear and concise documentation, it can be difficult to keep track of the various code dependencies and file hierarchies, essential for ensuring that the project runs smoothly. In addition, documentation can be extremely helpful when it comes to debugging (which may not be done by the exact same team that wrote the code), aiding to pinpoint the root cause of a problem more quickly.
  • Hold regular team meetings. The Agile methodologies in software development have done wonders for team collaboration, offering a way to keep everyone up to date on the project’s progress and ensuring that everyone is on the same page. Additionally, by keeping everyone in the loop, points of failure can be identified before they become a problem for the project, making regular meetings with the team a must for a well-managed development cycle.

By taking these steps, you can help increase your Bus Factor and make it easier for others to step in and continue working on your project if something happens to a key member of the development team. Nevertheless, the challenges of maintaining a project can go beyond the product itself, and with the way development works today, a different approach might be needed.

What happens when the bus is in another country?

Ghost-Colleagues

Software development is a notoriously challenging field, and one of the biggest changes we are currently living through is the normalization of remote teams, an increasingly likely outcome in a post-pandemic world where the advantages of having a hybrid approach and collaborating with external people, have become clear.

However, how does the Bus Factor come into play when your team is distributed over a wide geographical area? With so many options in outsourcing or hiring freelancer developers to collaborate on a given project, management has an increasing challenge in keeping everyone looking in the same direction and minimizing any risk involved in not having direct contact with a team. The challenge is that software development often requires very specific skills to carry through, from programming languages to types of technology being worked on, and the Bus Factor gets lower as more variables are involved in development.

“The complexity of a project isn’t necessarily the biggest problem contributing to your Bus Factor; that dubious honor goes to the subject’s specificity. The more specific your topic, the worse your bus factor will be. More specifically, if all other factors remain constant, your bus factor will decrease proportionately to how much specific expertise is required to carry out your work”, explains the blog “How to Beat the Bus Factor (and Be Prepared for Anything)” published by the workflow management company Process. st.

This is especially true when a project requires very specific skills that are hard to find. For an extreme example, imagine you’re working on a project requiring knowledge of a particular software library that only a handful of people know how to use. In such a case, it can be nearly impossible to find someone with the necessary skill set, and in case you do, how do you ensure that person not only remains during the entirety of development but also can come back and help if something goes wrong? Or leaves enough documentation behind so other people in the team can continue? If those questions are a concern, a different approach may be needed.

“As the benefits of Nearshore collaboration become more widely recognized, even more businesses will likely choose to partner with developers in Mexico and Latin America”, says Luis Aburto, CEO, and Co-Founder of Scio. “There are many reasons for this trend, but one of the most important is the increased collaboration that Nearshore development enables, letting developers in nearby time zones to integrate easily to a specific project.”

The option of Nearshore is attractive if an organization is looking to increase its Bus Factor, guaranteeing a positive outcome in the development cycle. You may have heard of Nearshore companies before, easily confused with mere outsourcing at first glance, but unlike trusting development to an external team (often in faraway locations such as India or China), the Nearshore model offers many benefits, including shorter project timelines, competitive costs, and reduced risks within the same time zone, allowing for a smoother collaboration no matter where in LATAM is the talent you want. 

In the case of Scio, we offer teams of skilled and experienced developers working together, putting collaboration and knowledge-sharing as some of our core tenets. This way, some of the common approaches to increasing the Bus Factor (like cross-training developers in a multitude of skill sets, empowering developers to grow and take on more challenges, implementing Agile methodologies, encouraging close communication at every level, and generally fostering a culture of collaboration and team-focused mindsets) are endemic to Scio, where not only we ensure any onboarding process in a new project is as seamless as possible, but also that everyone is continually learning and growing with new skills, offering knowledge and insight at every turn. In the rare cases, the Bus Factor comes into play, have ready-to-go measures to minimize its impact.

In short, the Bus Factor is an important part of risk assessment in every software development project, and increasing it as much as possible is always the best policy. So next time you or your company is looking into bringing talent to a team to complete a project, think of the best options out there to manage this risk as best as you can. 

The Key Takeaways

  • Risk assessment is important for every software development cycle, and the Bus Factor is one of the most critical metrics to watch out for.
  • In short, the Bus Factor is the number of people that can leave a project before it stalls completely, leading to negative outcomes for development.
  • Good practices can be implemented (like a commenting discipline, through documentation, and having consistent meetings to keep everyone in the loop) can increase the Bus Factor in any project.
  • However, when it comes to working with remote or distributed teams, the Bus Factor can increase depending on the approach of this collaboration.
  • Nearshore development can offer a solution, with organizations like Scio offering the support and culture necessary to ensure collaboration is a success, and a positive outcome can be reached for the project.

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!

Ghost colleagues: Creating a sense of professional connection in the age of remote work.

Ghost colleagues: Creating a sense of professional connection in the age of remote work.

by | Aug 29, 2022 | Project Management

Curated by: Sergio A. Martínez

There is such a thing as a colleague in the age of remote work? As we begin to get accustomed to working far away from the office, even for a couple of days a week, some of the things we took for granted in the past have begun to be re-examined and appraised after the pandemic started, especially around the social side of things.

Ghost-Colleagues-1

On one hand, remote work started to be normalized, bringing a lot of perks with it: the ability to set your own hours, avoid commute times, and save money on office expenses, as well as a greater sense of control and flexibility over your work life became invaluable for many people, and the ability to design their workspace and create a flexible schedule seemed to outweigh the drawbacks of this model.

But on the other, there’s a challenge in adjusting to working in isolation; in the modern reality of work, more and more people are finding themselves trying to create meaningful professional relationships with colleagues through a screen, and this complete absence of human interaction can have some effects not only on the mental well-being of a person but also how their professional career changes and develops.

But what is a colleague? Just someone you work with? Or does it encompass a lot more? A colleague, to put it simply, is someone you can rely on, whether you need help with a project or just a sounding board for your ideas; it’s someone who will challenge you and push you to be your best, and who will support you, both professionally and personally. Having a strong network of colleagues has been thought essential for any successful career, but now, forming these kinds of bonds seems to be getting more difficult by the day.

A workplace of ghosts

Working in software development can be a great career; you get to use your creativity and technical skills to solve complex puzzles and build products that people use and enjoy. However, it’s also a very collaborative effort that often needs a well-synchronized team looking in the same direction to succeed. So, what has been the effect of remote work when forming bonds with a colleague to create a successful product? 

“I think the biggest challenge when working remotely is that you don’t know your coworkers very well, which can make communication difficult”, says Julián Verján, a developer at Scio. “Establishing bonds beyond the job, like friendships, is difficult. I feel like, once we stop being coworkers, that connection can get lost easily, something I feel doesn’t happen as much with more face-to-face interactions.”

Beyond productivity, which has increased noticeably during the pandemic, the challenge faced by most modern software development organizations is more cultural in nature; missing out on the daily interactions that help to build relationships, or the opportunities to collaborate and learn from each other can have consequences on the overall cohesion of a team. 

“Contact is important. You are more excited about your work and meeting new people. Personally, in the Marketing department of Scio, I feel I have to be updated by my colleagues, and which new projects they are working on, etc.”, comments Ari Hernández, a Digital Media Designer also at our company. “I think immediate communication is the biggest challenge. I’m now used to scheduling video calls to discuss the smallest things when I could just walk up to the person in the office and ask. And there are things that you cannot communicate as easily through chat or video calls.”

This has given rise to the term “ghost colleagues”, the people on your team who you never actually meet in person since you’re both working from different locations. Even though you may never meet face-to-face, you still have to collaborate with them on projects and stay in communication via email, platforms like Slack or Microsoft Teams, or video chat. And it can be tricky to build a rapport with someone when you’re not actually in the same room, especially without any downtime at all between interactions, which tend to always be work-related. Additionally, if you have questions or need assistance with something, it can be harder to get help from a ghost colleague than it would be from someone right there in the office with you.  

“I would define the relationship with my coworkers as purely professional. Everybody is very nice to each other, but I feel it could be different with more face-to-face interactions. The good thing is that many here have the same sense of humor as me”, says Ari again, about her feelings towards remote work.

And this approach to colleagues has noticeable effects on the work itself, and how a worker approaches their job; a study cited by the BBC says that “part of the reason is that these social ties people have in the workplace feed into their sense of attachment and belonging at work. […] 65% of workers who had switched to teleworking all or most of the time felt less connected to their colleagues than they did before. A second study showed almost a quarter of workers felt disconnected from goings on in their company overall.”

Bringing the team together (at distance)

Ghost-Colleagues

Of course, a lot of the responsibility of bringing everyone together, even remotely, rests upon the culture built inside an organization; is not enough to just connect developers and tell them what a client needs (the “how” of remote teamwork), but to ensure the collaborators are looking in the same direction, sharing the same values, and moving to the same rhythm (the “why” of remote teamwork”). 

“Speaking strictly about the job, I’ve always felt very comfortable thanks to the Scrums we do every day. We all know what everybody else is doing during that day, making it easier to move as a unit”, says Julián again. “I think the biggest challenge is not knowing your coworkers very well, but Scio solves this pretty well. They do like to organize calls and activities to just kick back and relax, get to know each other, and even practice our English. It’s pretty neat.”

Anyone who has ever worked in an office knows that a positive relationship with your colleagues is key, which is why Scio likes to promote good chemistry among every collaborator. For one thing, a good working environment is more enjoyable and motivating, and when you get along with the people you work with, you are more likely to feel like part of a team and be invested in your job. Moreover, a good working relationship with your colleagues can lead to better collaboration; if everyone is on the same page, it can make it easier to get work done.

“I think a hybrid approach is the best. It lets you build a connection with your partners, and personally, I like to dress up and get out of the house”, says Ari. “I’m glad there’s the option to work from home, even if I found it difficult to adapt at the very beginning. I feel productive now that my routine is pretty well established, but I’d still like to visit the office sometimes.”

The workplace can be a lonely place if you’re the only person in your office, after all. You might feel like you’re on your own while keeping up with the workload, and when you take a break, there’s no one to chat with about the latest office gossip. But it’s important to remember that you’re not alone, especially if your workplace offers ways to connect with your colleagues, so here are a few tips for overcoming this kind of isolation: 

  • Try to socialize. Even if you’re not naturally outgoing, force yourself to chat with your co-workers or strike up a conversation with someone new. You never know when you might make a new friend.
  • Get involved in company activities. If your company offers any type of social event or team-building activities, make an effort to participate. It’s a great way to meet new people and build relationships.
  • Don’t be afraid to ask for help. If you’re feeling overwhelmed, reach out to your supervisor or a coworker for guidance. Asking for help is a sign of strength, not weakness, and you might even strike a deeper connection with someone that way.

Just because they’re not physically present doesn’t mean they’re not interested in getting to know you. By trying to connect with others, you can overcome the challenge of working remotely and avoid feeling isolated, and have a better sense of community to make development as enjoyable as it can be.

The Key Takeaways

  • The term “ghost colleagues” has become famous thanks to the fact that most remote collaborators do not have the opportunity to work face to face with their peers.
  • Although remote work has many perks, this isolation can give some side effects that a company with good culture has to minimize.
  • A hybrid approach seems to be the most popular option; by giving a chance to meet in person, while not taking away the benefits of a remote office, most developers can find their own balance and feel more connected to their colleagues.

Scio is a Nearshore software development company based in Mexico where we believe that everyone deserves everyone should have the opportunity to work in an environment where they feel like a part of something. A place to excel and unlock their full potential which is the best approach to creating a better world. We have been collaborating with US-based clients since 2003, solving challenging programming puzzles, and in the process showcasing the skills of Latin American Engineers. Want to be part of Scio? Get in contact today!

The Rubber Duck Method: What is the explanation behind this debugging approach?

The Rubber Duck Method: What is the explanation behind this debugging approach?

by | Aug 22, 2022 | Project Management, Technologies

Curated by: Sergio A. Martínez

Debugging software is an important, if often tedious, the task for any programmer. Finding and removing errors generating crashes, freezes, or incorrect results is critical to ensuring the quality of a piece of software, and while some bugs can be fixed with a few simple tests, more difficult ones require special approaches and techniques. And thankfully, there are many resources available to help programmers debug their software; after all, with patience and perseverance, even the most difficult bugs can be squashed.

The Rubber Duck Method: What is the explanation behind this debugging approach?

One such technique is the popular Rubber Duck method, which may already be familiar to a seasoned developer. In short, the Rubber Duck method is a debugging approach in which developers explain their code line by line to an inanimate object, such as a rubber duck. This may sound silly, but it’s an incredibly effective way to find and fix mistakes. 

“Computers process information differently than humans do. Anyone who’s first learning to program understands this well. What’s hard about programming for a beginner isn’t really big hard esoteric concepts, but that you’ve got to be so painfully exacting in how you describe everything to a (dumb) computer. That’s why we do rubber duck debugging.”

However, have you ever been curious about why this approach works? What exactly happens in our brains when we verbalize a problem to someone else (even if that someone just happens to be a bath toy), that could lead to a solution that was obvious all along? And what is the best way to implement this method to finally find and solve that bug that has been bothering you all week?

The challenge of language

Computers are dumb. And we don’t mean that in a Luddite, anti-tech sort of way, we mean it in the original definition of “dumb”: incapable of human speech. And speech here is more than just talking; speech includes context, mood, choice of words, familiarity, and an infinity of other variables that a computer can’t understand (yet).

Of course, this doesn’t mean that we cannot communicate with computers, it just means that we use specialized languages to do so, and every single one of them works with the principle that computers are dumb: unless you tell a machine exactly what they need it to do, or how to react when something happens, they will not produce a desirable outcome. Thoughtful Code put it best:

“‘Is it cold outside?’ is a question that most humans, having some idea of the weather, will answer pretty easily. They’ll say something like, “No, it’s pretty nice.” Asked that question, a computer — or a really finicky and hyper-rational person — will need you to define each of those words.”  

A computer understands the most literal and absolute terms and learning to manipulate those terms is the basic principle of programming. This also means that computers don’t make mistakes, people do. So, if something within the instructions given to the machine doesn’t add up, then the program will not work as intended, and finding the exact place where the communication between a person and a computer got out of alignment can be a challenge. Here’s where the rubber duck comes in handy, thanks to the way we process language.

Here’s a fun fact: did you know that reading, writing, and speaking are located in completely different parts of our brain? Our understanding of the way we use and apply language is always evolving, but it is understood that we use different functions depending on the type of language we employ, which is why it’s so useful to verbalize a problem to find a solution: you involve a completely different part of your mind to help.

Of course, the Rubber Duck method is not useful only in software development, but since computers are very linguistically complex tools (being probably the only ones we need to “speak to” to use), verbalization is useful here, forcing developers to slow down and think about the minute details of their code, which can help to spot mistakes that they would otherwise overlook. As the blog “The Psychology Behind Rubber Duck Debugging” puts it:

“A lot of times, I’ve experienced some programmers that will ask my help about a specific bug they are fixing. I will then ask them how their application and their code works. I literally have no idea how to fix a program that is not mine and have no idea about the flow. However, I let them explain the flow of the process and the connection between functions and files. Oftentimes, they think of a solution before I even understand what is happening. Many people have been so thankful for me — for doing literally, nothing.”

Programmers understanding themselves

The Rubber Duck Method: What is the explanation behind this debugging approach?

You can see the same principle at work in the classroom. Teachers probing students with questions are intended to make sure a lesson has been learned, forcing the students to consider and explain it by themselves. The only difference is that a programmer using the Rubber Duck method is taking both roles (teacher and student) at once. 

In other words, this method allows developers to share their thoughts with a neutral party, questioning and probing themselves regarding their code, which can help identify areas of confusion or misunderstanding. And most importantly, it encourages developers to develop a clear and concise explanation of their code, which can be useful for future reference. 

“The real magic doesn’t happen on the rubber duck itself (sorry, Duck Norris). However, it happens in our minds. It uses the same psychological principle wherein we are encouraged to explain to ourselves why we did such actions and have a self-realization about what we’ve done. It is usually used by most psychologists to fully understand a person and, at the same time, for the person to understand himself/herself fully.”

And understanding yourself is fundamental to being a good programmer. Just like writing any other thing (a novel, or a sheet of music), everyone has their own style, approach, and technique when coding an application, which makes the ability to explain what you wrote so important; if you aren’t able to understand your process inside and out, then debugging will always be a challenge, especially when working as part of a team, where the code must always be in sync. In fact, the Rubber Duck method can be used as a form of collaboration, as another programmer can serve as your rubber duck and offer feedback or suggestions while you go through your code trying to find an answer.

“When working on a software development project, it’s important to have a good collaboration method in place, and the rubber duck method is one way to ensure that everyone on the team is on the same page”, says Jesús Magaña, Senior Project Manager at Scio. “It can help a developer to articulate his or her thought process, and as a result, team members can quickly identify any gaps in understanding and address them before they cause problems. Additionally, the rubber duck method can help to uncover errors in logic or coding syntax, and overall is an effective way to ensure that everyone on the team can contribute.”

In a Nearshore development environment, where collaboration has come a long way in recent years, the Rubber Duck method can also be useful to bring keep everyone on the same page by improving communication, helping maintain contributions clear, and easing the challenge of solving a tough bug even in remote settings (where a developer may not have anyone to immediately bounce ideas or solutions during debugging), which can help projects to come together more easily. After all, Nearshore software development has its challenges, but by using the proper approach (or bath toy), teams can overcome obstacles and build better software together.

The Key Takeaways

  • A bug in the code is basically a mistake in communication between a developer and a computer.
  • Following this, it’s no wonder that approaches to problem-solving like the Rubber Duck method can help to find the precise place where a code is not working.
  • Although you only need something to talk to (like a rubber duck), this process can involve many people in a team, offering advice and feedback.
  • However, in remote setups (like with a Nearshore development partner), having a way to find and fix bugs without the insight of anyone else can be a valuable resource.

Scio is a Nearshore software development company based in Mexico where we believe that everyone deserves everyone should have the opportunity to work in an environment where they feel like a part of something. A place to excel and unlock their full potential which is the best approach to create a better world. We have been collaborating with US-based clients since 2003, solving challenging programming puzzles, and in the process showcasing the skills of Latin American Engineers. Want to be part of Scio? Get in contact today!

Maintaining Productivity: Is the Pomodoro Technique for you?

Maintaining Productivity: Is the Pomodoro Technique for you?

by | Jul 27, 2022 | Project Management

Curated by: Sergio A. Martínez

One of the main challenges for software developers everywhere is maintaining a high level of productivity throughout the day. No matter the size of the project, or how interesting the final result may be, it will involve hours coding away, looking at a screen, trying to stave off distractions, and keeping engaged long enough to accomplish a good outcome at every stage of production. And that can be difficult.

Maintaining Productivity: Is the Pomodoro Technique for you?

We have talked before about ways to make the most out of your workday here at Scio because we understand the importance of this focus and engagement, and today we want to dive into a popular technique that promises to effectively manage your productivity, allowing you to finish all the tasks involved in that sprint currently closing on you: the Pomodoro Technique. Have you heard about it? Has it helped you? What’s your take? Let’s dig into it and find out!

The key to productivity in software development

MAINTAINING PRODUCTIVITY: IS THE POMODORO TECHNIQUE FOR YOU?

There are several ways to increase productivity when working on software development projects. First and foremost, it’s important to have a clear understanding of the project requirements to focus your efforts in the right place and avoid wasting time. Secondly, use tools and processes that are designed to improve efficiency; many software development tools already include features that can help automate repetitive tasks. And finally, take regular breaks to avoid burnout; by giving yourself some time to rest and recharge, you will be able to come back to your work with fresh energy and ideas. This is where the Pomodoro Technique comes in.

We know the software development process can be a long and complex one, often involving multiple team members working on different parts of the project at the same time, which makes it difficult to stay focused and ensure that each task is completed efficiently. The Pomodoro Technique, which breaks down work into short intervals followed by breaks, allows developers to take on small tasks and then rest for a bit before starting the next one, preventing them from getting overwhelmed or bogged down in a single task. 

The beauty of the Pomodoro Technique is that it’s easy to get started and there’s no need for expensive tools or software. All you need is a timer and a way to keep track of your progress. The technique is effective in helping people focus and get work done, and it can also help to improve communication among team members, as developers can share their progress and discuss any challenges they are facing more frequently. As a result, this technique has become a popular tool for software development teams looking to improve their productivity.

How does it work?

MAINTAINING PRODUCTIVITY: IS THE POMODORO TECHNIQUE FOR YOU?

The Pomodoro Technique was devised by Francesco Cirillo as a University student in Germany, when he used a tomato-shaped timer to break his work into intervals, allowing him to keep a productive rhythm throughout the day. The basic technique follows these steps:

Before starting

  1. Determine the amount of work that you will need to do.
  2. Deal with any possible interruptions before starting (like emails, phone calls, meetings, or if you are at home, unexpected visits or deliveries).
  3. Make a schedule and set deadlines to finish, to calculate the number of Pomodoros you will need.
  4. Make a list of the tasks you will be tackling in this session.

During the Pomodoro

  1. Choose a task.
  2. Put your timer to 25 minutes and start.
  3. When it is done, take a break of 5 minutes.
  4. Repeat.
  5. After four 25-minute sessions, take a longer break of 20 minutes.

After finishing

    1. Record in a notebook (or something similar) how much you accomplished this session. 
    2. After you compile a good amount of data on your rhythm, start comparing it and note where you are getting stuck.

There isn’t much beyond this, which is the genius of the Pomodoro Technique; it only requires a timer and the willingness to keep records of everything that’s happening, to improve your efficiency constantly, which is why Jesús Magaña, Senior Project Manager at Scio, who advocates for this method in most of the projects he collaborates on: 

“It sounds very exaggerated to say you can only focus completely for about 25 minutes at a time, and some developers say that, when they get into the zone for hours, they can absolutely multitask, chat, watch videos, and work at the same time, but that’s just a simulation. You are not doing those things at once, but one thing after another, as interruptions. So, what Pomodoro does is organize your workflow so you can control your productivity better.”  

With such simple effectiveness, then, it’s easy to see why software developers are drawn to this method. Anyone who has ever worked in software knows that it can be a frustratingly difficult process, and part of the problem is that it’s very difficult to predict how long a given project will take. Even with careful planning, unforeseen complications can always arise and cause delays. 

In addition, software development is often an iterative process, with new features being added or existing ones being modified as the project progresses, which adds to the challenge of maintaining a consistent level of productivity. The relatively high cost of making changes to software once it has been completed can also lead to delays as developers are forced to make sure that each change is necessary, so it’s not surprising that the Pomodoro Technique has seen such a rise in popularity; it promises to keep a developer focused on making progress.

However, is the Pomodoro Technique the end-all of day-to-day productivity? Or are there some downsides we should keep in mind to ensure that it is implemented in the most effective way possible?

The challenges of an effective Pomodoro Technique

MAINTAINING PRODUCTIVITY: IS THE POMODORO TECHNIQUE FOR YOU?

While a popular time management strategy, the Pomodoro Technique is not without challenges and downsides that any developer should be aware of to get the most out of it. In theory, it should help to increase focus and productivity, but it can be difficult to stick to the strict 25-minute/5-minute timeline, especially when you’re in the middle of a particularly challenging task, and the frequent breaks can end up disrupting a workflow, making it harder to get back into the zone, which is something that Jesús Magaña likes to address: 

“There’s research going into people’s attention span, and 25 minutes is a consistent limit for it. So even if you are completely in “the zone” during the Pomodoro, it wasn’t going to last too long after the 25th-minute mark. The trick is getting yourself used to this length of time to accomplish something.”

Of course, nothing stops you from adjusting the length of the Pomodoro according to your personal rhythm; after all, the point is finding a way to keep you engaged in the task without getting burned out in the process. A more personal, customized version of the Pomodoro Technique is the most common at Scio, where the developers implementing it are likely to have better results if they take away some of the rigidity of this system.

Another common criticism of the Pomodoro Technique is that, even if it helps you go through the tasks of the day with no problem, it can be disruptive on a team to have everyone working at different speeds and taking mini breaks at different times. Does the Pomodoro Technique promote or hinder teamwork?

There are some advantages to using the Pomodoro Technique in a team setting; for one, it can help to prevent scope creep by keeping individual tasks focused and manageable, keeping team members on schedule by holding everyone accountable to the same timeline. However, there are also some potential drawbacks, like fragmenting the team’s work or making it difficult to collaborate on complex tasks. Additionally, the Pomodoro Technique relies heavily on individual motivation and discipline, which may not be evenly distributed among team members. Ultimately, whether or not this technique is beneficial for teamwork depends on the specific team dynamics and goals. There is no one-size-fits-all solution for this, so strong management of the project is required to make it work as it should.

Final thoughts

Regarding software development, the Pomodoro Technique is a powerful tool to increase your daily productivity, keep deadlines under control, and help developers make progress every day. And while it has some important downsides to keep in mind, as a solution to daily distractions, it can get the job done. With all that said, we can extract the following key takeaways from it:

  • Keeping your daily productivity can be hard depending on the project and its requirements, but there are a lot of methods out there to help you with that.
  • The Pomodoro Technique is the most widely used, thanks to its low-tech approach and simplicity to keep a working rhythm.
  • However, the rigidity of this technique is not for everyone, but nothing stops you from fine-tuning it to your personal preferences. 
  • Also, it can be counterproductive to teamwork, so having a solid direction and management during the development cycle is critical for a successful implementation of the Pomodoro Technique.

Scio is a Nearshore software development company based in Mexico where we believe that everyone deserves everyone should have the opportunity to work in an environment where they feel like a part of something. A place to excel and unlock their full potential which is the best approach to create a better world. We have been collaborating with US-based clients since 2003, solving challenging programming puzzles, and in the process showcasing the skills of Latin American Engineers. Want to be part of Scio? Get in contact today!

Is your talent distributed or remote?: A new way to look at inclusion in the workplace.

Is your talent distributed or remote?: A new way to look at inclusion in the workplace.

by | Jul 7, 2022 | Nearshore, Project Management, Remote Work

Curated by: Sergio A. Martínez

At this point, the adoption of remote work has become normalized, to the point of (almost) becoming standard in many sectors of the software industry; all said, the option to work away from an office is now a pretty popular perk among developers and engineers all over the world.

Is your talent distributed or remote?: A new way to look at inclusion in the workplace.

However, even if we understand the benefits of this model of collaboration, it doesn’t mean we have completely mastered it yet, and plenty of discussion about the best integration of people beyond the office space is still happening. Mainly, there’s been a lot of talk about the benefits of both remote and distributed work, and while there are certainly some similarities between the two, there are also some important differences that we should know about. 

Namely, that one of them is way more inclusive and equitable than the other.

But what do we mean by this? Remote work, as the name suggests, simply involves working from a remote location — usually your home. Distributed work, on the other hand, involves working with a team that is spread out across multiple locations, cultures, and languages. Nearshore development, for example, is a type of distributed work where team members are based in different countries within the same time zone, which allows for esaier collaboration and inclusion, as everyone can participate in meetings and discussions in real-time.

“Distributed work, on the other hand, means that people on the team are decentralized. It means the company has made a conscious decision not to have a “center” that’s more important than any other location. In other words, remote work builds back from the real estate (we have an office, let’s fill it up) whereas distributed work builds forward from the humans doing the work.”

And why is this important? Because nearshore development models are much more inclusive and allow for a greater diversity of voices and perspectives. In an increasingly globalized world, it’s more important than ever that we find ways to work together that are respectful of different cultures and traditions. Nearshore development helps to make this possible.

The importance of diverse perspectives

Is your talent distributed or remote A new way to look at inclusion in the workplace.

There are a lot of reasons why diversity and inclusion are important in software development. For one, it helps to create a more collaborative environment, because people who come from different backgrounds, and have different experiences, can share unique perspectives and skill sets to make a more innovative and effective software development; after all, if you’re developing software with the help of a diverse group of people, the end result will be more inclusive for a vast range of people using, making it stronger and potentially more successful. 

Additionally, diversity and inclusion help create a more positive work environment, as an employee that feels respected and valued is more likely to be engaged and productive, as well as attract and retain top talent. When employers manage to shift their way of conceptualizing the traditional office and look for talent beyond this setup, they can discover that the best talent doesn’t necessarily have to be in a specific place; by creating an inclusive environment, they signal that they are committed to attracting diverse candidates, which can include the best and brightest from any backgrounds. 

Ultimately, diversity and inclusion lead to better software development, and a more positive work environment.

“The collaboration that Nearshore development creates between businesses and software developers, taking place in countries that are geographically close to one another, has many benefits, but one of the most important is that it helps to promote inclusion by breaking down barriers”, says Luis Aburto, CEO, and Co-Founder of Scio, an organization based around collaboration all over LATAM.

So naturally, a more distributed workplace that can reach this variety of voices is the best approach to ensure that inclusion and diversity flourish within an organization. The problem, however, comes when the structure of an organization becomes purely remote instead of distributed, and the advantages of diversity and inclusion start to become diluted. In the words of Jensen Harris, CTO at the software platform Textio:

“When there’s a center — a headquarters or physical office with just some team members who are remote — there’s a power differential. […] Some employees can work with them in person, while others are “just remote.” The result? Employees working at headquarters see their leadership more. They’ll get noticed more, run into a VP in the kitchen and when it’s time for a promotion, the VP feels like she knows the guy she’s seen in person better than the remote staff. It’s just human nature.”

In Scio’s experience, though, a strong enough culture can ease many of these issues in regards to visibility and working relationships, promoting in-house activities that encourage an understanding that goes beyond the workplace: video-call meetups and activities, for example, can bring a team closer and build the rapport necessary to keep everyone on the same page, and thus ensure a seamless collaboration during any development cycle. 

The challenge of diversity in distributed teams

Is your talent distributed or remote A new way to look at inclusion in the workplace.

However, this doesn’t mean that a distributed workplace isn’t without challenges. When it comes to Nearshore development, where both the teams and the clients share a time zone but are still spread geographically, one of the biggest barriers to inclusion is language. When businesses and developers are working in different countries, there is a potential for misunderstanding and miscommunication that can lead to frustration on both sides and ultimately make it difficult to get work done. Nearshore development helps to reduce the risk of this happening by allowing businesses and developers to work in the same language, which in the case of Scio, is easy to achieve thanks to the proximity of the US (from where most of our clients hail) to the rest of LATAM, especially Mexico. 

Still, beyond language, a challenge to inclusion is culture. When businesses and developers are from very different cultures, there can be a lack of understanding and respect for each other’s traditions, which can again lead to frustration and difficulty getting work done. Nearshore collaboration helps to reduce the risk of this happening by bringing businesses and developers from similar cultures together; for example, with LATAM being very close to the US, there are shared traditions and knowledge of each other’s cultures that benefit any collaboration between these territories.

There are many other benefits of nearshore collaboration, but these two are some of the most important when it comes to promoting inclusion. By breaking down barriers like language and culture, nearshore collaboration helps to create an environment where everyone can feel respected and valued. And that’s something we can all get behind.

Evolving our understanding of remote work

The way people work is changing, and companies are starting to catch on. There is a growing movement of companies that are ditching the traditional 9-5 in favor of a more distributed model, where employees can work from anywhere in the world.

“Before the COVID-19 crisis, a survey of office workers by 451 Research showed that two-thirds of people worked from home at least some of the time but only 13% did so all of the time”, cites the Dropbox blog Work In Progress. “For these companies, the social contract for employment is not about showing up physically, but showing up mentally and engaging fully from wherever you are. The employees commit to being part of the team and doing the work, and the employer commits to making both possible.” 

 

There are a lot of benefits to this model. For one, it allows companies to tap into a global talent pool. It also gives employees a lot more freedom and flexibility when it comes to their work-life balance, but there are also a few challenges that come with this model. One of the biggest is making sure that everyone feels included, no matter where they are located. After all, as the quoted Work In Progress blog concludes: “companies that merely tolerate remote workers rarely expend the effort to make them part of the daily rhythms and incidental interactions at HQ”, and will rarely keep their remote top talent.

So understanding both the advantages and limits of a distributed workplace, where “remote” means more than just having someone with a computer connected from far away, is the next step for the new landscape of collaboration that is changing our approach to software development. As a Nearshore company, we understand the value that diversity and inclusion can have in every successful project we collaborate on.

The Key Takeaways

Is your talent distributed or remote A new way to look at inclusion in the workplace.
  • Working away from the office is an increasingly popular model of collaboration that the software industry is starting to adopt openly.
  • However, there’s a challenge in understanding the difference between mere remote work, and a distributed organization, which can be crucial for the success of an organization.
  • While “remote work” works well with collaborators that are still local (to a point) or with hybrid models, a distributed workforce with people permanently far away requires a different approach.
  • A strong culture that builds connections between clients and teammates beyond work is better equipped to deal with challenges and obstacles.
  • And more importantly, a distributed workplace tends to be more inclusive and diverse, which enriches the software development environment and leads to better solutions for everyone.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies to help you reach new heights. We have been developing 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’ll be happy to help you achieve your business goals.