Agile Innovation: Crossing the Wetware Chasm for Business Transformation

“ The modern era’s less rigid development methodologies - Behavior Driven Development, Scrum and Kanban complemented by “Hackathon” team-blending campaigns - are proven to accelerate agile innovation, trusted collaboration and business transformation.”

Modern-era IT jargon has coined the term “wetware” to describe the collective human capital - the programmers, developers, systems administrators, cloud and IT architects and others - who directly affect how an IT system functions.

Despite increasing sophistication, buy-siders and their builder-side agile development teams still fight an assortment of battles in the “wetware” domain  – many of which are based on biases and lack of knowledge. In an endeavor to bridge this “wetware chasm,” nearshore application builders and their agile development teams espouse a new value proposition that combines the art of collaboration with the expanding science of agile development. In this emerging wetware paradigm, inspired creativity, real-time innovation and spirited collaboration combine as key differentiators over conventional outsourcing models. 

Key innovation practices that expand the science of agile development include:

 

1, Transition away from rigid Waterfall application development practices typically used between U.S. companies and conventional outsourcers with large timezone differences -in favor of more flexible agile methodologies, such as Behavior Driven Development, Scrum and Kanban -- to accelerate and streamline lean development practices with just-in-time, daily production schedules.

2. Migration to virtual desktops and cloud-based development strategies using, for example, Amazon Web Services, and certification in stringent security practices, such as ISO 27000, to overcome data privacy and confidentiality issues between U.S. companies and their nearshore development teams.

3. Periodic Hackathons team-blending campaigns to meld buyer-side IT teams with their agile development teams - tapping into the mobile-first domain expertise and spirit of collaboration championed by an emerging breed of nearshore software builders and application developers.

The danger zone for agile innovation comes with too much formality. A truly agile team gets to know each other, come to agree on how much work can be tackled on a sprint. For example, when cycle time trends under one day with teams in the same time zone, automatically becomes a Kanban scenario. One of the big assumptions leads to overlooking how much information has to be communicated for each party to go do a good job. At the coding level, everyone needs to know what’s going on with code patterns. Though not always considered as part of agile, code reviews conducted on a regular basis - not for policing but for mutual education around the fine details - leads to healthier, more productive and shared understanding across the board.

There is, however, the peril on the science side to become an “agile cowboy.” When communications between buyer-side and builder-side become so easy and natural, the peril becomes messy agility - it may look agile, but is completely ad hoc. Practicing agile with maturity - not agility for the sake of agility - leads to processes to ensure development teams are moving quickly and in the right direction. Must have governance built into agile processes; otherwise teams can be moving fast but not in the right direction. To keep agile innovation on track, regular code reviews, certifying Scrum masters in every part of the development organization, Capability Maturity Model Integration (CMMI) Level 2 and 3 and other practices apply agile with maturity and governance built in.

“The science of agile innovation, using less-rigid methodologies like BDD, Scrum, Kanban emerges once teams master the art of collaboration combined with the discipline to apply it,” explains Patrick Miller, former CTO of Chatham Financial and CMO and Founder of  Informatic, a new software service that provides analytics and digital engagement. For our application development with Belatrix Software for Chatham Financial, a leading mobile financial provider, “The emphasis on code reviews really became important. This more flexible innovation process came as a response to needing to try new technologies, with news business application popping up, the Hackathons worked  to  solicit ideas from business and technology side.”  

During the Hackathon week, teams would vote on the best ideas from tech and business groups. The Hackathons worked to get ideas flowing between business and technology teams by breaking up into smaller teams who didn’t usually work together. Teams said “What are we going to do? We need people to feed work to our Belatrix nearshore teams.” So Chatham included Belatrix as well. With the goal to accomplish real work, Patrick and his IT managers socialized the Hackathon concept, and people got their heads around it and really embraced it . “It became competitive as to who would come up with the better idea. The Hackathons led to an evolutionary change of where the ideas first came up and how they evolved. Chatham Financial and Belatrix Software achieved an 80 to 90% success rate of the ideas coming out of the Hackathons,” says Millar.

Some of the outcomes, such as more responsive UIs and  faster processing of financial calculations, were direct contributors to the bottom line. And, attrition was not a factor. “One of the top reasons Belatrix developers in Argentina and Peru enjoyed working with the IT teams at Chatham Financial became the ongoing education achieved via a fun, yet productive break from the day to day,” says Millar. “This is particularly vital given that teams working agile must squeeze every ounce of time from their schedules.”

As buyer-side/builder-side teams adapt their development practices to address security and privacy issues, more secure development practices are the outcome. Penetration testing, firewalls, secure access and the like are necessary elements to communicate sensitive data outside the four walls of a company. Building a data set that incorporated all classic use cases from database is a fantastic exercise. 

Millar explains, “Anyone who works with developers, hears them claim ‘it’s a data problem’ -- that any trouble spots are coming from malformed data, and indeed that’s how some hackers gain access. Once you think through carefully what is a standard data type, you examine your code much more closely, developers gain the discipline of a more thorough inspection -- much more secure development and QA practices emerge.”

Given the critical nature of confidentiality and Intellectual Property issues to limit potential losses and comply with SLAs, what’s emerged is the adoption of virtual developer desktops, cloud-based development platforms and other development practices that protect development on both the builder-side and buyer-side. Why should I allow my developers to carry the code and databases on their laptops that can be lost or stolen anywhere in the world? This awareness began with the outsourcing model, then buyer-side innovators realized if they had those conventions working with the builder-side, it would be a good practice both ways. Developers perhaps don’t enjoy the lag time associated with virtual desktops and the cloud; however our experience has shown that it works effectively a - you can ramp up teams quickly, get another laptop if one gets lost, use tokens for security, and gain the benefits of secure development practices with little pain.

To apply the art of collaboration with the science of agile innovation and moving away from conventional, rigid Waterfall methodologies, best practices come to the fore. As in any business relationship, you only ever get out of a relationship what you put into it.  “It’s a misconception to think that we just signed the agreement so now the development teams can go do their own thing,” says Millar. “If you want to achieve high value add - like with any team inside your company - it takes effort to build enduring, productive and mutually beneficial relationships. It makes a huge difference when the development team is committed to the client’s vision and how they are changing the world. They get personally invested to bring that vision to life.”

Through collaborating and innovating versus being told exactly what to do, builder-side development teams become active contributors, not just passive members who are given detailed expectations and must follow orders explicitly. The result are higher value add, greater commitment and less attrition -- developers don’t want to work elsewhere, so attrition becomes a non-issue. Bottom line, blended teams are more effective, leading to better productivity and higher quality.

The question then becomes, do you have the capabilities to respond that quickly? And if you do, do you simultaneously have the ability to develop and prototype new, creative ideas, or are you constantly on the back foot responding to changes as they happen?

For example, Amazon makes software changes to Amazon Web Services (AWS) every 11 seconds - meaning it can respond in magnitudes faster than competitors to changes in business conditions. New applications are often adopted by the lion’s share of customers within 24 hours. Outside of the technology industry, the same trends can be seen. The solution for many buyer-side innovators is to harness a potent combination of agile development and working with nearshore builder-side teams. In 

PWC´s 2015 survey of 1,300 global CEOs 81% stated they are looking for a broader range of skills than in the past. Meanwhile the same survey found that access to new and emerging technologies was the number one reason to look for partners. It is this powerful amalgamation of the need for talent and finding the appropriate technical expertise that is driving companies to work with a broader array of partners.

At the same time there is a related dynamic at play. Agile development comes to the fore where small teams work closely together to produce a working prototype in two to three week sprints. The emphasis is on delivering the most critical requirements first, and iteratively improving the product over a series of sprints. In the modern era where the fastest time to market is a critical business priority in almost every industry, the allure and promise of agile innovation is clear. Meanwhile taking the iterative, agile, approach means there must be a framework for incorporating stakeholder and customer feedback, and if necessary changing direction during the product development process.

So we have two dynamics at play: an increasing need to partner for talent and capabilities; and a shift towards real-time, iterative and collaborative product development. Nearshore partners, located in a similar or close timezone, provide one solution. While companies may choose to develop everything in-house, they will face challenges in finding the appropriate skills and capabilities to keep up with rapid technological change and simultaneous business demands for faster time to market. As a result, in other situations companies will look for partners.

Millar explains, “Our mobile financial services organization was looking to develop new ways for customers to access their cash from an ATM. The result was the development of a mobile application which could be used instead of a credit or debit card to quickly access cash – so-called ‘cardless cash.’ This innovation came about due to close collaboration with our nearshore development team, utilizing two week iterative cycles. This ensured the development team could take into account quick and immediate feedback. The result was increased customer convenience -- the time it took for customers to receive cash went from 40 seconds to 10 seconds -- and increased security -- by lowering the risk of the skimming of credit cards)”

From our experiences working with this mobile financial provider and other U.S. innovators, here are five simple steps to applying what can otherwise be an elusive art of collaboration between buyer-side teams and their builder-side developers.

1. Keep team size to 7-10 members: While the exact team size will depend on a variety of variables, ideally you'll want to keep the number low. If necessary use multiple sub-teams rather than one larger team. As team sizes increase, so does the potential for conflict, less cohesion, and less productivity.

2. Find the best talent, but remember the importance of culture: As already mentioned, talent is critical to responding to the wave of digital change. But it is equally important to develop an organizational culture which strives for excellence, and which challenges your best individuals and teams. In distributed teams, this means making sure the individuals you hire are well suited to collaborative work, and making sure they have communication skills and self-reliance. Work with specialized human resource teams to identify these individuals.

3. Precisely define the methodology together with the partner: We often refer to "Agile”  to describe range of different methodologies, such as Behavior Driven Development, Scrum and Kanban. When working with a partner, make sure it is clearly defined. In addition, well-known methodologies, such as Scrum, can be modified depending on your exact circumstances and requirements.

4. Clearly outline the partner's roles and responsibilities as well as your own: Noise and friction can quickly develop when roles and responsibilities are not clearly defined. The process starts by knowing the skills needed, and identifying the profiles of individuals that match these skills together with your partner.

5. Put in place clear practices for communication for team members: Effective communication does not just happen, but rather needs to be proactively addressed. While email remains ubiquitous, it often slows down communication. The use of instant messaging, video conferencing, screen sharing all contribute to faster, more effective communication.

Why were IT teams in the heart of the U.S. financial industry able to innovate and collaborate so well  with our software builders in Argentina and Peru? The success of the nearshore collaboration came from applying less-rigid development methodologies to streamline and accelerate development and testing, however, it all started with the relationship part.

Agile development practices as applied by buyer-side innovators and their builder-side nearshore teams are indeed moving away from rigid waterfall development methodologies where things are locked down as typified by working with conventional outsourcers in locations with large timezone differences. Through flexibility, openness to receiving suggestions and spirited collaboration, U.S. innovators are leveraging their nearshore development teams, who are in turn becoming more confident and seeing that they can contribute more -- a fusion that is leading to  more innovative approaches to writing code and solving business problems.  Once buyer-side and builder-side teams cross the “Wetware Chasm” to harness modern-era agile science with the elusive art of collaboration, the world truly becomes flat when it comes to innovation.