Wherever Agile principles and practices took a foothold in industry, the word “process” became anathema. In many ways, this was a healthy reaction to the CMMI approach to software engineering that preceded it and that was extremely focused on process. It turns out that in addition to process, we actually need architecture, technology, teams, commitments, retrospectives and other practices.
The challenge is that some in the Agile community threw out the baby with the bathwater and declared everything process as bad, old fashioned and constraining. Although this works well at the team level, once we go beyond that level, we need coordination mechanisms to ensure that we achieve the outcomes that we’re looking for at the organizational level. Typically, a customer expects the results from more than one team to be integrated into one offering.
In many organizations, this translated into a situation where Agile practices were used at the team level while above that level, everything stayed with the traditional waterfall-style processes. Even if the intention in approaches like SAFe was to scale Agile to the organizational level, the result in many companies is that we rehash the old ways of working into a new terminology, but in practice, nothing changes.
As we’re digitalizing our product portfolio, the consequence is much faster cycles of value delivery. This value isn’t just delivered through individual agile software teams but through the software R&D department as a whole as well as through mechanics and electronics. So, the first change we need is for the company to become agile for real, meaning that every function, department and team needs to operate based on Agile principles.
This doesn’t mean that mechanics and electronics R&D need to introduce two-week sprints and deliver value at that rate, but it does mean that they need to operate in much faster cycles than their traditional ways of working. And I know of several companies where these groups adopted a sprint model and significantly benefited from it.
Of course, it doesn’t stop at R&D; it affects the entire company. In the end, the goal is business agility, ie the company’s ability to rapidly respond to changes in customer needs. This also includes sales, customer support and general management.
A second aspect concerns the traditional way of thinking about process as humans following process steps defined in some process specification. In practice, however, we can automate many steps so that humans don’t need to bother with knowing all the ins and outs of the processes followed in the organization. Instead, a few experts can define the automation required for ensuring process compliance and the rest of the organization can, by and large, be blissfully unaware.
There are many examples from the realm of robotic process automation (RPA), but an illustrative one is the build and test infrastructure that digital companies need. As we push out updates to systems in the field frequently, we need to establish that these systems will function appropriately. This requires a build and test infrastructure that allows us to catch the vast majority of issues before they reach the customer. This infrastructure, in practice, encodes and automates the quality assurance processes used in the organization. Even if we may still want a human to do a final check of the resulting release, automated testing can be run much more frequently and with much higher consistency.
As a third aspect, we need to adopt data-driven ways of working. Most companies will claim they’re data-driven, but in practice, every time the data collides with their beliefs, they reinterpret the data so that they don’t have to change those beliefs. However, as there’s much more data available due to the constant connection to systems in the field as well as with our customers, we need to use that data for decision-making and ways of working in general. Especially disciplines in the organization that traditionally have had very long feedback loops to the field need to adjust their ways of working significantly to incorporate data-driven practices.
Although traditional Agile declared everything process as anathema, the reality is that coordination across teams, disciplines, functions and departments in a large-scale organization requires processes. Digital transformation means that many tasks that traditionally were done sequentially now need to execute in parallel. In addition, the constant flow of value to the field requires significant changes to the ways of working across the company. This requires the company to adopt Agile for real, automate processes, especially around quality assurance, and start using the available data. As the saying goes: if you do what you’ve always done, you’ll get what you’ve always gotten. And as we want something different, we have to change our processes and ways of working too!
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
