Hybrid in name only

In a recent interview with a Dutch newspaper Tamar de Waal explains the results of her research in Dutch policies for integration of immigrants and refugees in Dutch society. She describes how over the course of the past 20 years the country shifted perceived responsibility for integration from society as a whole to individual migrants, how the government introduced increasingly strict rules and conditions for citizenship, enforced by examinations and fines, and finally outsourced the preparatory courses in Dutch language and culture to the private market.  The results she describes as disastrous, with declining amounts of immigrants passing their exams at declining levels.

These research results reminded me of how testing and quality are being treated in many organizations. With the introduction of the V-model testing became a de facto follow-up on development activities in any project. As a result the perceived responsibility for quality was no longer shared. Validating quality became testing in quality, with development and testing increasingly outsourced to separate suppliers. The results were described as disastrous for years, for example in the Standish Group’s CHAOS reports.

As a reaction to this Agile software development, and later Agile organizations, began to take hold. Development and testing became shared responsibilities of cross-functional teams once more. Business was included in this to inspect and validate quality as part of the team, not as an outsider looking in. This way of working has proven itself as successful for the past 20 years now.

Unfortunately too often I see an organization employing a “hybrid” Agile way of working. For example Scrum is often misinterpreted as being done by teams of developers, rather than by cross-functional development teams where everyone’s role is “developer” because all responsibility is shared. Sometimes these teams are even exclusively manned by supplier personnel. Additional testing phases are then introduced following the iterations to “examinate” the work of the supplier. Sometimes even the entire application is outsourced to a supplier, where “DevOps” teams try to absolutely minimize the chance of receiving fines for application outage, resulting in a complete resistance to innovation.

Tamar de Waal mentions that the Dutch government does not invest in integration while demanding more effort from immigrants. De-coupling responsibility for quality from development has a similar effect on organizations, especially if those functions are outsourced. Teams are expected to deliver increasingly cheaper services under the justification of innovation making processes more efficient. However this innovation would require investments before those benefits can be reaped. Moreover Agile has taught us that many of those benefits depend on customer collaboration. These customers however often do not view IT as something to invest in or collaborate with, but as a cost that can be saved on. This forces both development and test teams to deliver the minimum results possible without incurring contractual penalties using as little effort as possible to keep both their customers and their employers happy.

The results are often disastrous. I’ve seen organizations where software developed by Agile teams resides on a test environment for months at a time without being released to production because the test team hasn’t approved it, or even worse because nobody has the ability to make it work on an integrated environment. I’ve seen supplier DevOps teams deny responsibility for things as simple as a reboot, referring to a supposedly lacking knowledge transfer 5 years earlier. I’ve seen Scrum teams plan 10+ iterations of 4 weeks each ahead without any business involvement, on explicit request of program management, leading to decreased agility and perpetual delays in delivery. I’ve seen suppliers playing blame games over responsibility for incidents or exceptions for fear of incurring fines from their client.

If you want to prevent this from happening, the best way to go is to fully implement whichever Agile variant you prefer. A hybrid model always has the risk of not reaping the expected benefits while maintaining the very problems you attempt to resolve. If you absolutely want to go hybrid anyway, at least realize which problem you’re trying to resolve and how your hybrid model will do this for you. If you need a shorted time to market, it won’t help to follow your Agile development process with a waterfall testing process. If you require more agility in projects, don’t plan all work a year ahead. If you require increased software quality and fit for purpose, make quality a shared responsibility and include testing, business and operations in the development process. 

In the end the key to success, be it in software development, integrating immigrants into society or any other collaborative effort, is to interact with people, work together, adapt to changes and share responsibility for the end result. Exactly as the Agile manifesto taught us to do 16 years ago. Using hybrid can be perfectly fine, as long as it enables your teams to do these things. Therefore the single most important step to take when making a transition to a hybrid way of working is to adopt an Agile mindset throughout all layers of the company. Because if you don’t, you’re doing hybrid in name only.