By Jon Tonti
Agile is well on its way to becoming the new norm in software development management. Although Agile is a broad term used to describe a software development ideology, it is a practice area that enables Nearshore IT firms to compete at a higher level versus their offshore peers.
Lean Thinking – Agile’s Underpinnings
Lean Thinking was designed by Toyota in attempts to rid production systems of non-value-added activities. Value is specified from the viewpoint of the customer and broken down into tight steps that occur in a prioritized sequence ultimately leading to a product. Value derived from the product is continually redefined by the customer and those value streams are identified to inform further development.
That general concept was adapted for software development in efforts to tighten feedback loops, reduce re-work, and increase individual developer responsibility. Proponents of Agile methodologies say it speeds development, increases visibility, empowers the development team, and is a great fit for nearshore over offshore because of time zone and cultural advantages.
“Latin America has no caste system legacy. I saw it first hand in India when I worked there, intelligent younger guys of lower position would not speak up. Plus you have 12 hour time gaps,” said Brian Estep, Senior Partner at Velocity Partners when talking about the spontaneous-collaborative nature of agile teams and the intense client to development team interaction that happens daily.
Arin Sime, CEO of agilityFeat, a nearshore agile development and coaching company reiterates the time zone issue when saying “…agile is all about tightening the feedback loop with the customer, that becomes harder with a time zone issue. Depending on the exact methodology you may have daily communications and you will definitely have weekly or bi-weekly demo meetings / planning sessions that will last two to three hours, that is very tough with offshore. You could end up regressing into traditional heavy documentation requirement writing, less talking, etc.”
Extreme Programming, SCRUM, and Kaban
The concept of Agile is brought to life by frameworks like Extreme Programming (XP), SCRUM, and Kaban. Extreme programming is different from SCRUM or Kaban in that it prescribes engineering practices like test-driven development, pair-programming, and refactoring. All three methodologies have similar tenants such as working in iterations, cross-functional teams, daily meetings, frequent product demos, and Sprint (or iteration) reviews. All three methodologies also respond to the reality that there is no such thing as fixed-scope in software development and constant communication between client and vendor are necessary to avoid accumulating assumptions that can add up to big risk.
“A lot of it is just getting early feedback, in software you never really know what you want until you play with it,” said Sime.
More traditional methods might have feedback loops that last months, not days. Sime went on to say that often times features are fully developed that are obsolete or never even used, time and money that could have been saved had feedback loops been much closer together.
“The customer always has to play the role of Product Owner; they have to be very strong. The product owner directly interfaces with the development team and s/he will validate the work. It is definitely a full-time job”
The experts we talked to say companies pick and pull from the three methodologies to create their own brand of Agile.
“You can apply SCRUM as a wrapper around the technical aspects of XP; SCRUM is less prescriptive in terms of development practices. Kaban is even less prescriptive that SCRUM and can be used if you have a very experienced agile team because SCRUM might be an overkill for them,” remarked David Alfaro, president of Costa Rican operations of agilityFeat.
To use SCRUM as an example, the Product Owner (normally a dedicated employee on the client side) defines a list of prioritized features called a Product Backlog. The Scrum Master guides the development team in selecting a portion of the Backlog and assigning it to the Sprint. Although Sprints last anywhere from one to four weeks, Daily Scrums are used to constantly track progress and guide development. At the end of each Sprint the product should be deployable or as close to the minimum viable product as possible from the client’s perspective. The end of each Sprint stage is accompanied by a retrospective where adjustments are made for the next Sprint.
The interplay between Scrum Master and Product Owner of course significantly impact the outcome of the project.
“The customer always has to play the role of Product Owner; they have to be very strong. The product owner directly interfaces with the development team and s/he will validate the work. It is definitely a full-time job,” said Estep.
“The Scrum Master is in charge of the team’s progress, removing obstacles, and synchronizing the team,” added Alfaro.
Developers | Reach | Implementation
Short iterations, constant review, and an emphasis on personal responsibility might seem to create a pressure cooker environment for the developer.
“There is a lot of process involved, especially in SCRUM as things can be time-boxed for upper management. We have never seen any resistance or aversion from Latin American developers. It does introduce a lot more visibility, but in general they don’t mind visibility and want to know sooner than later if they are going in the wrong direction,” confirmed Estep.
And when asked about Agile’s reach in Latin America he explained that “it is definitely becoming more mainstream, but it is pretty small and most developers have not really worked with it,” said Estep.
Sime estimated that about 10-20% of developers in Latam are fully engaged in it.
Alfaro acknowledged that developers have heard of it and elements of Agile have touched them in some way, but few have worked in intense Agile development settings.
When asking our interviewees about Agile implementation we heard a familiar sentiment that it seems “deceptively simple,” and in actuality not that easy.
“It is a process of change management, is always hard to get a company to actually change their way of doing things,” stated Sime.
“It relies a lot on personal responsibility; it’s not a cut and dry recipe and instead depends on the qualities of each team member. A good Scrum Master is like a coach, and that Scrum Master also needs good support from upper management,” stressed Alfaro.