5 Pieces of Advice on Agile Methodology from a Nearshore Developer

Agile methodology came out of a need for innovation in an age of speed. As the development of new technologies speeds up, so did the product cycle necessary to keep up with the challenges and needs created by these new technologies. From this, the agile methodology was born.

But agile isn’t just about development; it’s about culture. Using agile, as a team, as a company, and as a group of developers, isn’t just about mimicking the popular techniques, it’s about building a team culture based on flexibility, innovation, freedom, and teamwork. Without a culture of agility, agile is just a buzzword--not a true transformation, and not the problem-solving methodology the market requires.

At Jobsity, we’ve been using agile methodology since our founding. We understand not only the what and how, but the cultural underpinning of what it takes for a team to launch successful agile frameworks, and how to make sure agile is implemented in a way that is best for the client, the client’s product, and the bottom line.

To gain insight into how Jobsity makes agile work--and how agile works for our nearshore team--we sat down with VP of Technology, Carlos >>>. We asked Carlos to explain his take on agile methodology, how he works to implement agile with Jobsity’s dispersed team, and what it takes for nearshore developers to use agile effectively,

Thanks for taking the time out of your busy day to talk, Carlos.

To start, in the simplest terms, tell us: What is the agile methodology?

The idea of agile is to be open to change. People think it’s related to speed or ease, but the real idea behind agile is to be open to change your environment.

In other words, an agile company can adapt to different environments, and an agile team can adapt to any product, any need; it can change who it is and how it works whenever it needs to and can adjust to any market, any vision, etc.

For a company to be agile, a company must be open to change and have structures in place to meet this change and change along with it.

You run technology at Jobsity, which means you oversee many teams of different people, which are often changing as projects and client needs shift. How do you implement agile methodology with a new team?

Agile is based on four values and twelve main principles. From these principles and values, you can jump into the techniques and frameworks that bring agile to life in your workflow. And with that, you create the culture of agile.

So yes, the techniques and frameworks are applied to the development you’re working on. But without the culture of agility--the culture that underpins agile methodology--those techniques and frameworks will get in the way just as much as they drive innovation. Without the agile culture, they’re useless.

At the beginning of any new team’s work: the important thing is the culture.

How to implement that culture? Start with the values (“Individuals and Interactions Over Processes and Tools;” “Working Software Over Comprehensive Documentation;” “Customer Collaboration Over Contract Negotiation;” and “Responding to Change Over Following a Plan”).

Once those values are understood, then: Describe the agile process; share the process with the team; get to know the team as people; set goals, and then play with the process.

Each team has to build and understand its interpretation of agile for it to work for that team and at that time. But it always has to be based on the four values.

Is agile different for a nearshore team than it would be for an in-person team?

It’s different, for sure.

In nearshore, the people are enthusiastic. They come to the table eager to understand agile--but the problem is with focus.

In in-person teams, it’s hard to get people to be enthusiastic, but focus comes a lot easier.

So the challenge is to apply different techniques to overcome these different challenges, depending on what kind of team you’re working with.

What recommendations would you give other dispersed teams to use when working with agile?

First, I recommend applying the framework, or one of the frameworks: Scrum or Kanban. Pick one.

And after that, use every part of this framework and learn. Then improve the process. As I said, each company, and each team, is different. And for this reason, the framework is a guide, not a map. You should change things to adapt to your team, based on your reality.

But it’s very important to start with a framework.

What is the greatest advantage of working with Agile? And what is the greatest challenge?

The principal advantage is the relationship with the client, and the second advantage is the speed and efficacy of feedback.

The idea of the third value of agile--“Customer Collaboration Over Contract Negotiation”--is to understand the client: what they need, who they are, and what their goals are. And every step of agile work after that is based on connecting to, linking up with, and performing for and with that client.

With agile, it’s all relational.

If you truly understand the client’s needs, this helps ensure that the first version of the software you deliver to them will already be close to what they need. And this facilitates quick and efficient feedback, a smooth iterative process to the next version, and so on.

For this reason, connection with clients, and feedback, are the great advantages of agile.

What advice would you give another team who is considering using agile?

It’s easy to start with scrum. Basically: there are specific events, roles, and specific artifacts. It's clear-cut.

But it’s very complex to maintain scrum. Trying to make it a habit is difficult. It takes work. This can make it a challenging process.

Many companies use the frameworks, but don’t change their culture.

I would start with the culture and then go back and add in a framework afterward.

What is your background with agile? When did you begin using it and do you feel glad to use it now?

I started with Scrum before I was introduced to Agile as a whole methodology. Back in 2010.

At that point, we didn’t have any experience with Agile, and the project lead had no idea what they were doing. My boss asked the business side to implement Scrum--and that was all. The idea was half-baked.

What I know now is that that’s not what agile is. It’s not a project. It’s a team. It’s not a product, it’s a company, a mindset.

So after that, I dedicated a lot of time to better understanding agile. I experimented with different companies using scrum and the processes and styles of work that Agile truly supports. I began to grow into the process and mature as a developer with these agile values.

Now that’s all I do! And I’ll never go back.

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.