The Agile software development method has been used in software development since the early 2000s, with few changes in the way it is used to manage software development projects. The Agile Manifesto has 12 guiding principles, mostly encouraging the setting of short-term goals with short turnaround times, resulting in quality software developed more quickly. Game-ification of the development process, and self-defining teams are key. Agile is an excellent way to manage projects where the landscape is changing rapidly, as rapidly as the software is developed; because the teams are focusing on short-term goals, changes can be made quickly, as business needs and market conditions dictate.
Agile versus Pragmatic Agile
Agile development is not without its pitfalls. A lot of “religious” ritual has grown up around Agile projects, rituals that were designed to ensure development teams follow proper procedures and ensure Agile principles are accurately followed, but have created unintended consequences that often hamper the business velocity of projects in favor of development velocity and Agile purity. Enter “Pragmatic Agile Development.” Pragmatic Agile development takes the best parts of Agile software development and removes those that don’t work in the real world. Ed Schwarz, co-founder and vice president of engineering at Gorilla Logic, describes Pragmatic Agile development as being able to identify the few top things that really matter, concentrate on the Agile principles that are practical and gets the important work done, but setting aside those areas that don’t work.
Schwarz says, “In addition to being robust to change, you need velocity, which is why you have things like continuous integration. It’s the reason you need to check in quickly and frequently, and break up the project into small pieces that can be implemented and corrected quickly.” Quick corrections are key to Pragmatic Agile software development. It starts with continuous integration, with quick and frequent check-ins by each team and breaking the project up into small pieces that can be implemented and corrected quickly. With continuous integration, the teams and customers do not have to wait until the project is completed to find out whether the system works. Schwarz describes the benefit of continuous integration as: “Get as much of the system working and tested as you can as early as you can.” Agile project management uses “sprints” to get short-term goals completed quickly; the optimal length of a sprint runs from one to four weeks and is a set period of time within which each team must develop, test and finalize their portion of the project. Communication happens between the teams and with the project management team during weekly meetings, designed to see where each team is within their areas of responsibility.
The Pragmatic Agile technique allows for longer sprint periods because communication within and between teams is more continuous. “You just have to be communicating over time, but that’s really more of a practice,” says Schwarz. “If you keep your eyes on those goals, and you’re communicating continuously about the goals, then it doesn’t matter whether the sprints are two weeks, three weeks or a month. It doesn’t matter whether you have sprint retrospectives for every single sprint or you do it informally because communication is still happening.” The religious zeal and fanaticism of Agile purists, however, closes off an important resource development companies all need – outside developers. Because Agile is flexible, new teams of outside developers can be added as needed, plugged into a particular piece of a project, then walk away once their part is complete. But those teams must adhere to the rituals at the center of Agile. One of the hallmarks of Pragmatic Agile is ‘YAGNI,’ which stands for “You Ain’t Gonna Need It.” Schwarz explains it best: “At the daily stand-ups, the teams can talk through their goals. During that process, they may realize they’re working on a component that won’t be valuable for some time down the road and change course, concentrating on real, immediate functionality.”
Pragmatic Agile and Outsourcing
When working with outsourced development teams it’s important to consider cultural practices as it relates to the effective implementation of Agile practices. “Nearshore” locations in Latin America are more amenable to Pragmatic Agile practices than “offshore” locations like Asia or Eastern Europe.
As mentioned above, continuous communication is a key component of pragmatic agile development. Unless your offshore developers are working the graveyard shift, communication will typically be limited to email with as much as twelve hours of latency between requests and responses. With nearshore locations situated in US timezones, the entire delivery team can be closely collaborating throughout the work day using tools like Skype and Slack for video conferencing and chat.
Another key aspect of team communication is cultural affinity. Team members need to be able to “understand” each other. This doesn’t just mean that everybody speaks the same language. They need to understand nuance underlying the language. They need to get the same jokes! There are some cultures that are highly hierarchical which makes team members hesitant to speak up. Although Latin American cultures certainly differ from the US, the divide is typically not terribly significant in ways that impede effective collaboration on agile projects. This is especially true in Costa Rica, which is culturally very similar to the US.
What Pragmatic Agile Means For Business
Gorilla Logic has introduced Pragmatic Agile software development as a guiding principal in their development to allow worldwide teams to understand and jump into the process. Pragmatic Agile removes the rituals and fanaticism surrounding Agile, and just focuses on getting the quality, enterprise work done as quickly as possible, as completely as possible. By taking ritual out of the mix, Gorilla doesn’t have to translate Agile to teams that don’t adhere to those rituals. According to Schwarz,
If one piece of Agile doesn’t work, if your product owner needs someone else to write their product specs, anything needing someone outside the Agile framework to work within it, Pragmatic Agility makes Agile work across the board. It adds velocity to the project that might be stunted by strict adherence to the ‘religion’ of Agile.”
Using Pragmatic Agile, then, Gorilla brings teams from around the world to allow customers to plan their product releases faster, with better quality, better control and greater cohesiveness between the teams working on each project.
Want to know more about pragmatic agile and software development in a nearshoring or onshoring environment? Don’t hesitate to contact us with any questions you may have and follow us on twitter.