Uruguay, like its people, is a country that is calm and self-assured. The people are warm, sincere, open, and seemingly happy. It is one of South America’s most progressive societies (Uruguay was the first country in the world to fully legalize cannabis in 2013). It ranks highly on global measures for personal rights, tolerance, and inclusion,1 making it a perfect place for Agile to flourish.
Diminutive in size and sandwiched between the region’s main powers, the question is how well Uruguay can punch above its weight.
History
The Charrúa, Chaná, and Arachán were small tribes of nomadic hunter-gatherers who were the inhabitants in the area of what is now Uruguay, as well as neighboring areas of present day Argentina and Brazil, before European colonization. It is estimated that the population of these tribes numbered no more than 20,000 people in total.
Colonization of this part of South America by Europeans occurred relatively late, partly due to the initially strong resistance shown by the indigenous peoples (who were later all but wiped out by European invaders), and partly due to apathy because of an absence of gold and silver in the area. The Portuguese and Spanish took an interest in the region in the late 17th and 18th centuries, the Portuguese establishing a base at Colonia del Sacramento and the Spanish founding Montevideo. The two powers struggled against one another for control of the area until Spain sided with France in the early 19th century, bringing them into the Napoleonic wars. Britain attempted several invasions of the River Plate area to gain control of Buenos Aires and Montevideo. Though the British had a presence in Montevideo for a few months in 1807, they were ultimately unsuccessful in occupying Uruguay. The struggles weakened the colonizing powers and sowed the seeds for independence movements to grow.
A concentrated campaign in 1825 against what was then Brazilian control led to a British mediated treaty that gave Uruguay its independence. The threat of further incursions from Brazil or Argentina subsided toward the end of the century, allowing Uruguay to emerge with a strong economy based on beef and wool – a legacy of the cattle that had been first introduced by the Spanish.
A period of relative stability and harmony was disrupted when, partly because of a drop in food prices in Europe and Asia after World War II, and partly due to a general worldwide decrease in demand for Uruguayan agricultural goods, the economy took a downturn. The subsequent drop in the standard of living led to civil unrest and the rise of an armed guerilla group named the Tupamaros who carried out robberies, kidnapping, assassinations, and made attempts to overthrow the government. Tensions escalated to the point where the government announced a state of emergency in 1968, introducing a number of repressive policies and the suspension of civil liberties in 1972. The following year, the military, on request of the then president Juan Maria Bordaberry closed down the congress and established a civilian-military regime. During this time, Uruguay participated in Operation Condor,2 the US-backed campaign, to repress the political left by a number of right-wing dictatorships in South America. Democracy was not re-introduced in Uruguay until the mid-1980s following the rejection of the military’s new constitution in a referendum.
Economic instability rose again at the turn of the millennium, when commodity prices dropped again and financial crises affected Argentina’s, Brazil’s, and Uruguay’s other main export markets. Despite the severity of the financial situation, Uruguay fared much better than its neighbors, an indication of its stability and reputation to investors. In the global financial crisis of 2008, Uruguay was the only country in the whole of the Americas that did not fall into a recession going by the technical definition of two quarters of negative growth.
Power in Uruguay has historically been contested between the Blancos and Colorados parties (named after the respective white and red bands that their members wear). In recent years the first left leaning party, Frente Amplio (translated as “Broad Front”) was elected in 2004, 2009, and 2014. They have introduced many cultural changes. The Frente Amplio government has overseen the legalization of marijuana, abortion, and same sex marriage. In 2005, they created the “Ministry of Social Development” to reduce the country’s poverty rate.3
Uruguay is notable for the progress it has made in its development and use of renewable energy. It made the bold ambition to be carbon neutral by the year 2030. As of 2015, they were 95% there, an achievement made in less than ten years4 by the development of hydroelectric dams, wind turbines, and solar panel parks. This has slashed Uruguay’s cost of producing electricity and the country’s carbon footprint.
Since its transition back to democracy, Uruguay has developed good relationships with the United States. Commercial trade has grown substantially between the two countries in recent years in particular, fueled by a bilateral investment treaty signed in 2004, and a Trade and Investment Framework Agreement in 2007.
This relationship between Uruguay and the United States was in evidence in the companies that we visited, nearshore software development companies providing services to US customers looking to lower costs while retaining quality and speed to market. The following story is told by Juan Rucks, Senior UX-UI designer at a company called UruIT based in Montevideo that we visited, and he tells the story about how at UruIT they build relations and trust with their overseas clients.
Building Trust, Learning, and Understanding: An Agile Approach to Project Discovery
Starting any new development project is a challenge. It’s the kind of stuff that still keeps me up at night. There is that uneasiness in the air that is almost palpable: there’s a lot of money on the line, anxiety is high, and trust still needs to be won. Agile methodologies, User Centered Design, and Design Thinking are all things that sound great when you explain the theory, but for the person on the paying end who is unfamiliar or inexperienced in development of any kind, those first days or weeks can REALLY make you question your investment decision. It’s not so hard to empathize with a client. As a client you want to see progress as soon as possible; you just shelled out thousands of dollars and in return the people you just hired are running “new-age” activities with post-it notes, asking to talk to users and telling you they are probably not going to do all the things you hired them to do in the time you hired them to do it. Wireframes, designs, prototypes, code, functionality, and releases are those tangible things that most clients in my experience consider “progress”; but Agile is not so good in providing “progress” in terms of delivering more features as it is in identifying value. Agile development if done right – in my opinion – is not faster than other methodologies but rather the opposite: it provides faster opportunities to learn and iterate on the thing you just built. You might actually spend more time ideating, testing, and measuring a particular piece of functionality than building it. If we compare development methodologies, I believe that in the same set amount of time using an Agile methodology, you will probably get less functionality done than in more traditional development, the difference being that the functionality that you do build will no doubt be more valuable and refined. This is an idea that is all well and good on paper, but telling the client that we will probably get less done than what they imagine is a really hard conversation at this stage of the project.
After many new projects, some more successful than others, I’ve come to the conclusion that the first few weeks of a project are about balance: interweaving things that the client wants to see with testing and research. Now all clients, all projects, and all teams are different, but I’ll try to share our way of tackling these first few Sprints and why we do it in the way we do. It is in no way perfect; in fact, it is very much a work in progress which changes with every new project.
To understand why we do the things we do I figure it’s important to first give you a little insight into our own particular context. We are a small development company based in Uruguay that works remotely principally for the US market. We tackle anything from small three-month startup projects all the way to partnership-like developments that span years. This means we meet all kinds of clients, from startups to well established companies, who have all types of previous experiences with development projects and who do business in all types of markets. However, although I can’t say it is true in all cases, two particular patterns I’ve seen with our clients are that (1) they are looking for lower costs than what they can get back in the United States while still keeping quality and (2) they appreciate, or are interested in, an Agile methodology because they’ve been burned previously with the more traditional waterfall approach of developing.
Lots of companies and people have different names for the initial project start phase, we in particular have started calling it the Project Discovery. It is very different from our actual development cycle and more often than not, we sell it as an entirely different project. The idea behind this is that we can’t estimate what we don’t understand. When a client comes to us asking for a price and time estimate, it’s often – and particularly in bigger projects – that we back up and propose to do a Project Discovery instead.
This is in fact what gives us our first limitation: the Project Discovery cannot be a big investment for either the client or for us, both in terms of money and timewise. Coming from a non-Agile UX background on my first projects, it made perfect sense to me to analyze problems in detail: conduct user interviews and testing sessions, create personas, post surveys, do benchmarking, create user journeys, etc., and of course, create neat documents to gather all our findings before starting a project. If you take the time to do all these things – and we have! – you most likely are going to spend months in this endeavor. To top it off, the unfortunate truth is that most clients do not see the value in these things that we in the industry do. I’ve yet to see a client have a “eureka” moment based on user feedback that has drastically changed their way of thinking or their general approach to an idea; the truth is that the conclusions of good UX research rightfully get passed off as common sense in the final solution. So my advice here – and a general rule of thumb for everything in this initial stage – is to do only the essential. So how do we define what is essential? Basically by forcing our Projects Discoveries to happen within a week. An idea that we borrowed from the Design Sprint concept by Jake Knapp.5 This not only keeps the cost of the discovery phase relatively low, but having a finite amount of time forces us to make conscious decisions on how to best spend that time.
Before I get into describing our Project Discovery, I must say that client involvement during the discovery week is an absolute requirement. Learning is mutual and intensive: the client has the business knowledge that we must absorb and we must teach the client how we work. This week offers some key insights into our daily work habits such as prioritizing, identifying value, building incrementally, and testing hypotheses. It is here the client begins to understand what to expect as far as working together if the project continues after the discovery phase. For these reasons we ask the client and the stakeholders involved to free up their schedule for this particular week. The reality, and one of the biggest setbacks we’ve had with the Design Sprint method mentioned before, is that it has been impossible to ask a client and the stakeholders to give us their undivided attention for an entire week. Additionally, if you’ve ever run any Design Thinking activities with someone from another business or background you’ll agree with me that skepticism is a big obstacle to get over. Asking for an entire week is not only a huge investment of time and money, it begs the question of “is this the best use of my time?” right out of the gates; trust is a hard thing to win over, let alone win back. To this end, we defined that a single day of the discovery week can have no more than four hours of meetings or activities with the stakeholders; and we always divide those four hours into two or more intervals since it’s hard to keep everyone involved and active for a longer period.
Despite our belief in collaboration and encouragement to run the discovery week in person, be it the client flies over to Uruguay or we send people over to them, this does not always happen. We are used to working remotely, but for many of these activities the distance issue can be quite a challenge. We’ve yet to find a way to get the same level of client involvement as we get in person. Nonetheless, it can be done, it is just a lot less effective and a lot more work. Another incredibly important and sometimes overlooked aspect of having this week in person is the empathic value of the meeting of the two sides. Development can seem pretty cold and distant through mail or even video conferencing; making a connection on a human level is the base of any good working relationship, it helps communication and motivation by creating a deeper involvement and understanding between everyone.
Which takes me to our team. Usually our Project Discoveries involve all of the team members that could eventually take on the project. This depends on the size of the project, but we are used to working in small autonomous teams from three to eight people made up of Product Owners, UX/UI roles, and full-stack developers. All the team is involved in most of the activities throughout the week to learn about the project firsthand, provide their perspective, and quite possibly to take turns facilitating the activities or meetings with the stakeholders. I believe having the whole team involved is key if you can spare it; everyone learning firsthand information and providing input from their different backgrounds is a real time saver in the end and keeps everyone aligned – plus it generates that all-so-important empathy and involvement I mentioned earlier.
As far as the discovery is concerned, to me it is like a conversion funnel: it starts off with the big picture, you prioritize something and add detail, then repeat until you have a small enough chunk of the most valuable part of the project with enough detail that you could create a prototype or wireframe with. A simple example could be an online travel agent, where as a group one could identify plane ticket sales as the most valuable thing to tackle first; then within the plane ticket sales, tackle round trip tickets and within that tackle frequent flyers. So you end up creating a pretty limited but fully working plane tickets purchasing platform or site only for frequent flyers and only for round trip tickets. This is important because not only does it become the backbone of the system, it is something much more graspable, estimable, and testable. What is imperative here is that everyone – client and team – is in agreement that this is the most important and valuable thing to tackle first. Prioritization in relation to value is an incredibly important lesson the client must learn about working in an Agile methodology so we try to introduce it to them as soon as possible. Our general goal in all development is to minimize what we build while maximizing the value it delivers; the idea behind this is that smaller and simpler things take less time to build, so if we identify and prioritize what is the minimum – and therefore fastest – thing we can build that provides the most value, we are making the best use of the project’s budget and time.
The principal objectives of every discovery is to have a general understanding of the project and business, a prioritized backlog, an estimation of how long the project could take, and, above all, a general alignment between everyone of what is going to be built – if a discovery is done right, there are no surprises in the final deliverable. To this end, our first order of business after our initial talk with the client and getting a green light to begin a Project Discovery is to get together with the team internally and define the objectives of the discovery week. Our tool of choice here is Trello, where we create a column of objectives. Some are essential as I mentioned beforehand: “understand the business and its context,” “align expectations,” “define the project technology stack,” “create a project roadmap,” and “estimate size/cost,” but, of course, depending on the size of the project, much more can be done in the week. Based on our initial talk with the client, we hopefully have at least a vague idea of the complexity and size of the project. It is with this intuition that we add new objectives to the week: “create a prototype,” “identify aesthetics,” “talk with users,” “create a proof of concept,” “conduct user testing” – anything we feel would add value to our final deliverable of the week to create a more valuable and solid project proposal. This is also where balance comes into play, we try to level out things the client might want to see with things that are more intangible or research based, and we may also end up challenging some of the client’s original ideas and hypotheses on value.
Once we feel we have a good list of achievable objectives for the week, we begin planning the week and ideating the activities. We create columns for each day of the week and add activities to them. Using the aforementioned four-hour rule, we add those activities with the client and those without the client to the columns in an order that makes sense and that we consider achievable in an eight-hour day. We’ve taken activities to involve the client from several different sources: Jonathan Rasmusson’s Inception Deck from the book The Agile Samurai,6 the Design Sprint we mentioned earlier, some more traditional UX activities,7 and some we actually borrowed and modified from other companies that have a similar “discovery” process. There are hundreds of different activities that have different goals, it’s about experimenting and seeing which work best. The key concept in all of these activities is that both the team and the client are engaged and participating, if we start seeing that either side is waning, we either cut the activity short or propose a break. Some of our more tried and tested activities grouped by our more common objectives are as follows:
“Where do you see the project in three months, one year, five years” activity taken from the Agile Samurai’s Inception Deck. We ask the group to write their thoughts for each time period on post-it notes, post them on the wall, and then share.
User journey mapping. Defining the start and endpoints of the customer journey as a group and then asking the client and stakeholders to fill in the middle with post-it notes.
Stakeholder mapping. Identifying everyone involved and getting agreement on their level of involvement.
“What keeps us up at night?” from the Agile Samurai’s Inception Deck. Write on post-it notes, share with the group and identify actions to counter them.
Risk matrix. Write potential risks and worries on post-it notes and then identify their place as a group on a graph where “impact” and “probability” are the two axis. Those risks with high probability and high impact are discussed and we plan actions to counter or mitigate them.
Google’s HEART framework. You can read about the original activity8 but we actually modified it to suit our needs. What we do is write objectives for the project on post-it notes and then later arrange them into the groups proposed by the framework. This, rather than forcing us to create goals for each category, helps us identify the overall category/theme of the project which we will later use to prioritize features.
IN/OUT from the Agile Samurai’s Inception Deck. Here we discuss as a group what we will be doing, but more importantly, what we won’t be doing.
User stories. First identify the user archetypes and then as a group write on post-it notes things that these users will need to do in the form of user stories (e.g., As a frequent flyer I must be able to view my plane ticket purchases).
Story mapping. Probably the most useful activity, but also the most difficult to explain and also the most time consuming. I won’t try to explain it in detail, but you can find information online9 or in Jeff Patton’s book User Story Mapping.10 We actually divide this activity into two parts, one for creating the story map of the flow we identified and a second part for prioritizing the cards into releases. This in fact becomes our initial backlog and also our source of information for wireframing and prototyping.
There are a number of other activities needed during discovery week, but the preceding are the main ones that require most collaboration. One final note is that we always finish off the week with a retrospective to collect insights on things we did right, things we can improve, and also to give thanks, but in a nutshell, this is how we run our discovery week. Once it is finished, we might add descriptions to the activity cards and time expectations for each. We then share the board with the client, present it to them and modify it based on their feedback so that everyone is aligned on what the proposal and objectives for the week are. Once validated, we schedule with everybody the meetings/activities for the first day.
I say only for the first day because in our experience, no discovery ever goes according to plan. The Trello board becomes a sort of living schedule. We are ready to change things up on a daily (or even activity by activity!) basis. As we start discovering the project and business, we soon find that we missed things, underestimated, overestimated, or just did not get the results we intended. This is why Trello is a good tool, since you can move, add or edit the cards as needed. We usually create a new column for those activities we did not get to since it is important to see them. Team and client decisions such as exceeding the time allotted, new activities, or new objectives all have an impact on what has been planned and it is important for everyone to understand and visualize that every decision has consequences. Nevertheless, it is imperative not to forget the essential goals. On bigger projects you can potentially take up the whole week just talking about the business or just understanding the project, it is key to just have a big picture understanding and quickly prioritize the most valuable user flows that need to happen within the system. This could be done in several ways, be it by general discussion or by using an activity like the aforementioned user stories activity followed by a prioritization of the stories. However, it is important to prioritize flows and not features, which is sometimes tricky when you talk in terms of user stories.
With any luck, by the end of the week we have all the information we need to create a document with all the work we did, its conclusions, a team proposal and time/cost estimations for the project. If the project is launched, we know exactly what we need to design, build, research, and/or test in its first Sprints. More importantly, the client gets a crash course of what working with us is like and a better understanding of the Agile methodology. There is a lot more trust and understanding by clients who we’ve run this type of discovery phase with. It makes easing into working with Sprints and increments of value a whole lot easier and smoother. That said, discovery is an ongoing process during the course of a project and having the experience of the activities makes doing them remotely later on much simpler. As I mentioned in the beginning, the initial discovery process itself is not perfect – there is no silver bullet when it comes to beginning a project – but hopefully it will give you some ideas into not only how to begin a project but also into how to establish a relationship with a client who is new to the Agile methodology.
—Juan Rucks, Senior UX-UI Designer at UruIT
Get the whole team involved from the start. Involving the wider delivery team during discovery might seem like an inefficient use of people’s time, but it pays off in the end. Everyone is more aware of the problem to be solved, instead of just being told what to build. We have seen and heard many examples where people are treated as order takers and the approach is to keep them focused on building stuff, only to find that features were delivered that went unused, or resulting products were different to customer and stakeholder expectations.
Find creative ways to engage with clients during discovery and keep this collaboration going throughout the engagement. Many clients find it hard to commit a lot of time and attention to their vendor partners. However, as UruIT shows, there are creative, flexible, and time-efficient ways to ensure the communication and feedback that is needed takes place.
Examples include the following:
Keep meetings lean and worth doing
Agree regular meetings that are at the same time and place so a regular rhythm is established
Make it clear what the goals are for each meeting and what everyone should get out of it
A good facilitator can help the conversation flow and make the best use of time
Insights
The previous story, despite the humbleness of the teller, demonstrates a depth of understanding and commitment to Agile ways of working, perhaps more so in UruIT than with many of their US clients! We found the Uruguayan people to be warm, open, and sincere, traits shared by many of their fellow South Americans.
Perhaps despite its economic successes and stability, similarly to other South American cultures, friends and family are central to people’s lives in Uruguay. Friendship and social interaction extends to the workplace. At UruIT, several people that we chatted with told us about how they felt like a family there. Their work colleagues were also their close friends away from work. The company operates a policy where people are free to work from home; however, the message that we got was that people wanted to come into the office (incidentally, an office that had been converted from a grand family home, giving it a very warm, friendly, and homely feel) to be with their teammates.
This interweaving of people’s professional and social lives is well demonstrated by the following story, written by Gonzalo Barbitta, a Software Engineer at UruIT. Here he tells the story about an experiment run at the company where the team were empowered to control their own salaries.
Empowering Team Members to Control Their Own Compensation – What Happened When We Let a Team Evaluate Its Own Performance and Decide on Each Member’s Pay11
We consider ourselves an Agile company, and therefore, every team inside UruIT is self-managed. This applies not only to development teams but also to HR, marketing, and finance. Members of these teams take ownership of how their work is done by planning and managing their day-to-day activities without any micromanagement from above. There’s no boss sitting in an ivory tower, but instead, responsibility is distributed across all members of the team.
At UruIT, salaries are reviewed twice a year (in January and June) and, like most companies, raises are given based on performance. But, if there are no “bosses” and everyone shares the responsibility for the teams’ results, who should evaluate employees’ work? Wouldn’t it be better if your teammates were the ones who evaluated your work?
The Context
Approximately a year and a half ago, our company decided to try and see whether empowering teams to self-manage their own salaries would be a good idea. Of course, this was not something that could be applied overnight. Instead, we had to start small, with maybe one or two teams who were willing to be the guinea pigs.
The experiment was very simple: during each salary review, the team would have a certain amount of money to divide among its members. This amount would be decided by management based on multiple factors, such as the period’s revenue. How this distribution would take place was entirely up to the team; management would not weigh in in any way on their decision.
At that time, I belonged to a team of developers including Andrés Báez, Waldemar Lopez, and Gustavo Clemente. We had been working together for almost two years, but had known each other for much longer than that. It was safe to say that we really trusted each other and would be able to discuss without taboo such a sensitive topic as salaries. But most importantly, we all agreed that our effort would be better evaluated by our peers, after all, it’s they who see us work and progress on a daily basis. So, with this in mind, we decided to go through with the trial of this experiment.
Transparency
The first thing we did was create transparency by sharing our salaries with one another. We strongly believed that in order to reach fair salaries, we needed to know this information.
As soon as we did this, we realized that one of us was earning less than the rest, mainly due to differences in our past experience and seniority by the time we all joined UruIT. But, even though our expertise at that moment may have been different, this person had shown great improvement, up to the point where there weren’t any differences in our day-to-day activities.
We knew that if we were going to move forward with the experiment, equality in salaries was essential as a starting base. So, after the first review, most of the pay raise was used to bring our incomes closer together. The only reason why not all of it was given to one person, was the fact that at that time, one member of the team was in need of money because of a home emergency. Because of this, the income was finally split equally and given to the team members who either deserved it, or needed it the most.
Reward System
Now that we were in a more similar position when it came to salary, it was time to think about how we would divide the raise during the next review.
We knew that one of the variables we would consider was each person’s effort throughout those months, so we needed to come up with a strategy to evaluate and keep track of such a subjective concern. After all, how does one measure other people’s effort?
As we imagined, agreeing on a strategy turned out to be quite difficult. We met several times to discuss different ways in which we could approach this, but never managed to reach a consensus.
The first approach we thought about was to keep track of the number of points each person closed during a Sprint. However, we quickly dismissed this idea because we knew this was not a reliable measure of effort. If someone spends a big part of their Sprint helping a teammate, he’ll be closing less points on his own. Helping each other should be encouraged, not punished.
For another option, we got in touch with a well-known Agile Coach from outside the company who also had a suggestion. At the end of every Sprint, each member would have 100 points to divide among his teammates. For instance, “Mel” would give “John” 60 points because of his effort and how effective his work was throughout the Sprint, and then 20 points to both “Jane” and “Richard.” John, Jane, and Richard would then do the same.
We thought that this idea, even though it had its benefits, encouraged competition. Think about it: each member has only 100 (or X) points to assign. If you want to reward John, you need to punish someone else by reducing their points. We were afraid that in the long term, it might lead to undesired conflicts between us.
So, after a few more ideas, we came up with a solution that everyone could agree on: a reward system.
Basically, when someone contributed something valuable to the team, a point was awarded to that person. But how do we agree whether a contribution is valuable enough to deserve a point? Are all contributions worth one point? For instance, is spending an entire day helping a fellow dev in need worth the same as helping troubleshoot an issue which took five minutes?
Since this is too subjective, we agreed that no point would be questioned: if someone felt that a point was deserved for whatever reason, this was to be respected. Points were to be added individually and secretly.
In order to keep track of these points, we used a big letter box on our desk. Points eventually turned into post-its where someone would enter their name, its recipient and the reason for the reward. This would help us know as a team what each member considers valuable, so we could align on a direction.
Time for Review
Months went by, post-its were added into the box, and the time for review came. We had to decide how we were going to split the raise from the money that was given to us.
Theoretically, the number of post-its would be used to evaluate the contribution of each member throughout these months. However, we soon realized this system was not going to be a reliable measure of each team member’s effort for different reasons.
For instance, two of our team members worked from home at least once a week. When this happened, the number of notes granted to them was much lower, mainly because it was hard for other members to see their effort throughout the day. The same applied to vacations – the person that was out of the office clearly did not receive any notes and was punished somewhat for their absence.
We knew we could not only rely on these numbers.
We reminded ourselves about each team member’s salary, and after a brief discussion, it was clear that we were not going to reach a consensus on how to divide the income. So, to keep things as transparent as possible, each of us wrote down on a piece of paper how they thought the income should be split by allocating a percentage of the available raise among the four of us, which would then be averaged. The decision as to how this would be done was up to each team member and their reasoning would not be questioned.
Results of UruIT team’s thoughts on how to split salary increase
Mel | John | Jane | Richard | |
|---|---|---|---|---|
Mel John Jane Richard % | 20 35 30 30 28.7 | 40 35 40 50 41.25 | 20 15 15 10 15 | 20 15 15 10 15 |
For instance, Mel decided that 20% of the raise should be for herself, 40% for John, and the remaining 40% would be split equally among Jane and Richard.
After revealing these numbers, we had a brief discussion about why each of us decided to split the income in that way. It was clear that each person’s priority was to achieve equality in our salaries. Secondly, for those with a similar income, we took into account the number of notes from the experiment. So, even though the system had its flaws, it still had an impact on our final decision.
Some Thoughts
I was recently asked whether I think empowering teams to self-manage their own salaries works or not. To be honest, this is clearly not something that would suit every company. But when it comes to companies with self-managed teams with a high level of decision-making authority, I do believe this can be a great fit that could benefit both employers and employees.
For employers, salaries are no longer handled by them, which takes some weight off of their shoulders. Let’s be honest, when that time of the year comes when performance is evaluated and raises are given, it’s likely that some employees will be unhappy with the outcome. Either no raise will be given to them or not enough. Regardless, it’s the company that has to deal with the consequences. From there on, employees may feel undervalued and their commitment to the company may be compromised. With this strategy, it’s up to the team to decide.
If teams can decide about pretty much everything else, why couldn’t they decide on each other’s salaries as well?
For employees, it gives them the ability to decide on their own salaries. Their raise is no longer determined by someone who may not be capable of evaluating their work. This is even more noticeable in non-hierarchical companies such as ours.
At a team level, it also has a great impact. First, the notes help everyone understand what other members consider valuable for the team. For instance, in our case in which there was a high level of customer support, joining a teammate for a customer call was clearly something that was greatly valued.
Secondly, discussing such a sensitive topic as salary, definitely helps bring the team together . Deciding why someone deserves a raise more than others, it’s something that cannot be taken lightly. You might be forced to leave personal interests aside, or put yourself out there by sharing private concerns.
It’s been a year and a half since we started with this experiment and unfortunately, the team is no longer working together. Don’t worry, this had nothing to do with the experiment, it’s just how our industry works! But on the bright side, we are able to share our experience with new members and, hopefully, have other teams try it for themselves.
—Gonzalo Barbitta, Software Engineer, UruIT
Considering the preceding story, is it any surprise that a Latinobarómetro12 poll in 2010 found that Uruguayans are the biggest believers and supporters of democracy in South America? What also stood out to us after meeting Gonzalo and the team was that their first thought was for each other; their first concern was to ensure equal pay. Further, as Ganzalo describes, they decided to award pay increases to the people that needed it most, as shown in the case when an increase was awarded to one of the team members that had experienced a home emergency.
Don’t limit experiments to products or processes. We build minimum viable products to test ideas for products or features, and try improvements in how we do things. However, don’t stop there. Designing safe-to-fail experiments that explore and push the boundaries within which teams self-manage, are empowered and are trusted, as we saw with Gonzalo’s team, could lead to some groundbreaking advancements in motivation, creativity, and productivity. At the very least, they should result in some valuable learning.
Other signs of the socially conscious and progressive nature of Uruguayan society include a wealth gap between rich and poor lower than any other Latin American country,13 and a high literacy rate of nearly 99%.14 In 2009, Uruguay was the first country to provide a personal computer to every primary school student as part of the One Laptop per Child program.15 In an example of “take it to the team” on a national scale, the Uruguayan constitution allows citizens to change laws by popular consensus through national referendums. Examples of its use include votes that have stopped privatization of public utilities and protected pensioner incomes.
With a population of just 3.4 million people at the time of writing, half of which is concentrated in the capital, Montevideo, Uruguay is the smallest Spanish speaking country on the continent. Geographically speaking, it is the second smallest sovereign nation in South America after Suriname, and when taking account of French Guiana, it is the third smallest territory. This is “small” in South American terms; Uruguay is still about three times the size of Ireland and about 25% larger than England. However, it is nestled in-between Argentina and Brazil, two giants in geographical terms.
Relatively speaking then, the size of the Agile community is correspondingly small, limiting the range of opportunities to share ideas and experiences locally when compared to Argentina, Brazil, or Chile, let alone in comparison to the likes of the United States and the United Kingdom. However, AgileUY, the active local Agile meetup in Montevideo is growing, and as of 2019 it has a respectable 1400 members. As we have discussed, we discovered that the Agile community in South America is not restricted by borders; Agile practitioners often share experiences and knowledge across countries, making it a “small” continent after all.
Uruguay’s small stature means it is less thought of; the likes of Buenos Aires, Santiago, and Medellin are more likely to jump to mind ahead of Montevideo as locations for clients looking for offshore partners, or for companies looking to grow their international operations on the continent. Uruguay does have a number of strengths as a nearshore/offshore location though.16 Few other Latin America countries can rival Uruguay for their Internet infrastructure. While salaries are higher than in other parts of South America, the workforce is highly educated. English is taught from middle school through to university,17 and many people speak Portuguese in addition, as well as the native Spanish. A number of free-trade zones have been set up with tax incentives and exemptions offered by the government to encourage the creation of shared-service centers in the country.
Getting On and Around
In our experience, the people that we met while in Uruguay were easy to get along with. Their hospitality and helpfulness are seemingly unbounded. When we visited UruIT, we were invited to make use of their office space when we were done interviewing people. In another example, at one of the homestays where we stayed, the owner went above and beyond the call of duty to ensure we had a comfortable and smooth stay, organizing taxis for us, and giving us detailed itineraries for where to go and what to see. When it became time to leave, we had purposely left a book behind for future for guests to enjoy. Shortly afterward, we received an email from the owner. She showed real concern about how and where she could return the book that she thought we had accidently left behind.
Coupled with its relative social and economic stability, and Uruguayans’ easy-going nature, there seem to be few taboos to avoid in conversation. Perhaps the main guiding principle is to acknowledge Uruguay as the independent and distinct country that it is. Despite the temptation to group Uruguayans in with Argentinians culturally, to do so would not only be unfair, but would also be rather disrespectful.
Agile Community Events and Meetups
AgileUY: www.meetup.com/AgileUY/