The importance of balance, leadership, and communication in QA: A chat with Team Lead Ángeles Banda.

The importance of balance, leadership, and communication in QA: A chat with Team Lead Ángeles Banda.

Project Management, Scio, Software Development

Curated by: Sergio A. Martínez

The software industry has never been the same since the advent of remote work. Before this, it was expected to be present in an office full of computers and development materials to get projects done, which meant that, for most teams, productivity and collaboration were limited by how far members could physically travel or commute. But at the outbreak of the COVID pandemic, the software industry had to adapt quickly to push work and collaboration online to keep business running beyond physical walls. And most developers had to learn new ways to stay productive from home – many being able to access their work applications remotely for the first time.

The-importance-of-balance-icono

Of course, remote work was something that had already existed prior to the pandemic, but this crisis pushed a lot of Tech companies into developing innovative digital solutions almost overnight, bringing unprecedented dynamism to the software industry. Now, it’s normal for many software professionals to access their work from any corner of the world, and companies benefit from this by being able to look outside their neighborhood to find top talent, instead of confining themselves to a local workforce that is more sought after each passing day. 

However, this has not been an easy change. Working from home as a software developer can present unique challenges when it comes to maintaining a balance, which often means finding creative ways to integrate personal time into an already busy work schedule. Being able to work remotely, of course, gives plenty of flexibility when it comes to managing the daily tasks at hand, and stuff that used to require commuting or travel can easily be completed online, but this has created the side-effect of blurring the lines between work and personal life in a way that many people hadn’t experienced before. When work is at home, separation is difficult to preserve. 

So yeah, managing a healthy work-life balance as a software developer working from home can be tricky. The key is to figure out ways to use this flexibility in your favor, by making sure that you plan and allocate enough time for each activity throughout the day – be it coding, hanging out with family, having meals together, or taking some time out for yourself. For this reason, we had a chat with Ángeles Banda, QA Analyst and Team Lead at Scio, whose experience balancing work, leadership, and family life can shed a light on the challenges of remote work and software development in the remote age.

A sudden change

Nearshore development runs on culture: Ensuring collaboration is at the heart of every project.

For a parent trying to work from home, the challenge of software development on top of childcare can seem daunting. Working on complex developmental projects requires laser focus, whereas being available for kids calls for complete attention and availability too, which can be hard to find all in the same day, never mind during a complicated situation like a pandemic going on. How to achieve that?

“The pandemic was a big game-changer in my life, not only because I started to work remotely back then, but because my child was born in 2020, barely a month before the lockdowns began. I was still on maternity leave when world came down that we would not be back to the office for a while”, says Ángeles about those days. “And that was good at first because all daycares had to close down, so I got the chance to be with my child during those first few months, but then I had to think of a way to take care of him while I worked. His dad is also on the same schedule, so it was a tricky thing to balance, and we had to figure it out as we went.”

Of course, Ángeles wasn’t alone in that. According to a study by Rutgers University, “prior to the pandemic, the percent of men who provided at least five daily hours of active childcare was 15%, but increased to 29% during the pandemic. For women, this percentage was 23% prior to the pandemic and increased to 37% during the pandemic”, meaning that it had to be a meaningful change in how work and personal time dynamics had to be managed to keep productivity during the early stages of the pandemic and onward. And this often requires some creative thinking.

“What I tried to do was change my schedule and work hours to suit what I was doing at home. For example, I worked from 9:00 am to 6:00 pm, but I had to start earlier, at 7:00 am or so, when my child was asleep, so I could get some work done by the time he was awake”, continues Ángeles. “My husband and I also had to balance and schedule any call or meeting we needed to have carefully, trying to always have one of us free in case the baby needed something. It’s interesting to note how deeply your priorities change in this situation, so striking the correct balance was essential.”

Leading from afar

Furthermore, remote teams come with their own unique set of challenges when it comes to keeping productivity, and the key to successful collaboration is strong leadership that understands how to direct team members, assign tasks, and manage expectations. Good leaders find ways to keep the team engaged even though they can’t be physically present in the same location, encouraging constant communication to ensure everyone stays focused on deadlines and deliverables. With clear direction and regular updates, remote teams can accomplish great feats of software development, but achieving that requires a kind of skill that gets tested during a lockdown.

“This process had kind of a steep learning curve because, while I was trying to adapt my work at home with being a new mom, an opportunity for growth came along almost at the same time”, tells Ángeles. “I began as a Team Lead at the time, so trying to balance all of these new responsibilities was stressful, but it also comes down to the kind of team you have. I always try to keep things a little more personal, trying to know my teammates as people, which gives you certain flexibility to work more comfortably. Still, there were moments when communication didn’t work perfectly, so I had to iron out any bump in the team dynamics. I always try to solve these issues internally, talking directly to people and trying to keep our goals clear, and as time went on, we settle on something we all feel satisfied with.”

Remote teams that need to collaborate and lead from afar often have a more difficult time juggling expectations. So, to ensure successful projects, effective virtual leadership should focus on cultivating relationships as well as fostering an open communication platform between team members, which is what Ángeles learned to do. Leaders should strive to lay out clear goals, create consistent check-ins, maintain morale with recognition of individual team performance when needed, and openly invite both questions and feedback so everyone is on the same page. That way, developing a strong relationship among all members of the team can greatly increase the chances for success and make sure the development process remains efficient without compromising quality. When managed well, remote teams in software development can become a stabilizing force even during times of uncertainty. 

Assuring quality at every step

The evolution of the employee

With that in mind, we don’t need to explain how software development is tricky enough as it is. But throw in remote QA and you have a whole additional challenge. Quality assurance is an indispensable part of ensuring the final product meets the predetermined standards, but doing this remotely presents its own unique set of hurdles, like the difficulty of gauging the effectiveness and accuracy of a test while also adhering to time constraints and deadlines. Fortunately, there are ways to make these remote QA scenarios run more smoothly such as adopting automated testing strategies, employing communication tools that bridge gaps between team members, and staying organized even when managing a widely dispersed team. With careful planning and the necessary support, software development teams can navigate through the challenge of doing distributed QA with efficiency.

“I think the biggest help for the QA team was the openness of Scio to let us have all the equipment and everything we needed at home”, explains Ángeles. “It’s not like we could request absolutely anything we wanted, of course, but things like this iPhone or this Mac I have right here with me, even if I only use them to test applications and programs, made a big difference. I think it would have been easy to make us go to the office if we needed to make tests with these machines, but Scio made the effort of bringing all these resources to our home, which helped a lot.”  

However, beyond physical resources, QA isn’t something one person can do alone – it takes a village. From the Project Manager organizing everything to the developers creating solutions, software quality assurance involves so many different roles and responsibilities that without each one playing their part, success isn’t possible. This means that team members need to be creative while introducing new working processes and tools to adequately make sure that their end product meets customer satisfaction levels, yields high-quality results, and prevents any major surprises or hiccups along the way. To achieve this, Team Leaders need to keep close to this whole process, be it in person or far away, with continuous communication at the heart of it. As Ángeles explains:

“With the majority of physical interactions conducted virtually, QA teams need to be creative while introducing new working processes and tools to adequately make sure that their end product meets customer satisfaction levels. Intuitive visual feedback programs, clear-cut standards, and reliable bug-tracking methods must now be considered in addition to manual testing when it comes to developing quality software. It’s certainly not an easy feat, but overcoming this challenge will lead to better products and improved user experiences, nonetheless.”

Final words

The modern workforce is constantly evolving, and for businesses to remain competitive, they must remain ahead of the curve. Software companies like Scio that offer flexibility are doing just that – providing employees with increased job satisfaction and giving them the freedom to shape their own schedules. After all, flexibility is the cornerstone of a software developer’s well-being. Offering a predictable schedule and the freedom to work remotely empowers developers to manage their physical and mental energy more effectively by setting clear boundaries between home, work, and downtime. 

Additionally, shifts in working hours can provide an advantageous opportunity for developers to take preventive care of themselves while also enabling more collaboration when tackling complex tasks. As the case of Ángeles shows, flexible schedules supply both software developers and project teams with the ability to shift an environment focused on speed and execution into one that emphasizes thoughtful problem-solving. At its core, this kind of culture allows software developers to maintain a healthy focus on the task at hand while addressing their personal needs, which will always guarantee a positive outcome when it comes to software development.

The Key Takeaways

  • Although remote work was a game-changer in the software industry, keeping a balance between work and personal life is still a challenge.
  • At the onset of the pandemic, adjusting to these changes was difficult, and required support and skill from an organization to do it successfully.
  • The key is having a culture of growth and flexibility that offers access to the correct resources, and building teams with communication and collaboration at the heart of their dynamics.

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!

Productivity Ratio: Understanding the “invisible work” of software development

Productivity Ratio: Understanding the “invisible work” of software development

Project Management, Software Development

Curated by: Sergio A. Martínez

We know that software development is not all just coding. As with any big project, there are plenty of tasks that must be fulfilled to create an effective end product, such as stakeholder supervision, decision-making, problem-solving, communication, and time management. Which is why it is  essential to have a clear understanding of the business goals of the software being developed, while also analyzing and interpreting the user requirements that must be worked into the development phase.

When-Excel-is-not-enough-icono

That’s part of the reason why productivity in this context is a tricky thing to track. Sure, you can see how long it takes to reach the end goal and measure it against timelines and expectations, but that doesn’t take into account all the nuances of software creation, as well as the challenges of debugging, refactoring, tweaking, editing and other tedious but crucial elements of every successful project. And this is further complicated by progress not always being linear — as soon as you start working on a project, it’s almost certain things will follow their own kaleidoscope-like paths that don’t always make sense from the outside. 

With all that, it might seem that tracking productivity is like nailing jelly to a wall: not an easy task by any stretch of the imagination, and sadly without a one-size-fits-all solution. Doing the required following isn’t impossible, though, but it requires finesse and forethought to obtain meaningful results. It also requires being aware of the “invisible work” going into the development of an application, and it requires having a complete understanding of how that many pieces fit together. Unfortunately, for some teams, ignoring the tediousness of tracking productivity can be seen as more desirable than going through the hassle. However, with the correct approach, any team can achieve such a goal.

Getting ratio’d

Productivity Ratio

Working with other professionals like designers, business analysts, or testers, is part of every software development project, so good collaboration skills are necessary to reach any goal. Furthermore, making sure that the tools you are using are appropriate for the task ahead can have a dramatic impact on how successful the project would turn out to be in the long run. All these requirements mean that a positive outcome demands a spectrum of skills, which makes the whole process more challenging, and not all of them are obvious at a first glance. In the words of this Crossing the Equator article:

“This invisible work increases the communications gap between the hidden, almost abstract world of coding on the one side and that of marketers, purchasers, and investors on the other. It’s a gap that can cause frustration and misunderstanding and can lead to employee turnover and a slowdown of business growth. It is usually the responsibility of engineering leaders to close this gap.”

In other words, measuring «invisible work» can be difficult due to the complexity of any project. While time and effort can obviously be used to gauge progress, many intangible elements must be factored into the equation, but it’s hard to quantify the value of research, problem-solving strategies, code refactoring, and investigating emerging technologies that all help to improve software quality. In addition, developers must often adjust their efforts on the fly if stakeholders change their expectations or new information comes in. As a result, measuring invisible work requires an experienced team who understands what needs to be tracked and how to factor it into the overall process. And one of the more interesting approaches to this comes from a very simple formula: productivity ratios.

Productivity ratios in software development are the gauge by which you measure whether or not a process is successful, indicating the amount of work completed versus the amount of time and effort expended. In other words, it looks at how much time and resources have been invested in a project, such as coding and bug fixes, against the end result. The productivity ratio, consequently, it’s an important metric for gauging how effective a development team is at producing quality work. And understanding how to calculate it can be an invaluable tool for ensuring a project’s success. The formula to do so can be expressed as the following:

productivity ratio

The tricky part, however, is how to define what the input and the output mean in the context of development. The most common approach is looking at the basic resources that go into the project (work hours, number of developers, cost per hour, among others), against a specified result, like development milestones reached, user stories, pull requests, and many others, with the general idea that something is being produced continuously. 

The result of the equation is then compared to a baseline (industry standards, or past development story, for example) to obtain an estimate of the total productivity of a given team. But how does this tie back to the invisible work involved in software development? Coming back to the Crossing the Equator article:

“It’s a human-focused thing. It also applies to collaboration, knowledge sharing, and team-building activities. Successful organizations build products that customers love, which can only happen when the right people are involved and treated correctly. Teams cannot afford to hire people who merely hit the keyboard to write code without any profound understanding of or connection to the end user. Understanding the business means understanding its processes and goals and ensuring full team alignment.”

A different way to look at development

Productivity Ratio

In short, without a holistic view of development, a productivity ratio cannot work as is because a lot of the effort is not directly apparent in the final product (like planning, writing documentation, ensuring clear communication between stakeholders, managers, and developers, implementing and maintaining the adequate tools, observing security, refactoring the code, etc.), but it’s required to guarantee the timely delivery of a product, its quality, and the overall success of it. 

After all, putting all the focus on coding is not enough and in fact can lead to disaster if other aspects of the project such as design, testing, debugging, and the actual use case are not taken into consideration. Without properly assessing these elements a lot of issues can arise while rolling out the software to customers resulting in wasted effort and resources. That last part is key: developers should take an all-encompassing approach by focusing on the final users as the overall destination of the whole process, and what they are getting from the whole ordeal is, perhaps, the most important point of all. Consequently, an effective productivity ratio should be defined less in terms of input/output, and more like:

productivity work

The core of this approach is to stop seeing the development process as an isolated black box where effort goes in and results come out, and instead get into a mindset of the “total work” output by a team against what the client and final user will be receiving. This should not just be an abstract idea but rather a value that’s central to all efforts during production, helping align everyone with a clear goal. Additionally, when strong ties exist between a software development team and its users, trust is established allowing for up-front feedback before any changes or upgrades would be made, all but ensuring that technical implementations fit with user expectations. Bottom line – all software development projects should prioritize the user experience, helping teams align their efforts from day one. Making sure everyone understands and is deeply invested in this user focus allows for more meaningful and consistent collaborations internally, bridging the gap between the visible and invisible work. Ensuring there is a clear baseline for the productivity ratio, will end up manifesting into an ideal, successful product that satisfies users completely.

The Key Takeaways

  • Productivity is always an important concern for any software development project because it can give a clear picture of the effort and resources put into development.
  • One of the biggest challenges of tracking productivity is the “invisible work” involved in creating a successful application, which is never obvious in the final product.
  • A successful approach might be the “productivity ratio” that measures the input against the output of any project, but it needs to be used carefully to consider invisible work.
  • To that end, keeping the focus on the final product that the user will be receiving can give a better idea of the productivity of a team, comparing the ratio of effort put in versus what the user will be getting.

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!

Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Product Development, Project Management, Software Development

Curated by: Sergio A. Martínez

Let’s think of the following example: imagine a brand-new bridge connecting two highways over a river. This highway sees a lot of traffic, including transport trucks that must pass from one side to the other daily, which tend to have a weight, on average, of about 25 tons. Thus, they mark the bridge accordingly: Limit Weight: 25 tons. However, the engineers know that they need a safety margin to ensure that the bridge doesn’t stress and wear out too quickly, so it’s designed to actually support up to 35 tons. It all seems good until one day, ten years later, the bridge collapses; a 40-ton trailer tried to cross it, and a tragedy occurred.

Why-will-platform-engineering-and-self-service-be-two-of-the-biggest-trends-in-2023-icono

It’s easy to point a finger at the culprit, right? That truck was way too heavy for this bridge, so we need to build sturdier bridges and think of a system that checks if a truck has the appropriate weight before crossing. Maybe even instill punishments and fines for people going over this limit. Easy stuff. Well, if that’s the case, then nothing was learned from this disaster. It will happen again in the future.

This is normalization of deviance. Simply put, it’s when people become so accustomed to seeing certain things done wrong that they no longer register as problems, but instead as the way “things work”. And they do work, until the day they don’t: catastrophic failures like a bridge collapsing are seldom the result of a single, unavoidable act of God, but instead the accumulation of small problems that one day reach a breaking point.  And normalization of deviance is a huge problem in the software development industry. 

However, how exactly does the normalization of deviance work, how does it affect software development, and what could be the steps to mitigate, or outright eliminate, the risks it presents?

Bending the rules (until they break)

Normalization of deviance

Software and civil engineering are not that different, at least when it comes to the complexity and precision needed to build things. After all, engineering of any kind is the art of finding solutions that work under stress: creating stuff that works reliably, no matter who is using it. So, no matter if you work with code or concrete, the process is roughly the same: you need to take into account every single situation that the design demands. And thus, both disciplines also tend to have very similar problems, with the normalization of deviance being one of them.

Let’s go back to our bridge example: what was the actual problem? The truck was way too heavy to safely cross that bridge, for sure. But why was such a truck trying to cross it in the first place? Because simply put, it was a normal thing to happen, and if that sounds like a contradiction, you would be right. After all, the normalization of deviance is a lesson in human nature.

People like to bend the rules. That’s what we do. Intellectually, we know rules are meant to keep things working properly, but rigidity is not our strong suit as a species. In the words of veteran programmer Foone Turing: “We always want to optimize. We want to do things cheaper, quicker, and more at once. And the thing is, most of the time going a little faster, a little hotter, that’s fine. Nothing goes wrong. Engineers always design with a safety margin, as we’ve learned the hard way that if you don’t, stuff goes wrong very fast. So going 110% as fast as the spec says? probably OK.”

So, you may see where this is going. In our bridge example, an interesting wrinkle is that the disaster didn’t happen right away, it was a full decade after the bridge was constructed. That’s the tricky thing with the normalization of deviance: it takes time to build up. It works through subtlety: if your bridge says that it has a limit of 25 tons, but you once drove a 30-ton truck through it and nothing happened, then the actual limit is higher, right? You can do it again. And if you do it enough times?

“You’ve been going 110% all the time. It’s worked out just fine. You’re doing great, no problems. You start to think of 110% as the new normal, and you think of it as just 100%. […] Then one day you’re running into 5 other problems and need to push something, well, maybe you do 120% today? After all, it’s basically just 10% of normal…”. That’s how you get a 40-ton trailer trying to cross a bridge rated way lower than that: someone drove through it with 35 tons of cargo, and nothing happened. 36 should be fine, right? Or 37, or 38, and so on. Bending the rules became so normal, without any immediate consequence, that it ceased to be wrong. Slowly, it became the standard, and a standard supported by bent rules is always a time bomb.

But how to avoid deviance?

Normalization of deviance

In software development, the normalization of deviance can happen at every level. For example, at a product level, it’s not exactly unheard of to release software that is not fully tested, on the assumption that the bugs will be fixed in future releases, which can lead to serious problems, such as data loss or security vulnerabilities. At the development level, programmers can start to disregard code style conventions if they feel slowed down by them (there’s a deadline to meet after all), resulting in a codebase that is difficult to read and maintain. And at the security level, it’s often easier to just write down a password than wait half an hour for IT to reset your account if you forget it. In either case, the result is the same: an organization will start accumulating issues until something serious breaks one day.

However, diagnosing the normalization of deviance can be difficult because there’s no immediate feedback loop to it. The bridge probably doesn’t produce a loud cracking sound if you go a couple of pounds above the limit, or the code doesn’t stop working immediately if you deviate a little from a style convention, so implementing effective ways to detect when it’s happening, or to deter this kind of behavior, can be tricky.   

The aforementioned Twitter thread gives a great example of why: “Susan gets in trouble because she put a post-it note with her password on her monitor, and we had to sit through a boring security meeting about password security. So, people learned to put their passwords in their wallets and their phones.” Or in other words, maybe the systems we have in place provide the incentive to deviate from the rules in the first place, and having after-the-fact measures don’t do enough to stop the buildup of problems. In that case, it falls on the culture of an organization to take into account these possible challenges and take the steps necessary to avoid lowering standards as a normal practice. These four key points might help:

  1. Rules are not forever. When it comes to technology, a year might as well be a decade in terms of advancement and innovation, so every procedure and workflow must be constantly reviewed to ensure “rule-bending” is not encouraged when certain parts lag behind, becoming obsolete or just ineffective. Revising and streamlining are always valuable skills for the leadership of any company to have, and giving people the power to always ask “why” could help avoid problems down the line.
  2. Open communication is critical. In that same sense, the main danger of deviance is that it develops in secret. Effective project management means communicating effectively with people, making clear the purpose of every rule, and being open to opinions, suggestions, and discussions to ensure those rules are effective and followed. Also, promoting an environment where a developer can communicate when a rule must be broken for the good of a project is crucial, as it allows management to respond and control such changes. “This situation has happened to us in the past”, says Jesús Magaña, Senior Project Manager at Scio. “And this decision has never been taken lightly. The objective, after all, is reaching the finish line without compromising quality or performance. This ‘shortcut’ has to be done with the consent of the Project Manager and the client, keeping in mind the possible consequences of doing so.”  
  3. Any change has to be clear and well-thought. The software sector is also ripe for new technologies, frameworks, languages, and tools to be implemented during development, but these changes are not trivial. If a new element is adopted within the development environment without proper measures (like clearly explaining the benefits and drawbacks of the new tool, giving people enough time to acclimate to change, being open to concerns, etc.), the risk of deviance grows.
  4. A culture of collaboration, not politics. Probably the most common cause of normalization of deviance, many of these examples don’t happen in isolation. Humans are social beings that tend to form cliques and in-groups that cover for each other, which can happen at every level of the organization, and thus be the perfect place to brew deviance that could snowball into disaster. So, promoting collaboration, being lenient enough with consequences so people feel comfortable about speaking up, but not to the point that developers feel they can get away with anything, and frequently promoting people to mix and work together in different configurations might be the key. It all comes down to skilled leadership.

And knowing is half the battle

Normalization of deiance

However, let’s not assume that these steps, although useful, are completely infallible when it comes to mitigating the normalization of deviance because this kind of behavior is simply human. We bend the rules when we know we shouldn’t, even at a personal level sometimes (“I’m on a diet, but this piece of cake shouldn’t be a problem, right?”), but that doesn’t mean that we cannot anticipate, learn, and improve at every opportunity. Understanding this is what separates good software organizations from the rest of them. After all, as Jesus Magaña tells us, “one of the values of the Agile Manifesto establishes that ‘people and interactions are above tools and processes’, which implies that a process doesn’t have to be a rigid path. Sometimes you need to veer off-course, and that’s not cheating. Let’s just keep in mind that, if everything is going well during development, a process is meant to help us to be consistent with the quality of our work.”

The Key Takeaways

  • Normalization of deviance, of lowering standards over time, is always a risk in any industry, especially software development.
  • Simply put, people are going to bend the rules when that benefits them because that’s simply human nature.
  • The main danger is that this normalization is almost always invisible until too late, helping the build-up of issues and problems until a disaster occurs.
  • It’s up to the management and culture of an organization to mitigate this deviance, which is virtually impossible to eliminate but can be avoided with the right approach to communication and collaboration.

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 Toyota Production System in software development: Lean, Agile, and Effective.

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

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

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.

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!